How to do USB audio

vid/pid/version identify a device in the absence of a unique id supplied by the device. This will separate different versions of the same device.

So we are left with separating identical devices so I’m proposing vid/pid/version/location to identify the device. location is only used to separate 2 devices with identical vid/pid/version.

But if I’ve misunderstood, or there’s a better idea, I will happily accept it.

I don’t think the idea is to assume that the VID/PID are genuinely unique. But the hope is that they will identify a specific device the user has. So allow them to choose to ’always to use my DAC to play audio> even if events change its USB device number.

At present I’m experimenting with searching for a device name string for this. That does at least have the advantage of being more ‘human recognisable’ in that I can expect a user to understand that they’d need to put something like “Cambridge Audio…” into a setting file rather than two arkane numbers. But some strings may not make this easy. e.g. The UCA202 returns strings wil some spaces padding the end. And some may have other ‘quirks’ or not be unicode.

For the programmer the simplest way to do this is by device number. Problem is that these deckchairs get shuffled. So the ‘unique’ here is for the user’s systems, not universal, I suspect. If someone has three DAC Magic Plus devices they might have to resort to some other method. ;-]

Jim

Jim I think the Device/product name is meant to be put on a menu like *usbdevices from there the user can choose the device and your program converts the selection into some device id that can be saved. The names themselves are not enough. With every other cheap device being C-Media electronics you may have the same text name on different devices.

I can play 48000/16/2 on the BBxM from USB spinning rust without interruption – also over ShareFS from a file hosted on the Iyonix’s PATA spinning rust.

Dave thats good to know. You can claim the first streamed USB audio over a network :-)

With every other cheap device being C-Media electronics you may have the same text name on different devices.

Agreed. So the question is what method is ‘best’? Alas I suspect what would be ‘best’ for some people and circumstances will differ from what others would think ‘best’. From the programmer’s POV using VID/PID/devicenumber is easiest I guess. Maybe it could be based on using usbdevices and asking the user to nominate.

Again, how much this matters is another question. Chances are most user will have one USB DAC, and that’s it. So I suspect we’re worrying about the special cases – nutcases like myself who may want a number of devices for different purposes, sometimes in combination. In the end, that would make devising a setup and software my problem. All of which is why my initial demo player just uses the first device in the return given by EnumerateDevices. The easiest bodge then is to have a number to specify by USB. But would VID/PID/number be a useful alternative?

Jim

At this point my feeling is that I should shift my own attention to looking at generating a simple ‘recording’ demo/test program to help me ensure I know how that works. Once that is done I plan to move on to starting to write something more on user documentation about USB Audio that would fit into the ‘ROSS Document’ which aims to cover RO audio. Although I’ll also write an ‘Archive’ article and a webpage explaining how others can get experimenting/using.

I will also try to bugfix the Probe and Player programs I’ve done as test/demos if I can get feeback I can understand! :-) But I guess that the best idea now is if one or two people can write a more user-friendly desktop player which will seem to users more like !PlaySound or !DigitalCD. That’s probably way beyond me!

During the next week or so I also have to write an article about something else. But once that is done I’ll come back to my main focus being the RO USB Audio again.

And I guess I’ll be asking my usual daft questions every now and then as I struggle to get things clear enough in my mind to let me write clear descriptions for others to read and learn. ;→

WRT recording, though, can I expect that a program would be able to record and playout ‘symultaneously’? That would be useful for some purposes when making audio measurements or for monitoring a recording. Is this essentally just an ‘enough bandwidth’ question? Or is there a snag? (Apart, of course, from my dimness wrt how to write a suitable program?)

Jim

can I expect that a program would be able to record and playout ‘symultaneously’?

Weren’t we here just days ago? The answer is Yes in principle. You need enough bandwidth and processing power. That’s it.

I’m not convinced that RISC OS is optimal in terms of buffer shuffling, i.e. we copy it from A to B, then from B to C so that it can go out. I would like someone to prove that it’s better than I think; but we have to copy from e.g. disc storage to a buffer, then I believe we have to copy from there to another buffer from where the USB device gets the data to be transmitted. It would be more efficient if we could cut out the middle step.

Dave: Afraid I can’t comment on the buffer methods. It would be nice from the POV of a programmer as simple-minded as myself to get as close as possible to behaving like the ‘everything is a file’ a’la Linux. However the other side of that is that I’d really also like to have more RAM available for ramdisc. This seems at present to be nailed to a maximum of 128M. They you can imagine almost a “cat ram:audiofile/wav > USBaudiodevice” doing the job. 8-] The point being to make as much as possible invisible for the user. But no doubt the system would still be spinning plates behind the curtains…

One question wrt swis:

At present when I want to play a file I have to basically find out two facts.

