How to do USB audio

Whether you call them ‘Release 1’ and ‘Release 2’ or ‘Class 1’ and ‘Class 2’, they are still entirely different things from USB1 and USB2.

A good reason to steer clear of the term Class regarding USB is that USB uses the term specifically as reported by !USBInfo: Class & SubClass e.g. “Class 255: Vendor Specific Class”. Unless of course USB Audio devices do report themselves with !USBInfo as Class 1 or 2. Though even if manufacturers do so, as it is not formally defined, it can’t really be trusted, so is confusing.

I’d agree the terms are unfortunate. However the problem is that they crop up in the literature (and in the magazines) so will be what users will encounter. Not helped by different makers and examples which don’t all behave the same way despite being sold under an apparently similar ‘classification’.

e.g the Dac Magic Plus that now works nicely with my ARMiniX. (And so, I assume, would with a PandaRO). !USBinfo says it is Class ‘1 Audio’ but USB spec ‘2.00’ and also Release ‘3.21’. The user handbook talks about USB1 and USB2 as well as Audio Class 1 and 2. and this is common in hifi now.

So I fear the mess has already been made. Any usage is going to confuse someone and annoy someone else as being ‘misleading’.

This isn’t my first encounter with the terms used in two areas (computing and audio) having conflicting definitions. Just the most recent example of a long series… :-/

Jim

This is what I’ve found on the beagleboard so far – and it makes little sense to me.

This is playing from a USB hard disc

I can play 44100/2/16 no problem on a USB1 device
I can play 48000/2/16 on a USB1 device but it is marginal sometimes I get like a gritty noise which I put down to data not being available in time to send. Debug information during playing shows data being sent properly.

my USB2 class 2 won’t play. Symptoms are it starts playing then there is a pause then it starts playing again then a pause and so on this is the same form 44100/2/16 to 192000/2/24. On my Iyonix I get the same symptoms playing 192000/2/24 from the same USB hard disc the rest play OK. This again looks like the data is not being read from the disk fast enough. This ties in with usb1 being marginal at 48000/2/16 because the class 2 device has to sent twice as much data (32bit subFrameSize v 16bit subFrameSize of class 1)

So I did a disc test to see what the read speed was using OS_GBPB in a task window and its virtually the exact same speed as my Iyonix whether I fetch large chunks or small chunks.

Looking at the debug info from playing It tells me that the beagleboard is taking less time to do the USB interrupt processing than the Iyonix.

So the disc speed is the same and the processing speed is faster yet it still acts as if it is slower – as I said doesn’t make sense.

Regarding ‘Disc not found’ on shutdown after loading the modules. That is because the 5.20 rom image and earlier don’t have the latest DeviceFS and SCSISoftUSB modules. Old SCSISoftUSB modules didn’t shut down properly when they were RMKilled hence the error. The beagleboard 5.21 rom cures this.

The other thing that is puzzling me at the moment is that on the beagleboard the debug version of the modules freeze the machine if you try to list debug info in a taskwindow while playing, or after restarting after pressing f12. This doesn’t happen with the non debug version and it doesn’t happen at all on the Iyonix.

Anyway you may as well try the latest version USBModule.zip

You should be able to run this from the zip file with the zip file on a USB disc.

I can play 44100/2/16 no problem on a USB1 device
I can play 48000/2/16 on a USB1 device but it is marginal sometimes I get like a gritty noise which I put down to data not being available in time to send. Debug information during playing shows data being sent properly.

What you describe sounds very like the kind of behaviour I get trying to use the Halide Bridge on my ARMiniX. It gives the impression that something keeps interfering with the transfers except for the lowest byte rate ones.

Are you using the same buffer size in bytes for all rates and depths?

As I detailed earlier. I’ve tried going from 0.1 sec to 0.2 sec buffers (for all rates and depths) and it didn’t fix this with the Halide Bridge. Yet the DMPlus (using the USB2 approach) works fine up to and including 192k/24bit.

Could it be something like a part of the ‘chain’ likes, say, 4 bytes per value rather than 3? i.e. some specific detail is catching out a buried assumption?

Occurs to me that all my ARMiniX tests play files on the main (not USB) ‘hard disc’. I should try playing them on a card via USB to see if that banjaxes behaviour in a similar way. I’ll try it when I get a chance. Tomorrow I’ll also tidy up my prog and make it available for others to try if they wish and they can see if it behaves differently.

Jim

freeze the machine if you try to list debug info in a taskwindow while playing, or after restarting after pressing f12. This doesn’t happen with the non debug version and it doesn’t happen at all on the Iyonix.

Read the source to TaskWindow some time. It is seriously scary.

I’ve tried many buffer sizes even tried single tasking where the buffer size shouldn’t be a problem – it made no difference.

Could it be something like a part of the ‘chain’ likes, say, 4 bytes per value rather than 3? i.e. some specific detail is catching out a buried assumption?

