USB Audio firmware development - Multiple Bit Resolutions and Sample rates

[alambert]

Hello all,

I'm hoping I can find an expert in USB Audio here.

I'm working on developing some USB Audio device firmware for Atmel's UC3 series of microcontrollers. What I'd like to do is create an audio device that supports a variable number of channels, 16-bit and 24-bit samples, and several selectable sample rates. To start off, I've used the Atmel Software Framework, which has much of the basic USB audio functionality baked right in. However, I've had trouble getting multiple sample rates and sample sizes to work by just modifying the USB descriptors.

Looking at the code already provided, I suspect I will need to implement some GET and SET requests for the CUR and RANGE attributes. Reading through the audio 2.0 specification, it looks like you can set multiple sets of ranges in the [MIN,MAX,RES] format by simply placing them in an array, and indicating how long the array is at the start. However, from the implementation examples I've seen, it looks like MIN, MAX, and RES GET/SET requests are all handled separately - the bRequest value for CUR is 0x01 (SET) and 0x81 (GET), while the three range components are split into 0x02,0x03,0x04, for SET MIN,MAX, and RES respectively; and 0x82, 0x83, 0x84 for the GET MIN,MAX,RES, respectively.

So then, if I have multiple RANGE arrays, say [8000Hz, 8000Hz, 0]; [16000Hz, 48000Hz, 16000Hz], and [96000Hz, 192000Hz, 96000Hz] as the [MIN,MAX,RES] trio, how do I format the packet to include all three pairs so that the host knows about all of the available sample rates, if MIN MAX and RES are all separate requests?

Secondly, if I've defined two alternate AudioStreaming interfaces for the 16-bit and 24-bit sample formats, and set up endpoint bandwidth appropriately for each, what else would be required to have both formats available and selectable at once to the host?

FYI, these are being developed for a High-Speed bus.

Thanks,
Alex

[Jan Axelson]

Do you have a host OS that supports USB audio 2.0?

[alambert]

Yes, it's Windows 7 64-bit. I actually also have an existing device that does what I'm aiming for, namely dual 16/24-bit with multiple sample rates, and it works quite well. The difference is that that device is full-speed only and only one channel, and I don't know how it's firmware was configured exactly. I've been using it as a model for the USB descriptors, but for things like requests which I can't easily view, its a bit trickier.

EDIT: Actually, now that I think about it, I don't think Windows has USB Audio 2.0 built in, given the presence of standalone USB Audio 2.0 drivers from companies like Thesycon. Looking at the same sections in the 1.0 specification, this indeed matches the format I've seen so far - MIN, MAX, RES, and MEM instead of just RANGE. This should clear up the confusion I had with setting sample rates.

So then the remaining questions are, is there a similar difference in implementation of both 16 and 24-bit samples between Audio 1.0 and Audio 2.0?
And also, is it possible to have high speed audio transactions using the 1.0 class drivers? (Assuming the host has a 2.0 high speed bus). As far as I can tell bInterval is locked to 0x01 in the 1.0 spec, indicating one transaction every millisecond. Combined with the 1024 byte limit for wMaxPacketSize, seems like a pretty hard bandwidth limit...

[Jan Axelson]

Yes, Audio 2.0 improves support at high speed, and Microsoft apparently hasn't seen the need to add Audio 2.0 drivers to Windows.

[alambert]

Is it possible to use the USB Audio 1.0 class to get more than 1023 bytes every 1ms on an otherwise High-speed bus? From what I can tell, the limits imposed by bInterval and wMaxPacketSize seem to be the restriction.

[Jan Axelson]

wMaxPacketSize can be up to 1024 for high speed.

For bInterval, in Audio 1.0,

4.6.1.1 Standard AS Isochronous Audio Data Endpoint Descriptor

says

"The standard AS isochronous audio data endpoint descriptor is identical to the standard endpoint
descriptor defined in Section 9.6.4, “Endpoint,” of the USB Specification and further expanded as defined
in the Universal Serial Bus Class Specification."

but then says:

"Interval for polling endpoint for data transfers expressed in milliseconds. Must be set to 1."

