How to do USB audio

bq. Doesn’t the device tell you how many bytes or samples per ‘frame’ it requires?

No. You work it out from the sample rate, the word length, and the number of channels. The arithmetic is simple enough. An audio frame consists of all the bytes necessary for one sample for all channels, e.g. 4 for 16 bit stereo. You have to send complete frames, hence 44 (mostly) and 45 (the other times) for CD audio, being 176 or 180 bytes.

OK. I was trying in vain yesterday to update and add to what I’d asked. But the site had frozen (presumably Andrew’s work ‘upgrading’ it).

I’d looked at the list of settings that had been posted and noticed that the device seems to say that the max number of unspecified items (presumably bytes) per transfer was 200, and that it polls at 1ms intervals. Which is presumably the basis of the 176 / 180 (?)

Is this not bufferred? The list seemed to include aysnch isochronous which IIUR means the device will handle the timing and just says when to ‘send the next batch’. If so, all you have to do is keep up and it should have enough internal bufferring to avoid ‘crackles’. However given the vast expense – 2 quid – maybe we would hope in vain for the device to have decent buffers itself.

Might a better USB device avoid the problems and be easier to use? I’ve not yet looked for one as I’ve been busy with other things, but I’ll have a look when I get a chance. I do have some fancy asynch / iso DACs but these are more complex as they can support many rates and use a 32 bit ints conveying 24bit values.

Would it help if I probed one of these and listed the results?

Jim

Jim: the way isochronous audio works is that you send suitably-sized packets to the device every 1 ms (assuming full speed). The device doesn’t poll. It’s common for devices to be adaptive, which means they adapt their output sample rate to that of the bus, at least over a small range. Some devices adapt over a huge range – the iMic claims to work over a range of sample rates from about 4k to 48k. Under those circumstances you can see how important it is to keep feeding it at a regular rate.

Would it help if I probed one of these and listed the results?

It would be interesting, yes. Though I’m sure the device(s) you’re talking about are beyond what I would be prepared to pay.

Last night I played audio through two different USB audio devices: a cheap “7.1 Channel Sound” interface with a Plantronics headset, and a pair of cheap Trust loudspeakers. Though not simultaneously! Maybe I should try that…

I didn’t have success with the iMic, though it was getting late so I wasn’t able to devote as much time to it as as I would have liked. But there is an interesting difference. The 7.1 and Trust devices have master gain controls. The iMic doesn’t; it has individual channel gain controls. Just another little bit of interest to add to the audio control system, whatever it shall be.

For anyone else who would like to try USBModule.zip now does isochronous in and out.

Dave’s pointed out a problem he has with changing volume whilst playing – advanced stuff :-). I haven’t looked into this yet but running my !USBDescriptors application while playing (which accesses control endpoints to produce the display) that didn’t cause a problem.

I’ve also tried streaming from a USB memory stick and that seems ok too.

I don’t see how these devices do 7.1 5.1 etc. the maximum packet size is 200bytes on my device given 48000 stereo is 192 bytes and you can only plug a 3.5 stereo jack into it I presume 7.1 etc. must be some sort of compressed stereo audio frame encoding.

Jim
The size of an audio frame is defined as the number_of_channels * bytes_per_sample.

The 200 figure is the maximum number of bytes (or maxPacketSize) which can be transfered over USB in 1 time interval (1ms). The number of bytes to transfer is determined by (frequency/1000) * frameSize which for 44100 16bit stereo is (44100/1000) * 4 which equals 176 bytes as you can’t have a part frame.

About feedback. There is none or at least it’s ‘Implicit’. Its an Adaptive endpoint with Implicit feedback so I think the clock rate gets controlled by the device. It may be that the device realises the packet size is short for 44100 and does something about it – anyway at this point in time I don’t see how I could do it any different. There must be some feedback somewhere but I think it is at the the hardware level – I’m guessing. It does sound better on my iyonix than when its on my pc laptop – maybe software processing on the PC is affecting things.

Dave. setting the bps to 180000 shows the effect of increasing the packet size.

For jim I should add that it sounds a lot better than I remember my iyonix sounding – prior to me frying the audio chip.

The 7.1 and Trust devices have master gain controls. The iMic doesn’t; it has individual channel gain controls.

Assuming as we’re talking about gain we’re talking about microphone input. Doesn’t the 7.1 device only have mono microphone input so the controls are set at the at the master setting presumably the iMic has stereo microphone capabilities? So you’d need controls for each channel.