Don’t think so. The exact same code is used on the Iyonix where it works.

In the class 2 case the beagleboard exhibits the same behaviour at 44100/2/16 as my Iyonix does at 192000/2/24 – ie pauses. I can understand my Iyonix eventually running out of steam at 192000/2/24 but expected a beagleboard to do at least 44100/2/16 in class 2

re class 1, class 2, usb 1, usb 2

I have a USB1 class 1 device, USB2 class 1 device and USB 2 class 2 device. I’d bet that you won’t get a USB1 class 2 device but i’m a rubbish gambler.

I have a USB1 class 1 device, USB2 class 1 device and USB 2 class 2 device. I’d bet that you won’t get a USB1 class 2 device but i’m a rubbish gambler.

So far as I can see, the audio literature uses a meaning such that ‘class 2’ requires USB2 to work. But I doubt all makers and vendors are singing from the same song-sheet on any of this. Witness the way some things work or not with no sign of any difference in what they tell you about the devices!

Don’t think so. The exact same code is used on the Iyonix where it works.

Ok, yes here the Iyonix gives a better result for the Halide Bridge than the ARMiniX with the same sorts of symptoms. Might this be in the ECHI/OCHI modules? (Can’t recall which one would be relevant so I’m mentioning both!) Or is this simply something odd about the hardware in each case?

Another thought. I’ve not tried using a different screen mode as well as not tried playing from USB memory device. Maybe something else is interrupting the process at an ‘awkward’ time. As I think I mentioned, I’ve had some odd effects when trying high rates with the Halide, as if something has become confused by trying to spin too many plates. Yet higher rates work fine with the DM Plus. Maybe this is telling us the DMPlus has better bufferring and handling so is ‘easier to drive’ in control and transfer terms.

Jim

You have this situation

1) USB 1 device plugged directly into an Iyonix
2) USB 1 device plugged into a USB1 hub plugged directly into an iyonix
3) USB 1 device plugged into everything other than iyonix or pi.
4) USB 1 device plugged into USB 2 hub plugged into any device other than a pi
5) USB 2 device plugged into any device other than a pi
6) USB 2 device plugged into a USB 2 hub plugged into any device other than a pi

1 and 2 use OHCI
3,4,5 and 6 use EHCI

EHCI has 2 ways of transferring Isochronous Data. High speed and Full speed split transactions

3 and 4 use Full speed split transactions
5 and 6 use High speed

If you have a USB 1 device and plug it directly into an Iyonix you use OHCI, If you plug into an iyonix via a USB 2 hub then it uses EHCI full speed split transactions.

So if someone says some device doesn’t work my thoughts are what doesn’t work OHCI, EHCI high speed or EHCI full speed.

Because your devices are switchable USB1/USB2 and some change class1/class2 and some don’t and I don’t know what mode you are using I’ll just say it can get confusing :-)

Release 2 devices can’t have volume or mute read or controlled correctly by the present USBAudio module. Releases 1 and 2 have very different layouts of the descriptors for Feature Units. One significant difference is that Release 2 provides 1 bit to show ability to read from, and 1 bit to show ability to write to, each of 15 possible functions.

Here’s my idea to change USBAudio’s parameter block to cope. I am requesting comment, so please read, mark, inwardly digest, and tell me what you think – including any better idea you might have!

The present definitions of the bitfields (each of 32 bits) at offsets +16 (volume) and +20 (mute) map bit 0 to the master channel, and bits 1 to 31 to channels 1 to 31 respectively, of the device. (Most devices only have up to 8 channels, so the remaining bits would be 0 in practice.)

I’m proposing to redefine it as bits 0 and 1 for the master channel, bits 2 and 3 for channel 1, bits 4 and 5 for channel 2, etc. up to bits 30 and 31 for channel 15. Bits 0, 2, 4 etc. show that the control can be read from; bits 1, 3, 5 etc. show that the control can be written to.

Release 2 devices would provide information to populate the bit vectors correctly. (Note that Release 2 requires that, if a control can be written to, it can also be read from.) Release 1 devices can’t, so I would have to guess at a value, and I would expect to say that the controls can be both read from and written to.

OK, that’s the full nitty-gritty. Most application writers would, I expect, just pass the appropriate bit vector, read from the parameter block (which is filled in automatically by a call to USBAudio_OpenOut or USBAudio_OpenIn), to the calls to GetVolume, SetVolume, GetMute and SetMute; this normally treats the two channels identically. Think of turning the volume up or down on your stereo system; you take it for granted that both channels are controlled identically.

I’ve got a Class 3 device.

Ok You’ve got more class.

Reading frequency on usb class 1 release 1 devices doesn’t seem very popular.

Reading frequency on usb class 1 release 1 devices doesn’t seem very popular.

Reading the current sampling frequency?

If that’s what you mean, I agree. In fairness, it must be difficult on adaptive devices, because it depends on the rate you’re sending data to the device. But that wouldn’t apply to devices with two or more fixed sample rates.

