How to do USB audio

I’ve updated a couple of things in my Audio directory at http://davehigton.me.uk/Audio in particular the USBAudio.zip archive and the USBAudioAPI document.

The module now includes calls USBAudio_EnumerateResolutions and USBAudio_EnumerateSampleRates, which are also documented. The archive includes the current USBAudio module and the UAPlayer application.

A new feature in UAPlayer: when given a WAV file that has a subframe size that the device supports, but the WAV file’s resolution is greater than the device’s, it will open the endpoint instead of erroring out. The feature uses the EnumerateResolutions SWI.

As usual, all feedback gratefully received!

Dave if you’d like to try the above set of modules on your beagleboard does it stop the sluggish mouse?

Yes! It certainly appears to. I’ve given it a thorough kicking, playing Albinoni and Patience repeatedly :-)

I think that, whatever it was, you’ve cracked it.

Oops – spoke too soon… it’s fine at 44100 Hz, but seriously scratchy at 48000 Hz.

And there’s another thing: I was running the modules on the Iyonix and the BBxM, but they both malfunctioned when I shut them down. The BBxM stiffed completely (no mouse cursor movement, no response to NumLock, didn’t reach the “Restart” window), and the Iyonix gave some kind of abort (I think it was an AODT but I can’t remember). It was late, and I wasn’t about to reboot to post this information last night, sorry.

seriously scratchy at 48000 Hz.

Could you try with the audio device plugged into a separate hub.

Its becoming impossible to debug devices I don’t have, I may have to call it a day and just tidy up what I’ve got.

Could you try with the audio device plugged into a separate hub.

It was (and still is).

The “seriously scratchy” sound was when playing a file from HardDisc4, which is a portable spinning rust drive that’s also plugged into the separate hub. I only later thought of playing a file from RAM disc; it was much less scratchy. However, the problem seems to be completely absent when playing a 44100 Hz file from the same spinning rust.

Its becoming impossible to debug devices I don’t have, I may have to call it a day and just tidy up what I’ve got.

That would be a shame. You have made enormous progress over the last few months.

Remind me whereabouts in the country you are?

What devices do you have? What is your budget for buying other devices for development? (Zero is one answer.) I’ve bought several devices on eBay from UK suppliers; most of them were well under a fiver each. The only expensive device I have is the iMic, which I bought years ago.

What exactly (with some detail, please) have you been changing recently?

Remember, I have a USB analyser, and I can use it to capture full speed traffic. Regrettably it doesn’t do high speed. If you have access to a Windows machine, you can get hold of the software and I can send you captures for you to examine in full detail.

The USB Audio Device Class clearly shows the ability to support more audio formats than plain old linear PCM. But does anybody know of the existence of a device that does so?

The USB Audio Device Class clearly shows the ability to support more audio formats than plain old linear PCM. But does anybody know of the existence of a device that does so?

Yes. Some of the DACs which have been reviewed recently in the HiFi mags also support the ‘DXD’ types of formats which send low-bit high rate audio packed into a series of bytes. No idea of the details, but I could see if I can find out. I think some also may support floating point. Never used a device like these as they tend to be ‘high end’. i.e. expletive expensive even by my jaded standards.

BTW regarding other ADCs (and DACs) two points.

1) Reminder to Colin and yourself that I’m still waiting to send you something that might aid being able to buy some more you can then play with… erm experiment with. :-)

2) In a few days when I’m clear of Xmas/Hogmanay I plan to get some DACs and ADCs to investigate myself and report on.¹ With luck we can start building a list to tick off what has been tested and works/doesn’t so far that will help others to dive in.

Happy New Year to all. :-)

Jim

¹ Been busy. Partly with the predictable wine, women, song, food, films, etc, etc, appropriate for the season. :-) Partly because I became interested in writing a (Linux) easy-automate-extract-and-process prog to get audio from DVDs. Now pretty much done.

Its not usb devices I need it’s a beagleboard.

I’ve been modifying the cmask and smask bits in the full speed queue header (qh) and split isochronous transfer descriptor (sitd)