Jim: the way isochronous audio works is that you send suitably-sized packets to the device every 1 ms (assuming full speed). The device doesn’t poll. It’s common for devices to be adaptive, which means they adapt their output sample rate to that of the bus, at least over a small range. Some devices adapt over a huge range – the iMic claims to work over a range of sample rates from about 4k to 48k. Under those circumstances you can see how important it is to keep feeding it at a regular rate.

This is why the asynchronous / isochronous mode that the better dacs use is important. Having the host control the timing can be a nightmare if you require precise playout. Its not just a matter of avoiding crackles, but of having the correct samples played with a uniform timespace interval between successive samples with no hiccups.

The DAC (USB soundcards) I’m referring to have their own internal buffers and request blocks (frames) of samples as and when they want them. This actually makes the job easier for the host as you simply write out blocks of data when requested, and even if there are short pauses due to interrupts, etc, they don’t affect the end-result at all. More like writing to a device that is saving to a file.

I’ll see if I can get a listing from something like an Arcam r-DAC and make the result available.

Jim

I was referring to the iMic’s feature unit on the output side. You’d expect it to have a master gain control, but no: it has individual channel gain controls.

(Audio engineers don’t talk about volume controls: they talk about gain controls.)

I’ve now got some details by using lsusb -v on a linux box that has a DacMagic Plus (USB DAC) connected. The details are at

Note this runs up to 96k and 192k (24bit) but I think I’ve set it in a mode that only accepts up to 96k, but uses an older and simpler interface. It expects to get values as 24LE packed into signed 32bit words.

Jim

I’ve now got some details by using lsusb -v on a linux box that has a DacMagic Plus (USB DAC) connected.

It’s a conventional USB Audio Streaming device. It doesn’t request blocks as it wants them; it has to be fed samples at a constant rate.

Jim. The device you list has a dedicated isochronous IN endpoint running in parallel with the isochronous (audio out) OUT endpoint to provide feedback on the number of bytes to transfer. The above module doesn’t cope with that but providing the latency between receiving information from the IN endpoint and modifying the data rate at the OUT endpoint isn’t a problem and 2 isochronous transfers don’t grind everything to a halt. it should be doable.

Only problem is I don’t have a device to get working.

I had read that Adaptive mode was the ‘modern’ way to do it but when it comes to high end audio the old ways are the best :-)

I don’t understand something dave.

If the audio out is stereo I’d expect 2 volume controls 1 for each channel – thats what I have on my 5.1 device. If the output device was mono I’d expect a master volume control and non indicated for the single channel. Similarly for audio in. Isn’t that what you have?

Jim. I should add that the only difference between sending 192k 24bit stereo and 8k 8bit mono is the size of the packet sent each millisecond.

Hmmm… just in the process of switching broadband from 02 as they don’t do it anymore. Its currently running at about half the speed it was this morning. Not happy :-(

If the audio out is stereo I’d expect 2 volume controls 1 for each channel – thats what I have on my 5.1 device. If the output device was mono I’d expect a master volume control and non indicated for the single channel. Similarly for audio in. Isn’t that what you have?

In the iMic there is a volume control for each channel (left and right) of the output pair. In the 7.1 and Trust speakers there is a master volume control.

On your stereo system at home, you have a single volume control. Probably also a balance control that you never alter. I would expect master volume on a stereo device; I was surprised to see individual controls.

From the descriptors you posted with your block diagram your 7.1 device is exactly the same as my device – details shown in the pdf I posted. It shows that Feature unit 9 which is the volume controls for the speakers has 1 control for each channel. Feature units 10 and 13 are for microphone volume and microphone mix volume and just have a master volume control because the are mono streams.

Only problem is I don’t have a device to get working.

Well my 300 quid ’Prize/ for getting this (asynch iso mode USB DACs where the DAC controls the timing, etc) is still on offer. 8-]

I did time limit it when I announced it ages ago. But I’m happy to still give it. The page is still up at

http://jcgl.orpheusweb.co.uk/ROAudioPrize.html

Would pay for a nice DAC, and leave some money over.

Jim

:-) Prizes/bounties feel a bit mercenary – wouldn’t cover the 5 months reading I’ve had to do to get this far anyway. I was quite happy teaching myself electronics at the time – your web pages come in handy. I blame Andrew Rawnsley.

In any case its catch 22, to win the prize I need the device and to get the device I need the prize. – only joking it was just an odd thought that came into my head.

Anyway I can implement explicit feedback isochronous as I think it should work and see what happens. Even when I get everything working on an Iyonix I don’t know if it will work with the other controllers. I haven’t had to change the controller drivers to get this to work so theoretically it should work for all. But it all depends on how well the other controller drivers are implemented. I have some confidence that EHCI will work as it is more up to date than the OHCI controller driver.

