How to do USB audio

Did you plug directly in to the linux box?

Yes.

I’ll come back to the Halide bridge.

OK. It probably isn’t a fair representitive of what people will buy and use these days anyway. I only now get it out of its box for tests or special purposes.

FWIW I’ve now ordered a Behringer UCA202 and am also looking to get at least one other USB device for ADC. Hope the 202 will arrive in the next few days and I can give it a tryout. Rather more representitive than the Halide of what most people will buy and use!

Haven’t clue with linux or how to get it on a beagleboard. Anyone any ideas where to start?

I’d recommend asking about this somewhere like uk.comp.os.linux as the chances are that someone there can advise and has done this. I can help with general points about Linux, but I’ve only ever installed the common distributions on typical non-ARM boxes. So I don’t know what distribution or install method would be best for a beagleboard.

You could also have a look at the distrowatch website to see if there are any which are specifically targetted at boards like the beagle. Or look at the pages on Debian for something that may do. But I don’t know what kind of install you’d find more suitable. Matter of personal preference as well as what’s available.

Once you have a distro installed I can probably help with the ALSA sound setup, though.

Jim

One thing I forgot to add was the speed of the stick may matter. I can play 192/24 from a fat formatted memory stick but not from a riscos formatted USB HDD

I’m not bothered about which linux just one that works with asynchronous USB I just want USB Audio out of it with the minimum effort :-)

One thing I forgot to add was the speed of the stick may matter. I can play 192/24 from a fat formatted memory stick but not from a riscos formatted USB HDD

Complex. When I did some tests years ago, the choice of ADFS vs Fat32 affected the speed. So not just a matter of the speed of the physical device.

I’m not bothered about which linux just one that works with asynchronous USB I just want USB Audio out of it with the minimum effort :-)

If you were installing on an ‘x86’ box I’d suggest trying mint or debian. But I don’t know about any of the ARM distros. I’ll look on distrowatch and ask on the newsgroup if you think that’ll help.

Jim

Jim.

We may as well try and get your rDac working to see if it’s any different to your halide bridge.

Could you download USBModuleDebug.zip then on your arminix:

1) run !USBModuleDebug
2) run !IsocPlayer
3) play some music – it will stop immediately
4) send the ‘RAM:IsocPlayerDebugLog’ file to me.

Thanks

We may as well try and get your rDac working to see if it’s any different to your halide bridge…

Just emailed the results. However I think I already did this a week or so ago, and its been forgotten as we bashed our heads against the Halide! :-)

Jim

The problem with the rDAC giving silence now fixed. The reason was that I was using an old version of Colin’s modules. Embarassed! However although it now plays it behaves like the Halide Bridge. Using it with the ARMiniX, 44k/16 files sound fine but higher rates give pauses and crackles.

I’ll put my head in a bucket of water for a while as penance…

Jim

I’m not bothered about which linux just one that works with asynchronous USB I just want USB Audio out of it with the minimum effort :-)

I’m sure that there are complete SD card images you can download with Linux distros on for the BB, aren’t there? I hope someone more clued up about this will come along soon and help you out, Colin. It might also be worth asking on the BB Google Group about the possible hardware problem you’re seeing, as there always used to be some very knowledgeable people there (I haven’t read it for years now, though) who knew a lot about the hardware.

One thing I forgot to add was the speed of the stick may matter. I can play 192/24 from a fat formatted memory stick but not from a riscos formatted USB HDD

Just out of interest – would I be correct if I said that 24 bit stereo at 96kHz is about 580Kbytes/sec, or 35ish Mbytes/minute?
Just trying to get an idea of how much data is being pushed around.

I’m sure that there are complete SD card images you can download with Linux distros on for the BB, aren’t there?

If you find a good one, please let me know. I could never get Angstrom to work – it keeps saying this whenever I attempt to configure it:

¹

Tried the demo image from two different sources, written to three different uSD cards. The only change I ever made was to tweak the uEnv.txt to point to s-video output. Everything else was left as-was.

¹ Copyright blurb is added automatically by the server for /blog images… It’s annoying, but then so is the reason why it was done in the first place.

Just out of interest – would I be correct if I said that 24 bit stereo at 96kHz is about 580Kbytes/sec, or 35ish Mbytes/minute?

Yes. its generally 96000 * 2channels * 3bytes per channel = 576,000 bytes per sec.

The devices which can do higher resolutions tend to use 4 bytes per channel so that’s 768,000 bytes per sec and for 192/24 1,536,000 bytes per sec.

The devices which can do higher resolutions tend to use 4 bytes per channel so that’s 768,000 bytes per sec and for 192/24 1,536,000 bytes per sec.

And if people think that’s a fair rate, note some DACs and files now provide 384/32 or more. 8-] Fortunately, these are currently for just a few of the more pointy-headed audio fanatics. Personally, except for measurement purposes, I can’t see much reason to go beyond 96/24. if nothing else, the downloads of such files takes soooo long.

Jim

FWIW I did get hits from DuckDuckGo showing ‘elinux’ when I searched for distros for the BB. But I know nothing about it. As I’ve said, asking on the linux group may help. However you may well find that a distro cut down and recompiled for such boards might simply have had some of the USB Audio support omitted to keep down the size. So even if it installed and ran you might find you’d be faced with probing the linux kernel and adding modules. Not a task I’d rush to do myself. But Linux is free so, you can give it a try and see if you get a coconut. :-)

