USBAudio and Mbox2

Using your xSamplesize% * xSamplerate% * 2 gave silence rather than a hiss that can be bumped.

This is definitely correct. The buffersize needs to be a multiple of xSampleSize% otherwise split samples can be sent which should never happen as it will cause noise not music. Multiplying it by xSampleRate*2 just gives you a 2 second buffer to smooth out desktop multitasking.

Are you now playing files which don’t give the ‘Not PCM’ error. My program won’t work properly if you have bypassed this error. Try a test file from Naim

Have you tried bAlternateSetting% = 3 yet.

Are you using the device via a hub? Some devices don’t like hubs.

Colin, it was ffmpeg 24bit conversion that made the strange header to cause ‘Not PCM’. it possibly needs a container filter applied to get the standard header.
OK, I have tried your correct buffersize with the downloads you mentioned, and there is no take up of the audio except a tiny burst as the file finishes.
If you look at
http://homepages.woosh.co.nz/ron.may/usbinfo.png
you wiil see a box at the top middle. I am thinking that may be the 1.1 root hub that Linux finds as the device name. No I am not using an external hub but I tried a USB 1.1 Hub earlier on. Could be worth trying again with the correct buffer size.
I tried bAlternateSetting%=3 and bEndpointAddress% from 131 to 3 and no change, just the ‘clickedy click click’ repeating till the end.

The png is just a graphical representation of the output from my !usbdescriptors program. The long vertical line of boxes are the standard interface descriptors. The 2 boxes to the left of that get their info from the standard device and standard configuration descriptors. For example in the long line of white boxes on the right the 2 numbers in the top left of the box are bInterfaceNumber,bAlternateSetting.

bEndpointAddress must be 3.

Which computer are you using I could send a rom image which will output debug info if you would like to try it.

Just so Ronald and everyone can be clear about endpoint addresses and numbers…

A USB endpoint number is in the range 0 to 15. 0 is always the control endpoint. The endpoint number is the same regardless of direction.

A USB endpoint address includes the direction. Endpoint addresses 0 to 15 are outputs (i.e. host to device), endpoint addresses 128 to 143 are inputs (i.e. device to host). Input vs. output is always considered from the point of view of the host controller.

If you’re trying to output from a host to a DAC, there is no way that an endpoint address of 131 can be correct.

This box is only responding with endpoint 3 or 131 on interface 2
and endpoint 4 or 132 on interface 3
I dont know why, Colins table suggested &85 and &86 as alternative endpoints so I tried them.

So far we’ve found no reason for the extra bAlternateSetting and the reason for two output interfaces.

In the png, there is tiny white boxes with for example 296 next to it.
What does that describe?

Colin I only have the Iyonix now, the raspberry pi had a totally unexplained meltdown which I believe originated in the GPU area. Even while it was overheating terribly and there was no display, the leds were indicating a normal boot to a desktop, finally it succumbed and the whole lot is dead now. All those people overclocking and overvoltaging, and this happened to me :-)
You can send the debug rom to beeb (squirly a) woosh.co.nz

131 and 132 are feedback endpoints and are used to regulate the samplerate. For example you may be sending at 48000hz and the device wants data at 48000hz for that to happen the usb clock and the device’s clock have to be the same speed which they won’t be – 48000 usb clock ticks may be 48001 device ticks – so either the device or the host have to decide which clock is correct. For asynchronous out endpoints – which we have here – the device clock is the master clock so when data is sent if it is sent too fast or slow the device sends the speed it wants the computer to send data back to the computer via the feedback endpoint.

&85 and &86 are input endpoints on another interface and are used for recording.

Endpoint addresses don’t exist in isolation. When you want to use an endpoint it is only unique to the devicename,configuration,bInterfaceNumber,bAlternateSetting,bEndpointAddress combination so you just can’t use any number you see.

The number 296 is the maximum packet size for the endpoint. USB data is transferred in chunks called packets. Each endpoint has its own maximum packet size.

For playing PCM on your device you only have the choice of:

