PORTS Forum
Ports and Interfaces => USB => Topic started by: alambert on February 28, 2015, 09:49:53 pm
-
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
-
Do you have a host OS that supports USB audio 2.0?
-
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...
-
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.
-
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.
-
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.
-
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.
-
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
-
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?
-
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.
-
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.
-
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.
-
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
-
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!
-
Glad you got it working, thanks for reporting back!
-
Well, working more. So I have confirmed that my chosen microcontroller has endpoints with a maximum size of 512 bytes. I wish to send more than 512 bytes in a single USB microframe. So how would this work? I tried using the same endpoint twice consecutively, and it ended up being in the next available microframe (4 microframes later, since I have bInterval = 3 at high speed). But, I've tried configuring two endpoints and sending some of the data in endpoint 1, and the rest in endpoint 2; the host does not recognize the second packet. Is there something specific with USB Audio or Isochronous for forming a (micro)frame packet from two IN endpoints? Or is this more likely to be some particular detail of the microcontroller?
-
In a USB 2.0 endpoint descriptor, bits 12..11 indicate how many additional transactions
per microframe a high-speed interrupt or isochronous endpoint supports: 00 =
no additional transactions (total of 1 / microframe), 01 = one additional (total of 2 /
microframe), 10 = 2 additional (total of 3 / microframe).
-
Oh, is that different than the high bandwidth mode that uses the DATA1 and DATA2 packets in addition to DATA0? I thought that that was different. Also, will it still work if bInterval is not set to the smallest value, 1? Mine is currently on 3 to comply with Windows (every 500us).
-
The endpoint descriptor specifies the number of packets per microframe for high-bandwidth endpoints, which use DATA0, DATA1, and DATA2. See 5.9.2 in the USB 2.0 spec.
5.6.4 in the USB 2.0 spec says:
A high-bandwidth endpoint must specify a period of 1x125 μs (i.e., a bInterval value of 1).
-
I think the underlying issue may be in how the microcontroller's USB DMA handles writes to the bus, and I just have to configure the write to be larger than the endpoint size to get multiple transfers from the endpoint buffer to the DMA buffer, which will then place the packet on the USB.
So the next problem I have to tackle is simultaneous In and Out packets to and from my device. The goal is to have a PC host send the audio device samples, which will go to a DAC chip and drive an output, then sample a sensor with an ADC chip, and send that sample back to the PC host.
Is this going to be a game of taking turns between IN and OUT transactions, e.g. time multiplexing? I'm a bit concerned, because currently I can only afford 2 transactions every 1ms frame, and until I deal with the DMA buffer size I have a limit of 512 bytes per packet. If I could somehow have two bInterval = 3 high speed transactions (every 4 microframes), but have the IN and OUT periods offset, that would be ideal. Not sure if I can actually do this, though. E.g., if I implement a microframe number check and send IN transactions to the host on mFrames 0 and 4, and receive OUT transactions from the host on mFrames 2 and 6, will both of these pipes be valid?
-
During enumeration, the host should determine if the requested bandwidth is available and refuse to configure the device if not.
After enumeration, the device can only respond to what the host does (send or request data).
Not sure what you mean by "implement a microframe number check".
-
In my microcontroller, as the host sends start-of-frames and microframes, the SOF count and MSOF count is stored in a register. So, in order to fulfill the indicated 2 transactions per ms, I check for microframe values of 0 and 4, and fulfill IN requests then.
I'm not sure how to do timing of reading OUT packet data though, since I currently don't know when the host will send these packets, relative to when I'm having the microcontroller send IN packets.
Basically, I need to figure out how to juggle the timing of receiving packets from the host, and sending packets to the host via OUT and IN transactions, respectively.
-
The device should try to be ready to receive data whenever it arrives, usually using an interrupt-driven routine to get received data and arm the endpoint so it can receive the next packet.
In a similar way, the device can arm the IN endpoint with data to send, and the host will retrieve the data when it wants. An interrupt routine can detect the sending of data and arm the endpoint with new data to send.