How to do USB audio

type in man aplay and press return. In any ‘normal’ linux…

There is no man :-) You can see it’s been cut to the bone.

The distro is Angstrom-TI-Gnome but it’s ok there’s no need to put yourself out.

I’ll persevere a while. I’m buoyed that this version recognises my DacMagic in USB1 mode – also listed in alsamixer. Unfortunately when I double click on a wav file it says there’s no application installed to play wav files.

The last version I tried which worked had a music player and I could get the test sine wave out of my cheap sound dongle.

So somewhere in there is what I want :-) Then again I may get more music if I hit it with a drum stick.

I suspect that continuing to try to find out using Angstrom would only be a display of sheer stubborn-ness.. 8-] I’ve found places like

https://www.star-m.jp/eng/products/s_print/technical/soft_license/Angstrom_Filesystem_Software_Manifest.htm

which lists packages inc aplay. But I guess you’d have problem after problem doing anything. So best abandoned. Sign that the distro is really hacked about to have alsamixer but no aplay command. The ‘Gnome’ makes me suspect they’re using a hacked about arrangement you could only find your way though by lots of trial and error… and may still not tell you what you need to know.

Jim

Well I’ve wrestled it to the ground and held its shoulders to the canvas for 3 seconds.

The good news – I think – is that it works at 96000/24. I can only play native formats but that doesn’t matter.

For those interested I did it from the terminal window with

mplayer -ao alsa:device=hw=1.0 /media/colin/music.wav

I was then able to make the filetype default to it so thats good.

Anyway back to the drawing board. At least I know now it should work. Thanks to everyone for their help.

Funny how knowing that something should work focuses the mind. Anyway I think I’ve fixed it. USB2 at 192000/ 24 and USB1 96000/24 on the beagleboard.

Problem was memory blocks used by the controller being reused too quickly – the controller holds copies internally.

I’ll test a bit more and post an update tomorrow.

Ok. If you are using my modules would you like to try this version USBModule.zip. The Iyonix works as before – only struggling with 192/24 from a USB hard disc. Beagleboard plays everything from anywhere.

Yes! :-))

Just tried your new modules and I can now play up to 96k/24 with my rDAC and Halide Bridge with no sign of pauses or crackles. Also the UCA202 now plays up to its 48k/16 limit OK. All class 1.

Playing class 2 seems to remain fine. Only quick tests so far, but clearly better than before. Excellent.

Curious that the Linux distro insists on you using something like mplayer which then works via the standard ALSA interface but omits the aplay command. Not sure what you meant by ‘native’ formats, but who cares now you’ve sorted out the class 1 problems! :-)

Cheers,

Jim

In case anyone is interested or finds it useful, I’ve now put a copy of my USBAudioProbe program at

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

This doesn’t do much that Dave or Colin’s test/probe programs don’t already do. But it gives output in a form find more ‘human readable’ and convenient. It scans the USB system and reports on any Audio device it finds, listing the sample rates, etc, they can play or record. It also lets the user type in a target format requirement for sample rate, etc, and the summarises which of the devices can play that. Either without any reprocessing or by simple byte padding. As an illustration I’ve included the results I get when I have four different devices connected. There is a help file and I’ve included the ‘C’ source code in case anyone wants some amusement at the expense of my programming skills (sic). :-)

Jim

Just tried your new modules and I can now play up to 96k/24 with my rDAC and Halide Bridge with no sign of pauses or crackles.

Excellent Jim.

Curious that the Linux distro insists on you using something like mplayer.

It didn’t really insist I use anything it tried its best to hide anything to do with sound. By ‘native formats’ I mean I had to use 24 bit on the DacMagic XS it wouldn’t play 16 bit – Which I thought odd as it has to bitpad 24bit to work with a 32bit channel size but wouldn’t do it for 16 bit.

Edit.

I’ve just remembered that I was using USB1 on linux so it didn’t have to do any bit padding to get 24 bit to work.

By ‘native formats’ I mean I had to use 24 bit on the DacMagic XS it wouldn’t play 16 bit

OK. FWIW Thats the kind of problem you can usually fix by using plughw: rather than hw:. The ‘plug’ tells ALSA to do any format conversions needed. Just using ‘hw:’ means “send direct to the hardware, no conversions”. So you were telling it not to allow conversions. The advantage of using hw is that as an audiophile you know the system isn’t fiddling with the values at all, just shovelling them into the output device. Yer pays yer money and yer takes yer choice on that. :-]

Alternatively fixable by having a suitable .asoundrc file that explicitly tells ALSA “this device insists on X bytes per value so convert to that”.

However given they’ve cut out aplay I have no idea if any of the rest of ALSA you’d have needed will have survived! :-)

Jim

I’ve updated the USBAudio module and UAPlayer test application in the USB archive, and the USBAudioAPI document, on my web site: http://davehigton.me.uk in the Audio directory.

IMPORTANT: I have renumbered some of the SWIs. I won’t do it again; I have now published the numbers of the SWIs that are currently available or planned, so they are fixed from now on. If you have used the USBAudio module, please revisit your application and ensure that you use the new numbers.

Jim: my apologies, this affects your USBAudioProbe. You will have to re-issue it with the new numbers. (I would recommend that you use hex numbers for the SWI numbers; all you need to do is prefix the hex number with “0x”.)

There are two SWIs that I have not yet detailed, and two more that are not yet implemented. I will be working to remedy those deficiencies in the coming days.

Jim: you will, I hope, be glad to see that there are two new SWIs: USBAudio_NameToVIDPID and USBAudio_VIDPIDToName. I hope these do what you wanted.

