How to do USB audio

One interesting thing I discovered last night when reading the USB Audio spec again.

I sit in awe of the people who design the protocols and write the specs. Take the short section on data returned from feedback endpoints. I’m thinking it’ll just tell me the number of bytes per packet to send – which is all I can change. But no it returns a 3 byte fixed point number where the top 10 bits are the number I want and are the only ones required to be sent, but you are left wondering what was the designer thinking when he thought a fractional part would be useful. I could do without loose ends to think about.

As far as the rasp is concerned I can probably silence that. It happens because the correct number of bytes are sent even if the buffer is empty. The noise is the undefined value of these bytes. Background filling is preferable but it can be useful to prototype in basic so its probably best to silence the rasp. You could also just leave the endpoint open and feed a playlist. Instead of silencing the empty buffer I could add a gentle crackle to give the real vinyl experience.

I could add a gentle crackle to give the real vinyl experience.

Oh good grief! Don’t go there if you value your (remaining) sanity… 8-]

Jim

I claim my Ciunas DAC – cos it sounds like vinyl :-)

I claim my Ciunas DAC – cos it sounds like vinyl :-)

In my experience what matters wrt “sounds like vinyl” is more a matter of how a given CD / file was produced. Modern pop/rock/etc CDs and files tend to be level compressed and “improved” by dimwits at the media companies.

I’ve made safety/convenience copies to flac (usually 48k/24bit) of various LPs. So far as I can tell, they sound indistinguishable from the LPs when played, and save wear and tear.

FWIW I’d have thought you’d be better off with a Dragonfly or one of the new Meridian USB DACs. Lower price, arguably better made, etc, and both fairly street cool amongst audiophiles. Meridian are one of the top designers for audio kit. However these things are very much a matter of personal preference. (That’s one reason I want user choice wrt upsampling.)

WRT DAC testing: I’ll leave it to you/David to say when I should start experimenting with the software you’re developing using my own DACs and ARMiniX. I can in the interim get back to adding info to the ROSS documentation. (CD Audio is next on the agenda.) For reference I have a set of USB DACs that all support the now-standard asynch/iso mode.

Jim

I don’t intend this to be a big diversion – if it is, I’ll start a new thread – but some of the USB audio interfaces have buttons, e.g. to mute input or output, and to increment and decrement the volume. The buttons appear in a HID.

How does one associate those control buttons with controllable functions within the unit? How would we do so within RISC OS?

How does one associate those control buttons with controllable functions within the unit? How would we do so within RISC OS?

In (ideal) theory any such controls would be handled by an extension to the SoundControl module and you’d have a *MixVolume setting for them. Which in turn could be used by applications or !Boot.

[This is why I think we’ll eventially end up needing an ALSA-like scripting to allow users to determine these things when input/output devices can be added/changed/removed by users.]

At present, in practice, I’d say “however suits you and Colin”! :-)

And for simplicity (and quality) I’d tend to start from the basic assumption that all gains are unity unless there is a specific reason to choose something else.

To some extent you can regard that as akin to a distinction like that between PlaySound (the application) and PlayIt (the module). In essence, PlayIt operates the sending of the audio. PlaySound gives controls.

Jim

Dave. I can’t replicate the crashing when changing volume while playing are you plugging in to a hub?

USBModule.zip

I’ve updated the module to be silent when the buffer empties and you can change the volume while playing with the up/down keys. This works for me. Does it work for you?

Edit: I couldn’t get set ‘all channels’ for volume control to work on my device could you?

Jim.

Would you mind plugging in your DACs into your Arminx, run USBDescriptors.zip and post the results for me to collect. The program will list the USB descriptors for all devices plugged in in a task window.

Would you mind plugging in your DACs into your Arminx, run USBDescriptors.zip and post the results for me to collect. The program will list the USB descriptors for all devices plugged in in a task window.

The URL won’t resolve here. Although your USBModule.zip one in the previous posting does.

Jim

The URL won’t resolve here. Although your USBModule.zip one in the previous posting does.

Got it OK! I tried changing the name to USBdescriptors.zip and using that name directly with NetSurf. For some reason NetSurf objects to the link. Maybe the case of the ‘D’?

Jim