1) Can device ‘USBXX’ play a given sample rate, number of channels, and sample bitsize?

2) If that answer is ‘yes’ I then need “How many bytes per sample for the transfer frames?”

At present I have to work though the results from the Enumerate swi to see if I can find a suitable match.

So the question is if it might be sensible and worthwhile to have a swi which you give USBXX, samplerate, numberofchannels, bitspersample, and it returns a yes/no and – if a yes – the number of bytes per sample (framesize) for each sample transfer. I guess it would also need a play/rec flag at input to deal with devices like the UCA202 and avoid it giving the results for the wrong transfer direction. In practice only one number need be returned as a ‘0’ for the transfer size would mean “nope! can’t do that”.

In essence I assume that would just move the ‘search’ process into USBAudio rather than have the program doing it using the Enumerate results. Would this be sensible, or would it be inconvenient or difficult? I’ve got my programs working without it, so it clearly isn’t essential. But it might be nice for programmers coming to write other programs.

Jim

a swi which you give USBXX, samplerate, numberofchannels, bitspersample, and it returns a yes/no and – if a yes – the number of bytes per sample (framesize) for each sample transfer.

I could do something like that; it would have to return a list of numbers of bytes, because we cannot assume that there is a unique result. A null list would mean no match.

The list only needs to be a list of bytes, and would be zero-terminated.

USBAudio_EnumerateSubframeSizes?

The purpose of the call is to uniquely identify the device or fail.

This, perhaps, depends upon your definition of “uniquely identify”.

I plugged a USB SD reader in and the USB device system variable (and I presume the device ID likewise) was:
USB$Device_00_00_00_14CD_121C_-1_-1_0300_USB7 : 7
I removed it and plugged it in to a different port, and the sysvar became:
USB$Device_00_00_00_14CD_121C_-1_-1_0300_USB8 : 8
While there is a complication in that the SD card media could be different, as far as the device itself is concerned, “00_00_00_14CD_121C_-1_-1_0300” ought to match this device.

It would fail if you swapped sockets of identical devices.

Interesting. If you have two identical devices and you swap them around, is it really a “failure” if the software does not detect this in lieu of any other indications as to which device is which ?

If you don’t have identical devices it will survive plugging into a different socket.

Ah, good. If I have a program that talks to such-and-such a device, I don’t want it to freak out if said device is plugged in to a different USB port (or via a hub). I would prefer if it just found the required device and got on with things.

Might be it safe and sensible if programs that play/probe/record send a reset before they get started as a general rule?

Worth trying. Perhaps another benefit of a reset (and possibly an explanation to the symptoms seen) is that you cannot tell what state a device in use was left in.
To give a short example, my parallel port IIC interface sends two STOPs¹ when it starts up (hehe which crashes the old DeskJet if it is plugged in!) because you cannot guarantee anything about the IIC state – it could be frozen in the middle of a data transfer. Attempting to use it in this state would be Made Of Fail, so STOP STOP will bring it back to a known, working, state.
As we’re still in development stage – I’d say suck-it-and-see. Reset the thing prior to use, see if this makes problems go away, or not?

¹ You should only need one STOP, but one of the teletext chips (CITAC) sometimes wouldn’t respond until I’d hit it with two. That was old (the newer tuners don’t use the separate CITAC chip²) but the STOP-STOP hung around. It also felt very deliberate, like you will submit!

² Actually, “newer tuners” don’t support Teletext (or analogue TV) at all, but that’s a whole different cupcake flavour… ;-)

Rick.

USB$Device_00_00_00_14CD_121C_-1_-1_0300_*

That does match the device in its unconfigured state – there’s another one created after the device has been configured but what happens if you use 2 identical devices? You will see:

USB$Device_00_00_00_14CD_121C_-1_-1_0300_USB8 : 8
USB$Device_00_00_00_14CD_121C_-1_-1_0300_USB9 : 9

Now you make one of them the boot device how does the computer know the one to use next time you switch on?

Turns out not to be a problem for storage devices as they have a serial number embedded in the descriptors.

Audio devices do not have a serial number so the only way to choose between 2 identical devices is the position of the device on the device tree – ie where it is plugged in.

Interesting. If you have two identical devices and you swap them around, is it really a “failure”

Well it is in so far as it isn’t consistent with having different devices. If I have usb headphones and usb speakers plugged in and configure the computer to play through the speakers switch off and swap them round the computer can still find the speakers. If instead I have 2 identical sound dongles with analog speaker in one and headset in the other after switching off and on the computer doesn’t know which is the speaker.

Re USB sound on Pi:
It seems the hardware can do it! :http://learn.adafruit.com/usb-audio-cards-with-a-raspberry-pi/instructions