48000 not working and 44100 working can be explained by 44100 transferring 176 bytes per millisec and 48000 requiring 192 bytes transferred per millisec. Up to 188 bytes can be transferred in a single microframe. So 44100 is transferred in 1 microframe and 48000 is scheduled to transfer in 2 microframes (using smask) From what you describe it sounds as if only one of the microframes is sending data. Investigating it remotely is difficult. The iyonix plays 48000 ok.

If you play 48000 on the beagleboard and remove the keyboard and mouse so that the only full speed device you have plugged in is the audio device does it play?

Its not usb devices I need it’s a beagleboard.

I may be able to help you there. I have a BBxM that I use and don’t want to let go of; but I also have a BB (not xM) that rarely gets switched on these days. (I have a project lined up for it, but I haven’t set a start date.)

It’s in a case along with a 7 port USB hub. I don’t have a hard drive to lend you. But is the BB of use to you as a medium-term loan?

I may be able to help you there.

Loan being arranged via email.

‘The USB Audio Device Class clearly shows the ability to support more audio formats than plain old linear PCM. But does anybody know of the existence of a device that does so?’

What is the deal on AC-3 versus pcm? See this link – the ‘AAM’ is the same USB card/dongle I have.
http://www.sprinkleofcocoa.com/2005_04_01_archive.html

Another thing I thought of and will try tonight, This card does passthrough to the optical output, so it might be possible for my surround amp’s DAC to make sense of the 44100 output (via optical) given that Colin’s driver can force the 48000 USB device to take 44100. I guess it depends on the definition of passthrough.
Edit:
Well, the ‘always on’ optical was received by my surround amp in an identical fashion, great at 48000, a mess at 44100. Colin’s driver wont send an ac3 file because ‘Not RIFF WAV file’. Possibly the suggested passmode would have to be set, but what would determine the rate of the ac3 file?, there is no handshaking over optical, so it would have to be done with the driver I imagine. (The driver that puts every other job second) Another question, are there many receivers that support ac3 streams?

It’s only !isocplayer which is stopping the AC3 data being sent you can send any data you like via USB. I expect all that you will get though is noise. There is no endpoint on your device for anything other than 48000hz 2channel 16 bit pcm. Sending 44100 data will only means that the 48000 data recognised by your device is sent short ie it only gets 176 of the 192 bytes it expects every millisec. The data is read in chunks so the shortfall in data will be played by the device ie it will play noise or silence or whatever.

From the above link
‘This extension (hack) to S/PDIF is called IEC61937’
From the manual for the ‘AAM’ (abreviated)
The S/PDIF optical transfers stereo audio to …. The data rate on the S/PDIF output is fixed at 48kHz.
The S/PDIF output may also be used to transfer multi-channel audio to an A/V home theatre receiver with built-in 5.1 decoder for Dolby or DTS formats.
DVD playback of these requires a software DVD player that transmits this audio format.
Elsewhere manual mentions only Windows XP can do it.
Maybe the 44100 ac3 is repackaged into a 48000 time frame by software, I dont know.
I dont want to cause a lot of fuss over this, as I doubt it would be used much. OTOH your driver might already do the job if the file is prepared first, but I am still speculating.
A description is here
http://www.ac3filter.net/forum/index.php?topic=93208.0

There are now a number of formats that can transfer over USB or ‘digital’ links So you can find examples which handle ac3 or dts or DSD or DXD or… I’ve not investigated as my personal interest is ye olde LPCM stereo. However I think for USB they tend to be based on packing the data into a series of bytes with a specific recipy. You then have to have an endpoint device which can accept the relevant format, but as yet I’ve never had anything that does this via USB.

Are the formats for DSD/DXD openly available? The SACD people seem obsessed with commericial control via confidentiality and DSD/DXD are based on SACD. I suspect Dolby will be similar for ac3, and much the same for dts. At least LPCM is pretty clear and open.

Jim

If you look at the Class 1 Audio Specification in the formats pdf AC-3 is specified there so it is possible to get a Class 1 Audio device which handles AC-3. However the device needs to tell you that it can do it by having an AC-3 interface descriptor and your device doesn’t have one.

If your device has vendor specific interfaces – I don’t have your descriptors to hand so can’t check but I can’t remember that it does – then those features are reliant on vendor specific drivers as they are the only people who know what these interfaces do.

I suspect only windows can run vendor specific drivers to access ‘extra features’ because they use some non standard back door they built into the device.