bInterfaceNumber% = 2 bAlternateSetting% = 2 bEndpointAddress% = 3
bInterfaceNumber% = 2 bAlternateSetting% = 3 bEndpointAddress% = 3
bInterfaceNumber% = 3 bAlternateSetting% = 2 bEndpointAddress% = 4
bInterfaceNumber% = 3 bAlternateSetting% = 3 bEndpointAddress% = 4

The interface numbers will refer to different sockets on the device.
The alternate settings gives a choice of something – we don’t know what
the endpoint address is where the data is sent on that particular interface number and alternate setting.

The graphical picture from !usbinfo just gives an overview of device capabilities. It’s not very comprehensive for getting programming information.

“….the raspberry pi had a totally unexplained meltdown..”: bad luck! Were you running default (700Mhz) settings?

George, now that you mention it, though /I/ hadn’t, the PiBang distro I was using at the time might have. It was running very cool for the week or so it was running OK with it.

Colin, I have a feeling there is an unconventional hub in the box, and this is why there is talk of ‘magic’ for turning on the mixer and elsewhere they turned off the interfaces not wanted I think.
In the png this would be the box with the red question mark.
The interface 6 red question mark looks like the midi interface, It is mentioned that it works the same as a MidiMan brand.
This version of !USBinfo perhaps suggests the physical position of the unknown box 1_0
http://homepages.woosh.co.nz/ron.may/topo.png

The 1_0 is the interface subclass and protocol

Interface 0 – the first unknown interface in the png – is an Application specific interface.
Interface 6 – the last unknown interface in the png is a vendor specific interface it could be a midi interface judging from the endpoints available though there is a standard for midi interfaces so you have to wonder why that wasn’t used. If it is a midi interface it’s likely the format is non standard.

In any case the code you’ve shown me hasn’t used these interfaces

I’d like to try the equivalent of

 /* Reset ifaces 2,4,5 to 0 altsetting. */
    usb_set_interface(chip->dev, iface, 0);

It doesn’t do anything useful. It sets the alternate setting for iface to 0. 0 is a ‘null’ alternate interface. The alternate setting is set in the USBDriver when you open the endpoint.

It appears they are primarily using interface 3 the one with all output capabilities.

Then change the bInterfaceNumber to 3 in IsocPlayer2.

Did you get the rom I sent?

But if they /are/ real conventional interfaces why would they find a need for nullifying them?
Just checked the mail, it is here.
Probably be a day or two before I get back, Summer has arrived, and there is stacks of work to do.

An interface can have many alternates it is still only 1 interface the data transfer happens in endpoints not interfaces. alternate 0 has no endpoints so after setting alternate 0 you can’t send any data to the interface. You can set the alternate if you like – There’s a star command I can’t remember off hand – do a help usb*. It will only be changed again when opening an endpoint. Alternate Setting 0 is a requirement of the standard.

*USBSetInterface 3 3 0
*USBSetInterface 3 4 0
*USBSetInterface 3 5 0

does seem to block access to those interfaces, it may be only an environment setting to stop a second program from trying to use those devices which might cause the device to hang or crash.
Having said that, the MIDI interface is supposed to work simultaneously. The unknown box must be some sort of hub or interface sharing thing to allow that.

If it was important I guess one could pass the arguments to the system and use *USBInterface <cli_variable> for each interface.
Strangely I wasn’t successful turning an interface back on and using it, but I have had hangs changing interfaces in the past so it doesn’t mean much yet.

But I see what you are saying, it may not be setting anything in the device, other than checking that there is such an interface.

First attempt of the day I tried interface 2 with alternate 3 and get ‘could not open pipe’ but once alternate 2 is used, /then/ alternate 3 will open. Time taken for the same track was identical, so the 48000/44100 setting does always hold true.

All interfaces work simultaneously but each interface can only use 1 alternate setting at a time. If you are setting the interface after opening the stream then the stream won’t work because you’ve changed the alternate set when opening the stream.

Ronald: the “unknown box” isn’t a hub. If it were a hub, it would be a known thing, and it would be shown by USBInfo like the other hubs you have.

Problem resolved finally, with Colins byteswapping version of the player. There are still a lot of mysteries with the undocumented MBox2, But things are looking a lot brighter now.