Jim, yes I was using your latest probe program at the time, and it uses the hex defines.
Replugging the devices is no cure. The earlier CMedia device is a single speed 48000 and it doesn’t get found either.

I cant try your player unless I recompile it as it wants a file in SDFS:Armini etc.
With !GCC if you dont specify a path you can then use the CSD which allows you to move from directory to directory for tracks easily.

Chris

Yes I said linux have isochronous working – I think they have moved the interrupts to fiq. Scanning through a thread on the pi website it has problems – basically limited to 44100/16 (probably because you can do that in a single microframe) with virtually no other periodic transfers (keyboard/mouse etc) or anything happening but it can work. Asynchronous has problems because it needs 2 isochronous endpoints simultaneously. Its an on going project.

I /think/ the RasPi outputs s/pdif on HDMI, but you need a decent HDMI switchbox that can decode/decipher it from the composite HDMI. There is a box in USA on Ebay around $40 that probably can do it, but it is only s/pdif no DAC. Some TV’s may be able to output the digital audio in both forms, I dont know. I’d put my money on a DAC chip that you have the specs for, and get high quality analog output as well as s/pdif. I think the connection on the RasPi has involved a kernel to support the i2s? or whatever, so it probably is a tight working space.

Edit: A modern Surround amp with the HDMI in and out should be able to do this task, in fact I think that’s what they are for. (-:

I could do something like that; it would have to return a list of numbers of bytes, because we cannot assume that there is a unique result. A null list would mean no match.
The list only needs to be a list of bytes, and would be zero-terminated.
USBAudio_EnumerateSubframeSizes?

I think that would be welcome. It seems to be something most programmers working on playing or recordings would find useful. So yes please if you’re happy to add it.

Jim

I cant try your player unless I recompile it as it wants a file in SDFS:Armini etc.

Edit the ‘Settings’ file inside the application directory. That’s what tells my player where to look for files to play.

You say you are using the latest versions of my progs. Can you confirm you’re also using the latest version od Dave’s module? It won’t work with earlier versions. If it still doesn’t work, can you report what my USBAudioProbe outputs? Note also that my UCA202 needs a usbreset to ensure it will work if it was plugged in when Colin+Dave’s modules were installed, so you might also have that problem.

It might also be useful if you could use Dave’s moduletest or !USBDescriptors so we can see details of the device you’re using. I can’t recall what it is. The problem might be that – like an example Dave has – it uses a ‘range of frequencies’ rather than specific rates. My progs aren’t yet able to cope with that as I don’t have such a device to use for tests of any code changes I make.

Jim

I /think/ the RasPi outputs s/pdif on HDMI, but you need a decent HDMI switchbox that can decode/decipher it from the composite HDMI. There is a box in USA on Ebay around $40 that probably can do it, but it is only s/pdif no DAC.

IIRC you can also get spdif-from-HDMI breakout boxes from Keene or CPC. I looked at this ages ago when I wondered about getting an RPi. The lack of decent audio output was a factor that put me off getting one.

Jim

but you need a decent HDMI switchbox that can decode/decipher it from the composite HDMI. There is a box in USA on Ebay around $40 that probably can do it, but it is only s/pdif no DAC.

$40!!!!????

Eeek!

No idea what this is, in technical terms. All I can say is that it is what I bought and it works on the Pi, both video and audio. What arrives is slightly different to the picture (audio out is on the back, not the side, but did I mention that it works with playing MP3s in RISC OS?).
http://www.ebay.fr/itm/Cable-Adaptateur-Convertisseur-Mini-HDMI-Male-vers-VGA-Femmelle-Audio-/271221914443?
Price? To France, €2,99 plus €8,99 P&P.

To England? http://www.ebay.co.uk/itm/Cable-Adaptateur-Convertisseur-Mini-HDMI-Male-vers-VGA-Femmelle-Audio-/271221914443?
Will be currency converted. eBay reckons £2.46 with £7.41 P&P.
Either way, it’s “about a tenner” for it.

Note that you will also need this for the Pi/Beagle: http://www.ebay.fr/itm/Gold-Plated-HDMI-Male-to-Mini-HDMI-Female-Connector-HD-TV-Converter-Adaptor-HDTV-/320822991617?
A quid fifty for it, plus another pound for P&P (or appropriate Euro conversion).

I did find a nice little HDMI dodah with audio and an itty-bitty HDMI plug. Cost twice as much. Better value for money to buy an adaptor (plus it’ll fit into my it-thinks-it-can-do-HD DVD player).

When you have it, read this: http://www.heyrick.co.uk/blog/index.php?diary=20130729 ;-)

No idea what this is, in technical terms.

“On-chip audio decoder which support 2-channel DS and SPDIF audio outputs.”

http://www.boomtek.com.cn/en/product_detail.php?ProId=13

Rick, On your modded adapter, Is there any useable number on the DAC chip in front of the analog audio socket?
Also how do you find the audio, noticeably better than the on board blue audio out? (Pi)

Jim, there is nothing special in the output of your probe program, just 0’s. I /did/ say I tried the single speed C-Media with no improvement.

Eben has stated that the 3.5mm jack output is very poor quality and recommended HDMI sound where ever possible!

Googling:‘raspberry pi analog sound quality’ was quite informative:
Poor quality PSUs can produce popping when no/quiet sound
also http://www.electronicsweekly.com/news/design/embedded-systems/getting-hi-fi-sound-from-raspberry-pi-2013-07/

On your modded adapter, Is there any useable number on the DAC chip in front of the analog audio socket?

I’ll just describe everything, since I have it opened up (with the Pi and video still running, hmmm!).

The board says: REV.A PCB-HDMI-VGFAU-CB02 2012.09.26

The main chip is a Lontium LT8511A.
Beside this is a thing marked “27.085”, I’m going to assume it’s an Xtal.
The other chip on this side is an ST 8S003F3P6, which is a basic microcontroller which runs at 16MHz, containing 8K flash, 1K SRAM, and 128 bytes E2PROM, plus 5×10bit A/D, along with some stuff like serial I/O, etc. CPU is an STM8 core. Looking at bits of the circuit that I can see, this may be for probing the capabilities of an attached VGA device.
The itty-bitty audio chip is an ES7144LV (took an epic bright LED torch and two magnifying glasses stacked in order to read that!). It supports up to 200kHz sampling rate with an I2S audio data format of 16-24 bit. It auto-detects the input data format.
The final piece of the puzzle is an Atmel 24C08AN, an 8K (1024×8) two-wire serial EEPROM.

Also how do you find the audio, noticeably better than the on board blue audio out? (Pi)

Can’t tell you. Is there a ‘hack’ to make the audio appear on both the on-board output and the HDMI?

What I can say is:

“Shell” (Bana; Witch Hunter Robin OP) → This is my reference track for evaluating new headphones/earphones. When the bass guitar kicks in at +13s, you will instantly know if the things stuck to your lugholes are any good.
“Topology” [to-po-ro-jî] (Itô Kanako; Robotics;Notes ED#2) → this sounds nice and clear.
“You Were The Wind Of Summer” (Daichi, part of the “(Dear) You” Higurashi collection) → the loud and quiet parts of this song were both handled competently, with nice stereo separation.
“Sparkling Daydream” (Zaq – Chûnibyô Demo Koi ga Shitai! s1 OP) → sounds good too.
All MP3, 44kHz stereo, 320kbps, played using !DigitalCD, while a 1280×1024@75Hz display is being sent down the same data link.

This isn’t to say the onboard sound would be “worse”, or even if I’d notice. Given my equipment, I rather suspect that it would require something akin to Jim’s spectrum analyser to highlight any deficiences in either case.

So… I’ll just say… Sounds okay to me.

Jim, there is nothing special in the output of your probe program, just 0’s. I /did/ say I tried the single speed C-Media with no improvement.

A set of 0’s is what I get from the UCA202 if it is connected when Colin+Dave’s modules are installed. I have to either unplug it and connect it again or do a usbreset <number> to clear that. If I don’t, it won’t work and refuses to give non-zero values. If you get the zeros, the player won’t work because it looks up the device values in the same way.

So what happens if you reset the device? Does it then give values?

Also, when using my probe program, you should get some lines like:

List of devices by ID = USB15,USB17,USB16,USB12
 Device 1 => USB15
 Device 2 => USB17
 Device 3 => USB16
 Device 4 => USB12

That list the audio devices by number. I guess that is OK as otherwise you won’t even get the zeros.

If it still doesn’t work, then use Dave’s test and USBDescriptors and let me know the resulting set of values for the device. I may be able to work it out.

Does the device work with Dave/Colin’s players? And what are the details of the test wave file?

Jim

FWIW I do plan at some point to write a simple audio scope + FFT analyser and sig gen progs for USB Audio. I already have a simple recorder working here but I won’t go too much further until I can also find a 96k/24 ADC+DAC and work with that as well as the UCA202. Also have some other things I have to do during the next few days.

However I did some simple tests on the Behringer UCA202’s input yesterday. A -14dBFS 1k tone gave no noticable distortion or anharmonics. i.e. well below 0.01 percent distortion. Quite a good result for a cheap ADC. And the response seemed pretty flat even down to 20Hz when I use a noise source. My guess is that the output is similar, but not checked yet.

Jim