Maybe it is protected, and if the USB device has to change mode to transmit straight data this might be a problem. At the far end of S/PDIF the home theatre device checks the data in case it is dolby or DTR no matter what gets sent. Is there no chance the USB device can detect the header the same way and change mode? (If that is indeed needed) The Windows driver pictured on the web as an ac3 filter page to match the input to the output. DVD Dolby is always 48000,
but some music DVD’s are 44100 and need to be upsampled for a 48000 device.
How do I get more info on my Audi Advantage Micro device?
EDIT
These guys have been encapsulating the the AC3 and DTS as a wav, so there wouldn’t be anything special to do if that is the case.
https://github.com/raspberrypi/firmware/issues/183

ffmpeg -i file.ac3 -acodec copy -f spdif – | ffmpeg -f s16le -ac 2 -ar 48000 -i – -acodec copy -f wav file.wav

Then the receiver detects the header.
To late to try tonight.

DVD Dolby is always 48000, but some music DVD’s are 44100 and need to be upsampled for a 48000 device.

I have a number of musical DVDs, but none of them are 44100 sample rate. They all seem to be 48000.

I’m not quite clear if you’re thinking of sending ac3 to an endpoint device that can’t accept ac3 from the wording of what you wrote. The data does have to be byte packed. But – I assume – you also need a device that confirms it can decode ac3 and then send in the transfer mode it specifies.

AIUI when you play a wave file you don’t sent the actual wave file metadata header as part of the stream. You negotiate and setup with the endpoint device what you’ll be sending as the audio payload, then send it. If that’s the case, having something like ac3 packed into a ‘wave file’ is really just using the wave header as a convenient way to tell the host computer what it is being asked to play if you start a playing process by giving a suitable program the ‘wave file’s address as the item to have played. Or am I missing something here?

BTW If converting ac3 to lpcm with ffmpeg you might need the drc_control switch to set drc to zero. Depends on the disc and the version of ffmpeg.

Jim

That’s pretty close, Jim. There is an easy to read description here.
http://www.ac3filter.net/wiki/AC3Filter_%26_SPDIF
There are a few spdifier programs around, They basically use the pcm container space for compressed data and look like a pcm. I note there is a requirement that the driver must not reorder the pcm information for it to work.
I did have my surround amps dolby light blinking and some ticking sounds, but he downloaded spdified wav showed up as 41000 with sndfile-info, which could be the problem.
Ideally I need a short 48000 ac3 file that has been
spdified properly to test with, otherwise it is going to be a while getting on top of a proper conversion process.
Edit:
I have now got ac3spdif from autools compiling in !GCC. I built the AFsp-v8r2 library it needs on the cross-compiler first though.
The good news is it works in the default settings and I am listening to dolby digital on my surround amp as I write. It only took a few minutes to convert a 34Mb ac3 file to a 116Mb wav on my Iyonix so luckily it is capable of doing it in real time, because the output file is so big in comparison and ideally you would stream it to the USB driver on the fly one day.
ac3spdif inputfile outfile.wav
so simple!
I will have to find a music DVD to see if all ac3 files work equally as well.

It only took a few minutes to convert a 34Mb ac3 file to a 116Mb wav

Must confess I have qualms about using the wave file format as a container for such non-LPCM data payloads. Despite knowing well that wave is a container.

If this becomes common it will be likely to confuse people who see a series of ‘wave’ files only to find that some play and others don’t because their playing app, etc, assumes wave will contain lpcm. Alas, this seems all to typical of the way M$ tend to ‘overload’ things so they can make use of the confusions over ‘standards’.

I can’t see why ac3 would need turning into a wave file to be playable since AIUI the actual endpoint device won’t simply be given the wave header. The playing application is handling that and then doing the interfacing in another way. Or am I wrong?

To me it makes more sense for a playing app to recognise and convert ac3 to lpcm or to then stream out the ac3 to the endpoint device. Either way, with the file being raw ac3 and have a name ending with “.ac3” or equivalent, not “.wav”. That way it is clearer what us going on and avoids confusions.

All of that said, my interest in ac3 and ‘surround’ is purely technical as I am quite happy with stereo in practice and prefer lpcm to any lossy formats. Particularly proprietary ones. So I’m interested in what you’re doing, but have no plans to follow you in practice on this. :-)