As always: any comments, observations, or corrections would be gratefully accepted!

As always: any comments, observations, or corrections would be gratefully accepted!

Comment one: good news.

Comment two: Blast! I won’t be able to update my progs until tomorrow sometime.

Comment three: The new swis will probably be useful. I’ve spent time today trying to devise some reliable code for people to match ‘by device name’. Its a minefield as some names may have trailing spaces, for example. That can mean someone reads the name but will specify it ‘incorrectly’ and be baffled. The UCA202 does this for example.

Why do you feel it is necessary to specify SWI numbers in hex? Decimal seems fine to me. Once the value is set, I’m not clear why it would matter.

Just wanted to say congratulations on nailing the BB bug, Colin, and congratulations to both you and Dave for taking away the awards by a well-deserved margin!

Why do you feel it is necessary to specify SWI numbers in hex? Decimal seems fine to me. Once the value is set, I’m not clear why it would matter.

Doesn’t really matter, but it’s easier to see, for example, if the X version is specified or not in hex format. That and convention, I suppose!

Why do you feel it is necessary to specify SWI numbers in hex?

I don’t claim that it’s necessary, but I believe it’s clearer. All the documentation, for all RISC OS SWIs, everywhere, shows the numbers in hex. They are allocated in blocks of &40, and, as Colin points out, converting to the X form adds &20000 to the number.

You can convert to decimal if you like, but you will be on your own, and your code will be different from the original documentation of the SWIs. You would be obfuscating your code a little. This is generally held to be a Bad Thing To Do.

I don’t claim that it’s necessary, but I believe it’s clearer. All the documentation, for all RISC OS SWIs, everywhere, shows the numbers in hex. They are allocated in blocks of &40, and, as Colin points out, converting to the X form adds &20000 to the number.

OK. I generate the values using a ‘swiscanner’ prog I wrote years ago. Since I now have to change all my USBAudio progs because a cruel taskmaster has shuffled his swis, I’ll modify the program to generate hex values. That means I can then know when I’ve updated any of the programs to fit the new swis because the values I define are hex. You’ve tricked me into it. :-)

You can convert to decimal if you like, but you will be on your own, and your code will be different from the original documentation of the SWIs. You would be obfuscating your code a little. This is generally held to be a Bad Thing To Do.

My biggest problem is that my wife does understand me. 8-]

Jim

WPB.

Thanks and thanks to everyone that voted for us its nice to see the interest.

Jim. I wouldn’t have been bothered it makes no difference. If you give the swi a name you only use it once and the name means a lot more to anyone reading your program than the number.

I should have added you should make your swiscanner prog output

#define swiname swinumber 

lines. Then you can cut and paste the ones you want into your program and use the swinames in your program.

Then if swinumbers change you just need to change the defines.

Jim already did the #defines – but he used decimal numbers.

Jim already did the #defines – but he used decimal numbers.

Yes. In the distant past I used to be able to rely on the values provided by the swi.h, etc, data provided as part of the ‘Acorn’ compiler. But more recently I’ve found it useful to do a sweep and generate a complete listing of swis name → value results for this. Too many swis now not in the h file! But I’ve been quite happy with decimal for values. However I’ve now changed to using hex. I’ve just put up a new copy of USBAudioProbe at

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

This should be OK with Dave’s new module and gives the #define values in hex. Assuming I’ve not made a mistake because I was in a hurry.

BTW Dave, am I correct that you’ve also changed EnumerateRates to EnumerateSampleRates as the swi name? I had to also change this.

Talking about names, I’ve also altered the program slightly to put a * before and after each reported maker and device name string. This is because some names have trailing spaces which can catch out someone doing a match by name as they might otherwise not realise! The culprit here is the UCA202 as the ‘example’ I’ve provided with the program shows.

I’ll work my way though modifying the other programs I’m working on later today. Hoping to have a new USB Player sorted soon that allows the user to choose a device if more than one is connected.

Jim

BTW Dave, am I correct that you’ve also changed EnumerateRates to EnumerateSampleRates as the swi name?

It always was EnumerateSampleRates.

It always was EnumerateSampleRates.

OK. I must have shortened it when making and using my earlier #define and I’d forgotten.

BTW My copy of Hi Fi News cover dated March arrived this morning. RISC OS and audio get a mention on the letters pages. Take care, you could become famous in concentric circles. 8-]

Jim

I’ve been updating people wrt USB Audio progress on the R-Comp ARMiniX support email list. The obvious question has now been asked: How close do you think we are now to the modules being ‘ROMable’? i.e. included as part of a ROM release?

Jim

How close do you think we are now to the modules being ‘ROMable’? i.e. included as part of a ROM release?

I’d like to see rather more testing, but I think we’re pretty much at the stage when we could invite more users to test.

I have tested in parallel with my audio equipment, other things that are important to me. HD (spinning and SSD), Surf Stick, USBtoEther (BeagleBoard), CDVD, Printing … No problems. You have my permission;-)

I’ve suggested on the ARMiniX email support list that others may find it useful to test this. I’ve warned that it is ‘experimental’. But I’m hoping some will try it.

BTW I’ve now fixed a buglet in my player that stopped it working with the UCA202 unless I hacked some of the playout values explicitly. It was because I was allowing the player to find settings without screening out mono endpoints or ones for ‘rec’ rather than ‘play’. having trapped those it now simple uses the first device it can find, and plays any stereo wave files the playing device can accept.

I’ll tidy this up, write a help file, and make it available as another test prog people can use – or reprogram into a more decent form!

Should this work on an RPi? I don’t have one so have no idea.

Jim

No the Rpi uses a different controller so USB audio won’t work with it.