Here is the result of running USBDescriptors. I plugged an Arcam rDAC into the front left-hand USB socket of my ARMiniX and ran the program.

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

The above links to a zip of the resulting text.

If you want me to do this with a different USB port, or with other DACs please let me know.

Jim

Not sure this is relevant but just in case…

Before I ran the usbdescriptors program I was working on a ‘demo’ prog for the ROSS documentation. This is to show how to use the CD_ SWIs to read audio from an Audio CD. After running the USBDescriptors I found that PlayIt ceased playing audio although PlaySound showed the progress thermometer, etc, OK. I did a shutdown and restart and all was well again.

This may be something else. e.g. having increased the size of the data block I was grabbing from 2 sec to 5 sec I’d had a run fail because the wimpslot was too small. Dragging up ‘next’, it then ran OK. Maybe that did something odd. But I’m reporting this just in case.

Jim

I’d used ‘,com’ instead of ‘.com’ sorry about that.

You said that you had a number of DACs do you know that they work the same way?

You don’t happen to know the cheapest DAC with Asynchronous USB I only want one to test with at the moment – don’t bother about it if you don’t know.

I’ve been looking into beagle board and noted, as we have said before, that it doesn’t do OHCI – EHCI is designed to pass full and low-speed devices on to OHCI. But apparently this deficiency of the board (I read that some pin on the root hub chip isn’t connected) is worked around by plugging full/low-speed devices into a separate hub. Obviously it works as you can use the keyboard which is described as being full speed. I expected them to be slow-speed as keyboard and mouse are described as slow-speed on an Iyonix. Maybe EHCI only emulates full speed OHCI I haven’t read that far yet :-) This is all academic but out of interest were the keyboard and mouse specially selected to work or do you think you can use any old keyboard and mouse.

Wimpslots – forgot about them I run 4096k ones by default.

!USBDescriptors only reads string descriptors from a usb device in the standard way. Really very basic stuff. All USB devices use the same call all the time. So basically it seems odd that something was affected.

EDIT: odd it should need a bigger wimp slot. The file is only 67k and the program 24k

You don’t happen to know the cheapest DAC with Asynchronous USB I only want one to test with at the moment – don’t bother about it if you don’t know.

The ‘cheapest’ I currently recall are in the 200 quid range, so only ‘cheap’ compared with the ones that ‘high end audiophiles’ consider! However I’ll ask about and see if I can suggest something.

So far as I know, all the ones I use or have tested use the same asynchrnous / isochronos interface which is now included in most mainstream Linux kernels and the MacOS one (quasi BSD I think).

odd it should need a bigger wimp slot. The file is only 67k and the program 24k

Sorry, I think I wasn’t clear. The problem I had was with the program I was working on. This grabs a series of CD audio ‘frames’ from the CD in the drive. I’d increased the grab from 2 sec to 5 sec long which required a bigger buffer in the program. Which took it over the usual default slot size assigned by ‘next’. My prog, not yours.

Jim

I’m looking to see if there are subtle differences so it would be handy to see descriptors for all DACs – plug them all in at once if its easier.

I’m looking to see if there are subtle differences so it would be handy to see descriptors for all DACs – plug them all in at once if its easier.

OK. one at a time is probably easier from my POV. I’ll do a few more and put up the results when I get a chance.

The thing to look for is being told they are “Audio Class 1” “Class 2”. (These are audio classes NOT the USB ones.) Class 1 means a now established open standard. Class 2 is that plus a newer (also open) standard that goes above 96k/24bit. Almost all ‘Class 2’ DACs also operate in ‘Class 1’ mode as well if needed. And in practice ‘Class 1’ is fine for most people. So far I’ve never bothered with ‘Class 2’. What this should mean is that anything that says it is in these classes should be pretty similar wrt driving.

WRT knowing what’s about and something more ‘affordable’ I don’t have any full list. I’ll check recent magazines when I can. But here are a few URLs that may help one way or another. Note that many of the items on offer are at prices that are steep for those not obsessed and dedicated. But there are some cheaper ones about. Alas, they tend not to get so much publicity on audiophiles sites/mags as the costly kit tends to attract the big reviews.

http://www.diyaudio.com/forums/digital-line-level/231138-asynchronous-usb-dac-clock-source.html

