How to do USB audio

Personally I want an audio output to ‘block’.

I really think you don’t. Blocking in this context means that fwrite does not return until it has completed, thus holding up the desktop. It has nothing to do with mixing etc.

What I haven’t seen yet is how the host knows that the device is full speed. Or maybe it doesn’t need to know – maybe the host does the above sequence regardless.

I think the value of the pullup resistor on the line determines full/highspeed

This is where the missing code slots in EHCI line 1748.
FreeBSD has implemented isochronous split transactions unfortunately NetBSD has not.

The advice given in the code to plug into the root doesn’t work because the boards with EHCI we are using don’t have OHCI controllers (they should).

bulk/interrupt and control split transactions have been implemented thats why mice/keyboards etc will work through a hub.

All it means is that I can’t comment because I don’t have one.

OK. Is there something I could determine about the ARMiniX that would resolve this? Either by checking something myself or asking Andrew?

Jim

Is there something I could determine about the ARMiniX that would resolve this?

Get USBinfo: http://www.xat.nl/en/riscos/sw/usb/

Then you will understand my references to USBinfo and green or yellow icons.

I really think you don’t. Blocking in this context means that fwrite does not return until it has completed, thus holding up the desktop. It has nothing to do with mixing etc.

Ah. OK, yes, I’d misunderstood what you meant.

However the writes are simply small chunks in a loop. I did the demos in this simple way because DR allows you to use a TaskWindow and will ‘sleep’ the process to avoid being over-run. This doesn’t seem to upset the rest of the desktop. But presume you mean this isn’t satisfactory if I were to try it from a WIMP polling app. If so, fair enough, I’d understood that in such a case you have to use other approaches for DR. But it would be nice if USB audio provided something similar to DR for TaskWindows (or non-desktop uses). Make life easier for someone who wanted just a file player.

Jim

I think we’ve established that Jim only has EHCI

I think the value of the pullup resistor on the line determines full/highspeed

The question is how the host knows whether a device is full or high speed, with a hub in between – hence the need to deal with split transactions.

This is where the missing code slots in EHCI line 1748. FreeBSD has implemented isochronous split transactions unfortunately NetBSD has not.

I’m not attempting to refer to the code here and now, but how much of a resemblance is there between the FreeBSD and NetBSD code? Can you copy the missing bits from FreeBSD to NetBSD with an acceptable degree of hacking?

What I think happens is this.

When you plug into the root hub the device is directed to a EHCI controller or OHCI controller depending on the pull up resistor.

When plugged in via an external hub the upstream connection (hub to computer) is determined by the hub’s pull up resistor. So a USB 2 hub will connect to EHCI and a USB1 hub to OHCI.

When plugging a USB1 device to a USB2 hub the hub detects its USB1 by the pullup resistor and does transaction translation so that the 12mhz USB1 device to hub speed is converted to a 480mhz hub to computer speed. This allows both USB1 data and USB2 data to travel down the USB2 wire but now it has to be handled by EHCI not OHCI because that is what the hub is connected to.

Can you copy the missing bits from FreeBSD to NetBSD with an acceptable degree of hacking?

My impressions from a cursory glance were that it can wait another day :-) Its not too different.

What I think happens is this. [snip]

I have the same mental picture.

One minor point of interest I’ve just tested is if you try to play full speed audio through a USB2 hub it doesn’t work – as expected. If I rmkill EHCIDriver it does. Obviously in the absence of EHCI The hub connects at full speed to OHCI

One minor point of interest I’ve just tested is if you try to play full speed audio through a USB2 hub it doesn’t work – as expected. If I rmkill EHCIDriver it does. Obviously in the absence of EHCI The hub connects at full speed to OHCI

Now that’s interesting! However, I guess it won’t help OMAP boards, as their root hubs are high speed only, if I recall correctly.

Get USBinfo: http://www.xat.nl/en/riscos/sw/usb/
Then you will understand my references to USBinfo and green or yellow icons

I’m clearly not understanding this but USBinfo here shows the hubs on my ARminiX as all having a ‘green’ icon and their details say ‘USB2’ and the speed as ‘Hi-speed 480 Mb/s’.

Jim

To add to that, here’s the report USBinfo gives me for the ‘Halide Bridge’ which is a USB to spdif convertor. (Probably still the best in terms of timing.)

  Device: 12
      DeviceFS  : USB12
      USB spec  : 1.00
      Class     : 0     (Defined at Interface level)
      Subclass  : 0     
      Protocol  : 0     
      MaxPacket : 8
      Vendor    : 21b4  
      Product   : 3002  
      Release   : 1.00
      Speed     : Full speed (12 Mb/s)
      NumConfigs: 1
      
      Config: 1
         MaxPower  : 250 mA
         Attributes: 
         Interfaces: 2
         
         Interface: 0
         Alternate: 0
            Class     : 1     Audio
            Subclass  : 1     Control Device
            Protocol  : 0     00
            Endpoints : 0
            
            > Report=36 Length=9
            > 09 24 01 00 01 1e 00 01 01 
            
            > Report=36 Length=12
            > 0c 24 02 05 01 01 00 02 03 00 00 00 
            
            > Report=36 Length=9
            > 09 24 03 08 01 03 00 05 00 
         
         Interface: 1
         Alternate: 0
            Class     : 1     Audio
            Subclass  : 2     Streaming
            Protocol  : 0     00
            Endpoints : 0
         
         Interface: 1
         Alternate: 1
            Class     : 1     Audio
            Subclass  : 2     Streaming
            Protocol  : 0     00
            Endpoints : 2
            
            > Report=36 Length=7
            > 07 24 01 05 01 01 00 
            
            > Report=36 Length=20
            > 14 24 02 01 02 03 18 04 44 ac 00 80 bb 00 88 58 01 00 77 01 
            
            Endpoint: 1
               Direction : OUT
               Transfer  : Isochronous
               Interval  : -
            
            > Report=37 Length=7
            > 07 25 01 01 00 00 00 
            
            Endpoint: 3
               Direction : IN
               Transfer  : Isochronous
               Interval  : -