Jim

After a quick look around I’m going off the idea of installing linux rapidly.

Dave.

Do you know the revision of your beagleboard? I read early ones had problems with usb.

Beagleboard Rev.: There should be a sticker next to the USB port.

It’s in a nice box so I didn’t want to get my screwdriver out as it’s not mine :-)

It’s in a nice box so I didn’t want to get my screwdriver out as it’s not mine :-)

Feel free to open the box; the only particular care you need to take is to try to keep the top parallel to the bottom – and try not to zap it with static electricity!

You’ll notice that two of the fixings had to be removed to make space for the board.

Colin: I just tried to email you the descriptors for the UCA202. The email was bounced by the genesys server. I’ll try again later. If no luck I’ll put the zip up and give the address here.

Dave: Would it also be useful if I ran your probe program with the UCA202 and made the results available? (It is an ADC + DAC with spdif out and a headphone output as well as line in/out.)

Jim

Would it also be useful if I ran your probe program with the UCA202 and made the results available?

Yes.

OK, I’ve put both files in a zip here

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

There are lots of selections for this device. 8-]

I’m probably not reading the results correctly. But it looks like it may be willing to send/accept 16bit data as 16bit – i.e. 2 bytes per sample transferred. If so, maybe it will also avoid the ‘stuttering and crackles’ of the rDAC and Halide. It’s also limited to 48k/16 max. So if it can be made to work at 44k and 48k for 16bit it won’t then be expected to push its luck for any higher rates!

Jim

IsocRecorder should just work

Line 45 of the !runimage has this

     xName$ = "'Burr-Brown from TI'"
        usb$=FNusb_findDeviceByVendor(&8bb,&2902,-1)
        IF usb$ = "" usb$ = FNusb_findDeviceByVendor(&8bb,&2900,-1)
        xInterface%  = 2
        xAlternate%  = 3
        xEndpoint%   = &84
        xSamplerate% = 44100
        xSamplesize% = 4 : REM 2 channel 2 bytes per channel
        xChannels%   = 2
        xBits%       = 16

Which is the same as your device. The recorded file will go to ram disc change outfile$ if you don’t want that. Looks like you can record various frequencies and bit depth – though Isocrecorder only supports 16bit PCM.

Dave, you could have warned me that it wasn’t screwed together – the screws were just holding down the beagleboard :-) Anyway it turns out to be rev C4 which should have the USB problem I read about fixed.

At the moment though I’m 99.99% certain it’s a hardware problem – the number of decimal places are increasing. I was wrong when I said I couldn’t get it to play 44100/16, I was using my expensive dac in USB1 mode and I’d forgotten it uses 3 bytes per sample making a data payload of 264.6 bytes per frame when I use the cheap dac it uses 2 bytes per sample making the data payload 176.4 bytes per frame and that played ok. The cheap DAC at 48000/16 has a data payload of 192 bytes per frame and that doesn’t play properly. The payload sizes are significant.

To schedule the data transfer each frame (a 1 millisecond window) has 8 microframes – so a microframe takes 1/8 millisec to complete. For USB1 each microframe can carry 188 bytes.

So in the last version of the modules I issued, interrupts are scheduled in microframe 0 and isochronous from microframe 1 onwards. For 44100/16 data 176 bytes need sending in 1 frame. Those 176 bytes can be scheduled in 1 microframe so I schedule it for microframe 1

Playing 48000/16 on the cheap device or 44100/16 on the expensive dac requires > 188 bytes be sent per frame. So these data rates need 2 microframes to send so I schedule them for microframes 1 and 2. Now the sound is gritty ie they don’t play properly.

Now I can rearrange the sheduling so that the isochronous data is sent in microframes 0 and 1 instead of 1 and 2 and move the interrupts down to microframe 2. If I do 44100/16 and 48000/16 play correctly on both DACs but now the mouse and keyboard are erratic.

This ties in with what I’ve seen when using USB2. In USB2 the payload is spread evenly across the 8 microframes of a frame and the last microframe has an interrupt on completion flag set. When the top bit of the frame counter is set – which is every other second – microframes 2 to 7 are missed erratically. When the microframe with the interrupt on completion flag is missed the process stalls until the controller comes back round to that frame again with the top bit of the frame counter clear then the controller works properly. Thats why with USB 2 you get a pulsing of the sound it plays when the top bit of the frame counter is clear and doesn’t when it is set.

So playing a 48000 file plays noisily in the correct time in USB1 and plays cleanly with pulses taking about twice as long in USB2

Anyway thats todays theory – it helps to write it down I usually prove myself wrong soon afterwards :-)

The doubts I have about a hardware problem is that your beagleboard xm has a similar problem. It may be common hardware of course.

In USB2 the payload is spread evenly across the 8 microframes of a frame

Why?

In USB2 the payload is spread evenly across the 8 microframes of a frame

But you do split it in complete sample frames, don’t you? i.e. every microframe’s payload is an integral multiple of (channels * subframe_size) bytes?

Why.

Because it is the interval on the endpoint descriptor.

But you do split it in complete sample frames, don’t you?

Yes.

xEndpoint% = &84

I’ll try it later this morning. I think I’ve also sussed how to get it to play now I’ve looked at the results from your/Dave’s probe programs. But why is the above &84 ? In the list I see from Dave’s prog it is shown as 4.

Jim