http://www.audiostream.com/category/dac-reviews

http://www.audiostream.com/content/musical-fidelity-v-link-usb-spdif-converter-specifications

http://www.thewelltemperedcomputer.com/KB/USB.html

http://thewelltemperedcomputer.com/HW/USB_DAC_Async.htm

The V-Link series has a good reputation at ‘low’ (sic) price. But I don’t have one and haven’t tested one. That said, maybe this is a good excuse for me to ask MF if I can borrow one to test. :-)

Jim

OK, here are the results for two more devices.

http://jcgl.orpheusweb.co.uk/temp/2dacs.zip

Halide Bridge = A USB to SPDIF convertor. This is slightly different to many as it doesn’t do any digital to analogue conversion. Just controls the clocking and buffering to give you a clean spdif output from a USB port. It uses the ‘Wavelength’ process internally which many of the most costly devices use, but is still Class 1/2.

DMPlus = Cambridge Audio DacMagic Plus. This is a very good Class 1 / 2 DAC that I have beside the ARminiX because that and my main Linux box share items via USB and use the same monitor. So it was easy to connect temporarily to the ARMiniX.

The only other USB DAC I have at present is a Cambridge Audio 851C. However that is wired into my main hifi setup in another room so not so easy to connect to the ARMiniX. It is also a development version so may not be exactly like the ones on sale. (I got it from them whilst the 851C was being developed before going on sale.)

Jim

Thanks Jim.

Any class 2 devices? Don’t see what is class 2 about dmplus it is practically identical to Halide bridge as far as USB is concerned. I know you said that these are Audio classes not usb classes but welltemperedcomputer says

Another common misunderstanding is the specification of the bus (USB 1,2 or 3) and the USB audio standard (1 or 2).

and then goes on to say.

Class 1 is tied to USB 1 Full Speed = 12 MHz

Class 2 uses High Speed (480 MHz). This requires USB 2 or 3.

Where is the confusion? Class 1 audio is USB1 specification and class 2 audio is USB2 specification. All the devices you’ve showed me are full-speed (USB1). You need class 2 drivers for class 2 devices because they use USB2 and that has a slightly different system.

Any class 2 devices? Don’t see what is class 2 about dmplus it is practically identical to Halide bridge as far as USB is concerned.

The DMPlus – and other Cambridge Audio – DACs I’ve tried/used give the user a switchable option to limit to Audio Class 1 or include Class 2. I normally have everything Class 1 as it is the older class (so supported by more Linux kernels) and it only limits me to 96k/24bit. Which is fine for me as I don’t have much personal interest in using the higher rates.

One of the reasons for the old Class 1 was to ensure working via older USB1.×. I can’t comment on the USB class side as I don’t understand it. But my Linux boxes all support USB2, and one also USB3. Beyond that, I’m sure you’ll understand it better than me!

FWIW if it is useful I’ll see if I can find out how to change the class of the DMplus and then get the description again, etc, in that mode. I did know how to do this, but will need to find the details as I’ve forgotten. Its one of these “switch on whilst standing on one leg and thinking of a horse” processes. It then flashes its LEDs to tell you it understood.

Jim

Don’t worry Jim. If I get class 1 working it’ll be a start

Don’t worry Jim. If I get class 1 working it’ll be a start

Yes, in fact it will be excellent. :-))

FWIW Class 1 is the entry ticket as it suffices for pretty much all the standard DACs unless you want above 96k/24, which only a small minority require. And so far as I know, all the DACs that say ‘Class 2’ can also handle Class 1 as their fallback. So the pool of devices is wider for Class 1.

And AIUI Class 1 and Class 2 do use different transfer protocols. Not just a matter of USB ‘speed/mode’. But I’m just going on what I’ve read. Don’t understand the USB details at all!

Jim

Colin has found the root of the problem that causes poor audio when attempting to replay properly at 44100 Hz, i.e. using packet sizes of 176 and 180 bytes. The solution, though, is not obvious. I’ve got analysis software and hardware waiting to check out the next code drop.

Jim: where are these audio classes 1 and 2 defined?

Here it is then Dave USBModule.zip. Sounds even better at the correct speed. Be interesting to see if your analyser matches my ears.