Note I obtained that by plugging it into one of the front sockets of my ARminiX.

Jim

This is where the missing code slots in EHCI line 1748.

I decided to have a look anyway (I’m waiting for Windows – it’s been 2 hours 40 minutes so far, and there’s clearly still a way to go…)

Line 1749 is “ifndef __riscos” – which surprised me, that next block (the error message) is present if __riscos is not defined.

Comparing it with the current version of the NetBSD code, to which extra isochronous support was added in 2008, there’s no difference I can see in that area. I expected to see something different around line 1807, but no.

I’ll have to have a longer look.

Note I obtained that by plugging it into one of the front sockets of my ARminiX.

Control transfers work fine. If you don’t have OHCI support (or split transfers via EHCI), you won’t notice a problem until you try to open an isochronous pipe.

Line 1749 is “ifndef __riscos” – which surprised me, that next block (the error message) is present if __riscos is not defined.

Its just commenting out NetBSD error reporting.

here’s the report USBinfo gives me for the ‘Halide Bridge’ which is a USB to spdif convertor

Jim. You said you had a switchable Class 2 Audio device.

If you switch that to class 2 what does USBInfo show for that?

Jim. You said you had a switchable Class 2 Audio device.
If you switch that to class 2 what does USBInfo show for that?

Sorry for the delay responding. Busy with something else. The Halide Bridge isn’t mode-changeable. But I’ll try and get USBInfo results from the DAC Magic Plus. Later this afternoon if I can. If not, tomorrow sometime.

BTW What would be involved in sorting out either OHCI or split EHCI for the ARminiX? is this something that could be done my modifying the Iyonix modules for the later CPU? Or is it far more complex than that?

Jim

Sorry for the delay responding. Busy with something else.

Don’t worry about it I was just wondering if it connects as a hi-speed device in Audio Class 2 mode.

BTW What would be involved in sorting out either OHCI or split EHCI for the ARminiX?

OHCI will never work on an ArmMiniX – it doesn’t have an OHCI controller. To get EHCI to work with full speed (USB1) devices full speed isochronous support has to be added to EHCIDriver.

To get EHCI to work with full speed (USB1) devices full speed isochronous support has to be added to EHCIDriver.

And, since Colin and I are looking at source files and talking about them in order to increase our understanding of the problem and the solution, you might say we’re looking at it :-)

I’ve now connected the DAC Magic Plus in both modes. The results are too long to drop in here so I’ve put a zip at

http://jcgl.orpheusweb.co.uk/temp/dmpmodes.zip

The USB/Class 2 mode is said in the manual to need a driver for Windows. But I think current kernels for Linux and Mac will drive it without a driver from Cambridge Audio. There is, I think, also more than one transfer mode on offer, but I don’t understand this so am just giving my impressions of what the manual says.

Switching mode was more of a struggle than I’d thought. Switching to class 2 worked first time. But I had to keep trying to switch back. Think it is now OK and back to Class 1.

Glad you’re looking at making EHCI! All above my head, alas. I can cope with DSP for audio signal processing, but modules and code for things like USB are beyond my grasp!

Jim

Interesting. The class 2 mode is indeed Hi-speed so should work without any modification to EHCIDriver. If its no trouble could you run my usbdescriptors application as it shows more detail. If you have to set something up again don’t bother.

If its no trouble could you run my usbdescriptors application as it shows more detail. If you have to set something up again don’t bother.

Blast! Sorry, too late. :-/ I shifted it back to the Linux box and had to play about to get it back as before. (Changing mode also reset things like the different settings for the headphone and main output volume settings the DAC itself applies.)

Alas, all these settings are fiddles along the lines of "hold button A whilst powering up the device. Then twiddle control X while holding that, then press another button quickly. Then do it again for when the headphone socket does have something plugged in. They assume you’ll only ever do this once, so don’t provide any dedicated controls for all the setup functions.

I can have another go if necessary, but I’d prefer to avoid it if I can. That said, when you/Dave get something to me that should work, I’ll have to give it a go, I guess, as I assume you’ll want it in ‘Class 2’ mode. (?)

I’ll see if I can find another similar DAC to use so I keep one ‘Class 1’ and the other ‘Class 2’.

Colin:

This is where the missing code slots in EHCI line 1748.

Just above that, at line 1723, is this line:

epipe->nexttoggle = 0;

The current NetBSD code has this instead:

/* toggle state needed for bulk endpoints */
epipe->nexttoggle = pipe->endpoint->datatoggle;

I have had cause to wonder, a time or two in the past, whether there was something wrong with data toggle when working through a tree of hubs. Something that should have been a really simple bulk transfer failed, and my USB analyser indicated something was wrong with the data toggle.

Any comment?

Colin: I take it you have some USB audio devices?