:-) Prizes/bounties feel a bit mercenary – wouldn’t cover the 5 months reading I’ve had to do to get this far anyway. I was quite happy teaching myself electronics at the time – your web pages come in handy.

Understood. The problem from my side is that I haven’t been able to offer enough to make it worthwhile in terms of pounds/hour for a professional! :-/
However rather than feel mercenary, look at it as a way to recover your costs for a DAC if you need one to do the tests.

That said, if you get something you think will work, I can then try it with the DACs I have and report back. If it works at least moderately well, I could then give you the cash to get a suitable DAC as an ‘thank you’ and encourage further progress.

Only side-comment I’d make is that I’m wondering if it came that far David might deserve a share. I don’t know the relative contributions in terms of what is involved, so I’d have to leave that for you and David.

David: would you care to comment on that? Afraid I’m in no position to judge the extent to which your work and Colin’s depends on each other’s!

I blame Andrew Rawnsley

I blame him for providing a machine whose internal DAC chip is pretty good already. :-) It has tended to divert me from the wider value of USB audio. If we crack that we can make it far easier for almost anyone with a wide range of RO hardware to get good audio without it being a struggle with the HAL every time!

Jim

I blame him for making a machine whose internal DAC chip is pretty good already

If I had an ARMinx and thought that, rather than trying to decipher what ROSS does I’d have unplugged the ROSS and poked around the hardware.

David: would you care to comment on that?

My contribution to getting USB audio going has been miniscule so far. Colin should have all the credit.

Colin: if you get the bounty and we ever meet, you can buy me a drink :-)

Feature unit 9 which is the volume controls for the speakers has 1 control for each channel.

Once again I sit corrected :-(

One interesting thing I discovered last night when reading the USB Audio spec again to work out how to set features, is that you can set controls of the same type on all channels with a single command.

I’m wondering how long it would take me to write a USB audio player app, based on the technology that Colin and I have developed. One of the hardest things to solve may be how to keep the buffer from emptying. At the moment, using the player that runs in a TaskWindow, things like reading email can cause the audio to pause and be replaced by a loud rasp. Clearly it can be done because DigitalCD does it; we “just” have to learn how.

Easy to background fill the buffer.

Use 128k buffer, Set threshold to 32k, fill buffer at start, use an upcall handler to intercept the buffer emptying upcall, match the buffer_id of the call to your buffer_id, if a flag is clear create a callback and set a flag that a callback has been registered -. In the callback fill the buffer and clear the callback flag.

To cope with multiple streams each stream’s data is in a linked list. The upcall handler searches the list trying to match the buffer_id. When a match is made a flag is set for that stream indicating that it needs filling. The way to use the callback is as described above.

The callback handler then goes through the linked list filling any buffers which have a fill flag set and clearing the fill flag.

If I had an ARMinx and thought that, rather than trying to decipher what ROSS does I’d have unplugged the ROSS and poked around the hardware.

The problem is that I don’t just want the ARMiniX/PandaBoard to work well. I want the option to be easily available for any new hardware RO is ported to without some poor sods having to rewrite all kinds of HAL cruft. In the process having to make guesses because the hardware makers keep vital details secret. (One of the main reasons the PandaBoard audio isn’t quite right is that TI keep the details secret for their own infuriating reasons.)

For me, the advantage of USB isn’t just that the DACs can be superb. It is also ‘portability’. When you move to a new RO box you should then be able to go on using a good DAC (or ADC) via USB without having to hope someone can sort out the HAL in a crazy situation like the above!

FWIW I’d like to be able to write/explain how to drive SoundDMA directly as this could bypass something I’m currently unhappy about. But I’m also wanting:

A) 24 bit – SoundDMA, etc, are resolutely 16bit at present whilst the PandaBoard DAC (and most decent USB DACs) are 24 bit as minimum spec.
We really do need this implimented sometime. Although for now, 16bit is fine.

B) Adding in somewhere ‘central’ the kind of user chosen resampling options I’ve shown can work. Again, simple methods can be OK, and a DAC can sometimes do better than any user software will. But this is another ‘generalisation’ issue like (A) to make choice of hardware easier.

The point of all the above being to get RO more up-to-date and give the user an easier choice ranging up to higher quality than before.

Jim

I’m wondering how long it would take me to write a USB audio player app, based on the technology that Colin and I have developed. One of the hardest things to solve may be how to keep the buffer from emptying. At the moment, using the player that runs in a TaskWindow, things like reading email can cause the audio to pause and be replaced by a loud rasp.

From my simple-minded POV I’d look at the DigitalRenderer / !DRplayer approach. I may ask Chris Martin about this… But I know he is busy with other things.

Jim