Isochronous USB

Since there has been a fair amount of change within the USB stack of the BeagleBoard version of RISC OS, it suddenly occurred to me to see if I could get any better response to my speakers than I do on the Iyonix. The result was disappointing.

On the Iyonix, I can open an isochronous endpoint, though I’ve never managed to get any noise out of the speakers, and the Iyonix usually stiffs soon afterwards. Trying identical code on the BeagleBoard, I couldn’t even open the endpoint.

John Ballance said that the code for isochronous transfers was all in the Iyonix stack, just that there was some bug that he never managed to find. He suspected that the stiffing might be as the code failed to return from some privileged state.

Has isochronous been disabled in the BB version?

Here’s the situation:

• EHCI controllers are used for USB 2 devices. Although they can talk to USB 1 devices if they are connected via a USB 2 hub, they can’t talk to a USB 1 device if you plug it straight into the motherboard.
• OHCI controllers can only talk to USB 1 devices.
• The Iyonix has both EHCI and OHCI controllers, and is able to dynamically select which controllers use which ports. Thus if you plug in a USB 2 device the port will use an EHCI controller, and if you plug in a USB 1 device the port will use an OHCI controller.
• Originally only OHCIDriver had support for isochronous endpoints. This meant that your only chance of getting isochronous transfers working would be to connect a USB 1 device straight to the computer (or via a chain of USB 1 hubs).
• Recently I updated EHCIDriver to the latest NetBSD sources. This included adding support for isochronous transfers. But since I didn’t have anything to test the code with, it went in completely untested. (I think I’ve got a webcam that uses isochronous for something, but no code to test it with)
• The OMAP3 is also capable of switching its USB host ports between EHCI and OHCI. But (AIUI) the USB PHY that’s used in the beagleboard only supports USB 2, so only EHCI can be used with the host port. So until recently there wouldn’t have been any support at all for isochronous transfers using the USB host port.
• The USB OTG controller does support isochronous transfers, but I haven’t tried adding support for isochronous transfers to MUSBDriver since I don’t have any code to test it with.

So assuming your speakers are USB 1, the failure when you connect them to your Iyonix will be due to the unknown bug in the OHCIDriver. And the failure when connecting them to tbe beagleboard will be due to an unknown bug in EHCIDriver (assuming you are using a USB 2 hub, which you almost certanly would be, and assuming you’re using a ROM image newer than the 22nd of July, which is when the code went in).

Thanks for your information, Jeffrey.

EHCI vs. OHCI really does depend on the USB version the device claims to work to, not the device speed? The audio devices I have are full speed only. (The hub is a single-TT affair, like most hubs are. The audio devices are seen by USBInfo.)

One curious observation: tonight I swapped the USB2 hub for a USB1 hub (both are adequately externally powered), again plugged into the BB’s non-OTG port. The BB didn’t appear to see any of the devices, not even the keyboard, and just stopped at the Supervisor prompt.

EHCI vs. OHCI really does depend on the USB version the device claims to work to, not the device speed?

I believe it’s down to some low-level signaling that occurs between the two transceivers. Or at least that’s the impression I’ve got after skimming through the relevant bit of the USB spec.

One curious observation: tonight I swapped the USB2 hub for a USB1 hub (both are adequately externally powered), again plugged into the BB’s non-OTG port. The BB didn’t appear to see any of the devices, not even the keyboard, and just stopped at the Supervisor prompt.

Yes – that’ll be due to the problem I mentioned with the USB PHY that’s been used on the beagleboard. (Although judging by this thread, the problem could be due to either the USB PHY not supporting USB 1 speeds, or the OHCI signals not being routed anywhere. Or both.)

Since the BBxM can cope with all three speeds on the on-board USB interfaces, and since I’ve ordered two more USB sound “cards” (unbelievably cheap on eBay), it must be time to have another look at isochronous USB.

But the BB has an MUSB driver too, doesn’t it? I’ve not yet worked out what that is. And I read somewhere that isochronous support is either absent or disabled (I can’t remember which, any more than I can remember where I read it).

But the BB has an MUSB driver too, doesn’t it?

Yes, it does

I’ve not yet worked out what that is.

MUSBDriver. It’s the driver for the USB OTG port.

And I read somewhere that isochronous support is either absent or disabled (I can’t remember which, any more than I can remember where I read it).

Support is absent, since I don’t have any device drivers to test it with.

Aha – in the MUSBDriver documentation, I’ve found:

(I don’t have any hardware to test with – JL)

I knew I’d seen it; I just couldn’t remember where.

My purchases from eBay were a 5.1 channel USB sound adaptor at GBP1.18 and a 7.1 channel USB sound adaptor at GBP2.45, each inclusive of P&P. There are plenty more available at similar prices. When they arrive, I’m going to try them out at work and, hopefully, capture some USB traffic on my analyser. If at least one of them works, it should be a good thing to use as a test bed.

Some years back, I did some experiments to try to control my Griffin iMic, e.g. volume, mute, sample rate, mono/stereo, etc. Most were successful, however it was really on the basis of hard coded settings. Perhaps a useful contribution I could make is to write a generalised GUI app to read the settable parameters of an audio device, and to build a GUI in which all the appropriate controls for that device appear.

I’m not sure that the API for isochronous USB was ever adequately defined. Clearly there’s a lot of real time buffer filling and emptying to be done. I’d have expected that an isochronous pipe would have to be associated with a RISC OS buffer, so that there is a standard way for a calling application to deal with buffered data, and thus largely abstract itself from having to deal with hard real time issues. If the API does deal with that, I’ve failed to see it.

One (curiously not both, but the supplier has admitted the mistake) of the two USB sound interfaces arrived yesterday, so I played with it and my old iMic last night here, eventually gaining a much better understanding of the audio descriptors. Now I see how it’s possible to build a block diagram of the internals of a device.

Also I did some captures this lunchtime from both of them. I can see how the sample rate is set, and I can see how streaming is started and stopped.

The captures confirm what I had expected when operating at 44.1 kHz: there is one frame in which 180 bytes are transferred, followed by 9 frames in which 176 bytes are transferred. This ensures that, even if a frame is lost due to errors, the stereo channels won’t swap.

It all reinforces my perception that isochronous transfer is substantially more complicated than the other modes.

If Jeffrey or anyone is thinking about buying one of the USB sound adaptors, there is a definite reason to buy the “7.1 channel” version over the “5.1 channel” version: the 5.1 channel only supports a sample rate of 48000 Hz, whereas the 7.1 channel supports 48000 Hz and 44100 Hz. Better for playing CDs at normal speed :-)

The old Griffin iMic has a much greater choice of sampling rates for the input system, and a continuous range from 4990 Hz to 48010 Hz for the output system.

“It all reinforces my perception that isochronous transfer is substantially more complicated than the other modes.”

I haven’t looked at this very deeply, but I noticed at

http://www.beyondlogic.org/usbnutshell/usb4.shtml

that it uses both channels, and maybe takes over the normal bus
for its data. Maybe a duty cycle could be established for a timed
switching in and out.
Steve Drain released some timing related utilities recently.
You might be able to do something in BASIC.
Just a few wild ideas, Thanks for your efforts.
Ron M.

Red Book 2ch 44.1/16 is probably all that is needed right now :-)