For devices with only one sample rate, I guess they simply wouldn’t bother to implement readback.

Because your devices are switchable USB1/USB2 and some change class1/class2 and some don’t and I don’t know what mode you are using I’ll just say it can get confusing :-)

The DMPlus has been set to ‘class 2’ for many days now. I’ve avoided switching it back to ‘class 1’.

I think that both the Halide Bridge and rDAC are ‘class 1’. But I’m saying that because they are relatively old, and won’t go above 96k. Is there a way to get this clarified using your/Dave’s swis? In the interim I can use !USBinfo and report what I get from them.

Here’s my idea to change USBAudio’s parameter block to cope. I am requesting comment, so please read, mark, inwardly digest, and tell me what you think – including any better idea you might have!

My main comment is that I’ll probably have to re-read what you wrote a few times to decide if I understand it. :-)

My immediate question is: Would that mean that what I’ve written thus far would cease to work (when it does now work!) unless I add more things to the register values I give when making the calls?

I’ve got a Class 3 device.

Oh, expletive. ;-> I guess we should have seen that coming given USB3 as well. Have they come up with yet another totally differ set of transfer protocols for LPCM? Or is this just to cover things like non-PCM transfers?

Jim

I’ve used !USBinfo to get as much detail as I can on the three DACs I’m experimenting with. The lists are too long to put here so I’ve put a zip at

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

Results obtained with the rDAC and Halide bridge connected to one of the front USB sockets on my ARMiniX. The DMPlus is connected to the other front socket but via a USB2 hub. (In tests over the last few days I’ve tied the other two direct and via the hub, and it made no difference to their behaviour as reported.)

However – as I thought – the rDAC and Halide Bridge are ‘USB1’ devices, so I assume they are ‘Class 1’. So far as I know this can’t be changed. And I’ve had the DAC Magic Plus set to ‘Class 2’ for a long time now.

Jim

You have to laugh.

What I am interested in is whether the device is a USB 1 device or a USB 2 device. What Dave is interested in is interested in is whether the device is release 1 or release 2. You are interested in class 1, class 2. Dave’s release 1, release 2 is the same as your class 1, class 2. Dave is using the proper terms but you are using the terms you would use to buy a product because everyone in the audio world say class 1,class 2.

From the descriptors you posted

DMPlus is USB2 (speed = Hi-Speed) release 2 (interface protocol = 32 (0×20)) – this is your Class 2 (because it is release 2)

Halide Bridge is USB1 (speed = full speed) release 1 (interface protocol = 0) – this is your Class 1 (because it is release 1)

rDac is USB1 (speed = full speed) release 1 (interface protocol = 0) – this is your Class 1 (because it is release 1)

So from my experiments I’d expect the DMPlus to fail with a pulsing of the music (plays some then a gap repeatedly) the other two fail with the sound being noisy (gritty)

So from my experiments I’d expect the DMPlus to fail with a pulsing of the music (plays some then a gap repeatedly) the other two fail with the sound being noisy (gritty)

The results you comment on are why I started saying ‘Release/Class/USB N’ because they seem to tend to go together in what I’m using. However given the way computer-gear makers behave I don’t doubt almost anything will crop up! Particularly when you’ve not been able to take it into account. :-/

In practice the DMPLus works flawlessly now, the rDAC stays silent, and the Halide works at 44k but not at higher rates where it crackles or can – for the higher rates – also give gaps and pauses.

Jim

Ok, I’ve now done a version of my test/demo prog and dared to make it public. You can find it at

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

Anyone interested it welcome to have a look at it and – if they dare – give it a try. READ THE HELP FILE FIRST. Its very very much experimental and I’m a rubbish programmer. So there are all kinds of reasons to be wary of it. However it should give others a chance to see what I’m using for my tests and learning. And if very lucky may even play music for them without setting fire to the cat. I’ve not tidyied up the source code which I’ve included. Anyone is welcome to do something better or use/modify any part of it that they happen to find useful. Enjoy at your own risk. :-)

Jim

You have to laugh.

I wish I could. I spend more time with my head in my hands.

My immediate question is: Would that mean that what I’ve written thus far would cease to work (when it does now work!) unless I add more things to the register values I give when making the calls?

As far as I can see, it would make no difference:

• if you didn’t attempt to use SetVolume, SetMute, GetVolume or GetMute, it can’t possibly make any difference;

• if you did use any of those calls, but only used them in the way I suggest in the USBAudio API discussion document, I believe it won’t make any difference. That is the intent.

Is there a way to get this clarified using your/Dave’s swis?

As before, use ModuleTest1. It’s still there. Please post the results.

Unfortunately, the files in your threedacs.zip file are very difficult to work with, because they are partly textified and the binary information is only available by reversing the textification – a laborious and error-prone manual process. If you use Moduletest1, the result is in almost raw form, which I can feed into the USBAudio module to see how it reacts.