Jim

There is an easy to read http://www.ac3filter.net/wiki/AC3Filter_%26_SPDIF

I’ve only glanced at that so far, so I may be wrong. However it does seem to make some errors. You can send 192k/24 over spdif, which contradicts what it seems to say, for example.

It only took a few minutes to convert a 34Mb ac3 file to a 116Mb wav on my Iyonix

Curious to know why the resulting ‘wav’ file is bigger than the source ac3. That implies it isn’t simply wrapping the data but converting it. Maybe the page will explain when I have time to study it. But it does underscore my wondering why the playing app can’t do such processes at runtime. That way you can keep smaller files and avoid extention confusions. To me this approach continues to have an air of the kinds of standards muddles that big companies love and users end up finding a PITA! :-)

Jim

There’s no reason to make it a wav file USB doesn’t know anything about the data format. It’s the device which decides the data formats it can handle by providing different endpoints with different properties. If your device says you can only handle 2 channel 16 bit PCM data at 48000hz (48000/2/16) and you send data which isn’t that format how is the device to know that that the format is not 48000/2/16?

To send 48000/2/16 usb sends 48*2*2 = 192 bytes every millisec. If the data is PCM all values of those 192 bytes are valid so you can’t put a marker in there to say that the data is not PCM.

The only way I can see it working is if the device can be switched to treat the incoming data as a different format then it doesn’t matter what the data is that you send – could be a jpeg file for all USB cares. You would just open the endpoint as if you were sending 48000/2/16 and send anything you like.

Curious to know why the resulting ‘wav’ file is bigger than the source ac3

I suspect it’s been converted to a wav file. wav files can have more than 2 channels. reading the wav header would be interesting.

ac3 is compressed audio, that is why it is possible to fit the six channel 16 bit 48000Hz information in a 2 channel 16 bit 48000Hz wav container. Also the trickery requires no change to the basic USB1 devices like mine that would have been prevailent back in the day. (And in our case, nothing special required by the driver.)
I read where you can use 3 optical outputs to do 6 channel output but they are rare.

ffmpeg or (avconv as it is now called) is excellent at extracting the correct ac3 file from a DVD VOB file, and can also put the s/pdif into a specified wav container.

avconv -i VTS_01_6.VOB -map 0:1 -c:a copy -f spdif – | avconv -f s16le -ac 2 -ar 48000 -i – -c:a copy -f wav outp.wav

On RISC OS you’d have to use a temp file instead of the pipe, Duncan’s pipe utility may work, but on these slow machines it
doesn’t hurt to break the jobs up.

I’ve probably gone as far as I need to with this myself now, I have just received one of those cheap USB sticks with the mic input and will be looking at trying to record, mainly in the voice range, I’m not expecting too much from something that only cost a few dollars.

ac3 is compressed audio, that is why it is possible to fit the six channel 16 bit 48000Hz information in a 2 channel 16 bit 48000Hz wav container.

Yes. That doesn’t really deal with the comments I made, though.

To me it makes more sense to:

Have a program that can read ac3 files and send the results via spdif (or USB) to a device that can understand the ac3.

than:

Have one program to make (bigger) ‘wave contained’ files. Which are then, later, sent by another program, carrying essentially the same ac3 data over an spdif (or USB) link to a device which can understand the ac3.

Seems a needless complication and waste of resources to me. As I said, what I’d expect someone like M$ or Apple to do since they aren’t bothered if you have to keep up with them by paying them money, etc.

That said, I can see the point for test purposes. e.g. When doing this with a simple RO player of the kind Colin/Dave have developed if the ‘wave contained’ file’s data payload is the sequence of bytes to be sent. However I’d assume that either means changing the player to recognise the different wavefile header or some bodge around.(?) But for everyday use when you have a collection of files, I think I’d avoid this approach.

ffmpeg or (avconv as it is now called) is excellent at extracting the correct ac3 file from a DVD VOB file

Agreed. Also fine for things like HDTV ts files, etc. I’ve found it useful for dealing with these (aac_latm audio) when examining the audio on these. Once again, this area in the UK seems a real ‘standards’ (sic) muddle!

Jim