Yet USB 2.0 says that for high speed, bInterval = 1 selects an interval of 125 microsecs.

So the question is whether Windows and other OSes consider a high-speed audio isoc. endpoint's bInterval = 1 to be 1 millisec or 125 microsecs. I don't know the answer offhand; am hoping someone will chime in on this.

[Barry Twycross]

Our Audio people called high speed audio 1.0 devices "Frankenstein" devices. They didn't officially support them, but they probably worked. The opinion was if you wanted high speed it should be Audio 2.0.

[Tsuneo]

Our Audio people called high speed audio 1.0 devices "Frankenstein" devices.

I believe Barry means such commercial audio DAC products which run 24bit/192kHz stereo over Windows audio 1.0 driver, using high-speed high-bandwidth isoc EP, whose bInterval = 4 (1ms).

Tsuneo

[alambert]

I actually at one point had my firmware set up for high-speed operation; my Beagle USB 480 indicated that the device was in high speed mode. I had bInterval  set to 4, and observed data sent every 1ms... I also couldn't set bInterval to anything less than 3 in this mode, otherwise the device drivers wouldn't load.

I'm also having a terrible time trying to get Windows to recognize 24-bit operation. If I take all of the 16-bit code, change bBitResolution and bSubFrameSize for 24-bit, and reload the device... I'm greeted by a grayed-out sample rate selection window. Even ASIO via ASIO4ALL does not show the other sample rates.
I'm pulling my hair out at this point!

Perhaps you cannot get more than one packet / 1ms frame, but could you perhaps take advantage of high-speed isochronous endpoints' ability to do multiple transmissions per frame with DATA1 and DATA2 in addition to DATA0?

[Barry Twycross]

I know the hardware supports more than one pack per ms. I haven't come across any host chipset which could not. OS support for this was a bit patchy (I wrote a bug where 2 and 4 micro-frames didn't work). Then there's the audio driver itself which is an entirely different beast, usually from a different set of developers.

If you're using the DATA2/DATA1/DATA0 transactions, your endpoint must be specifying a binterval of 1. (1 micro frame period.) See section 5.6.4 "A high-bandwidth endpoint must specify a period of 1x125 μs (i.e., a bInterval value of 1)"

Can I suggest a different host, I'm pretty sure all this works under Mac OS.

[Barry Twycross]

Our Audio people called high speed audio 1.0 devices "Frankenstein" devices.

I believe Barry means such commercial audio DAC products which run 24bit/192kHz stereo over Windows audio 1.0 driver, using high-speed high-bandwidth isoc EP, whose bInterval = 4 (1ms).

You're right, the 1 packet/frame devices just happened to work on Windows, so were popular.

[alambert]

Unfortunately we're stuck with Windows as the aim of the device is to work with Windows machines in the long run. Anybody have any tips on the requirements to implement 24-bit sample and have Windows accept them? just setting bSubFrameSize and bBitResolution has not worked (though I can get one sample rate to send 24-bit samples).

Also, I've noticed that things start to go wrong if I set the endpoint's wMaxPacketSize much more than 500. Is there a limit here for UAC1? Perhaps 512 bytes? I was thinking of the full speed isochronous endpoint limit of 1023 bytes, but that's for the USB 2.0 specification. Audio Class 1 has been around for a while longer, so I'm wondering if Audio Class 1.0 devices have a lower max packet size.

[Tsuneo]

Also, I've noticed that things start to go wrong if I set the endpoint's wMaxPacketSize much more than 500. Is there a limit here for UAC1?

Isn't it a limitation of the device side, ie. the size of available memory (USB_RAM) for the packet buffer?

Tsuneo

[alambert]

That could be exactly it - looking at the datasheet, each Pipe / Endpoint is 512 bytes, with a total of 2368 total bytes available.

In other news, I managed to get the "Frankendevice" working - with high-speed enabled, bInterval = 3 is a valid configuration, giving me IN requests every 500us. By adding a micro start of frame interrupt, I was able to send two packets every ms. Hooray!

[Jan Axelson]

Glad you got it working, thanks for reporting back!