How to do USB audio

I think the vendorid, productid and deviceversion is the safest way.

Do the USBAudio swis return those? I can’t seem them. If they are device specific they’d be handy for avoiding having to parse strings.

Jim

So have you only played 192/24 from your SDHC card?

I did play files from a Fat format SD card a few days ago to test what happened. I think I did 192k/24. But I can check to see. Can try using the new Hub as well for this.

Jim

I think the vendorid, productid and deviceversion is the safest way

Do the USBAudio swis return those?

No, but they could if you want. My question is what would you do with the vendor ID and product ID if you had them? The whole point of the USBAudio module was to abstract application writers away from having to deal with any nuts or bolts of USB.

But strings can be a PITA for this as you may have to load and parse ones with spaces and assorted non-alphanumeric characters.

There is no use that I can see for the maker and device strings other than for a human being to read them, as a way to identify which USB audio device they are dealing with if they have more than one connected. So I can’t see any reason that you would ever want to parse them – simply present them to the user, and let the user choose a device as a result of seeing them, very likely by clicking on something.

Just checked again.

Yes, as well as being able to play up to and inc. 192k/32bit files from my main ‘hard disc’ (actually an SD card) I can also play them from a Fat32 format 16GB SD card which is in a USB adaptor stick, connected to a 7-port mains powered hub, which is plugged into one of the rear sockets on my ARMiniX.

That’s all using my class 2 DM Plus. No sign of any audible problems playing 192k/32 bit stereo wave files.

So things seem fine for class 2. The problem is class 1.

Jim

No, but they could if you want. My question is what would you do with the vendor ID and product ID if you had them? The whole point of the USBAudio module was to abstract application writers away from having to deal with any nuts or bolts of USB.

Understood. That makes perfect sense for the bulk of situations where the user has just one USB device and uses it in the way most people do. However I’m also thinking of situations of more demanding and flexible kinds. e.g. where I’m using the DM Plus to play out audio whilst using the UCA202 to read in audio. (I’m assuming / hoping this will be possible.)

It may also make life easier for programming if we can associate a device with some numbers that don’t change. Easier than having to keep parsing a pair of strings. So I suspect it may be useful. However I can’t be sure at the moment, so if it isn’t a trivial addition I’d be happy to leave it until I’ve spent more time experimenting as I’ll then have a better idea of if this might be wanted. May be easy enough to use the strings.

That said, if it is easy to add, then it may be useful at some future point anyway.

Jim

Jim.

The fact that you can play USB2 what looks like flawlessly means you don’t have a problem with missed microframes. And neither is the problem with USB on the beagleboard due to HAL differences.

If you put the usb1 device on a hub on its own does it work? When on a hub on its own it won’t be affected by any other USB1 device you have working.

Dave the point about vendor/product/device is that is just as meaningless as USB8 as an identifier but it survives inserting and unplugging things and switching off and switching on.

However I’m also thinking of situations of more demanding and flexible kinds. e.g. where I’m using the DM Plus to play out audio whilst using the UCA202 to read in audio. (I’m assuming / hoping this will be possible.)

It always has been.

I’m probably way off base here, but the issues on the BB you’re seeing couldn’t be to do with a stale memory cache, could they? I mean, when you see that the active flag has (or rather hasn’t) been changed, can you be sure that’s definitely the case? Just a wild stab in the dark in case it helps. I know I’ve been caught out by cached memory before!

It may also make life easier for programming if we can associate a device with some numbers that don’t change.

OK. Given that all control communication with USB devices requires the USB device name (e.g. “USB8”), I don’t propose to change the existing USBAudio API to require something else instead.

But if I add a pair of SWIs to translate in both directions between USB device name and VID+PID, would that do what you want?

The snag, of course, being that the translation from USB device name to VID+PID is guaranteed to be unique at any point in time, but the other direction would not be unique if you have two identical audio devices.

If you put the usb1 device on a hub on its own does it work?

Yes. That’s how I did the recent tests. Which leaves the puzzle of why the class 1 devices show the problem. Given that crackles can occur for 48k/16 it clearly can’t be a raw bandwidth issue.

FWIW I’ve also done recent tasks with my test player single-tasking to eliminate as many possible sources of ‘distraction’. But this seems to give the same behaviour as using a TaskWindow or GraphTask.

The UCA202 will play 32k/16. If I get a chance I’ll try that later today. Maybe the problem occur because 44.1k/16 by some happy chance is a ‘magic’ rate that dodges a problem other rates trip over.

Jim

bq. However I’m also thinking of situations of more demanding and flexible kinds. e.g. where I’m using the DM Plus to play out audio whilst using the UCA202 to read in audio. (I’m assuming / hoping this will be possible.)

It always has been.

I was uncertain if it would hit some kind of timing/bandwidth/contention problems in reality. Particularly given the problem we have at present with non-44k using USB1. I assumed that and OpenOut and an OpenIn could be run in parallel so far as the software is concerned. But less sure what would actally happen and if both input and output then worked without flaws. :-/

Jim

But if I add a pair of SWIs to translate in both directions between USB device name and VID+PID, would that do what you want?

I can’t be sure at present as I’ll only know once I’ve done some experimenting with arrangements. But, yes, I think having that may well be useful. So yes please. FWIW it seems sensible to me for it to be a different swi as you describe.

Jim

the 44/16 USB1 problem is a problem with the USBDriver not the programs feeding it ie isocplayer it isn’t a buffering issue. There’s nothing you can do to fix it. Having the device on a hub on its own was the best chance to play without problems.

44/16 works because data is sent in 1 microframe. I can make 48/16 work by starting the transfer in microframe 0 but then I have to move the microframe that the mouse uses to > microframe 1 and then that becomes eratic.

I’m having no luck getting linux on the beagleboard. Does anyone know if I just need to change the sd card to a card with the correct image on it or do I need to do something else?

WPB.

Thanks for giving me something else to think about. As if I don’t have enough sleepless nights :-)

I’m having no luck getting linux on the beagleboard. Does anyone know if I just need to change the sd card to a card with the correct image on it or do I need to do something else?

I assume you need to swap to having an SD card that either already has the distro on it, or a loader that will let the machine install the distro from some other connected device.

I’ve not had any newsgroup response to my question about this. But I think I found a web reference to elinux. I’ll have another look. However I’m doubtful it will help as it would not surprise me if USB Audio hasn’t been sorted out for what would have to be a special linux install targetted at the Beagle/Panda types of board. So it might not help the main quest.

Jim

I’m having no luck getting linux on the beagleboard. Does anyone know if I just need to change the sd card to a card with the correct image on it or do I need to do something else?

As far as I know you just swap the microSD cards over. I actually have a card here which I have found after a big rummage. It has a version of Ubuntu on it (having just looked at the kernel file in zap). It came from R-Comp when I bought the ARMini. I have never used it, but if you think it would help, I am quite happy to post it off to you.

Following on from what Chris said: Might be worth your while asking Andrew at R-Comp about this as he may be able to advise. Other than that, I’ve been poking about the elinux site and found pages like

and

but as yet I’ve not found an SD card image. And if there is one, you’d probably need to be able to use a Linux (or Windows) tool like dd to put the image onto a card. So if you’ve not used Linux (?) this may be a bit of a steep hill without advice.

Jim

Note: The ARMini Image is for a BeaglexM. It will not work with a Beagleboard C4. You need a other one. I have a Angström one at home. I can wrote a Image to upload if you are interest. You can wrote this with SDCreate or with CloneDisc.
Edit: Maybe this one works.

Thanks for giving me something else to think about. As if I don’t have enough sleepless nights :-)

Sorry, Colin. At least you can listen to music while you can’t sleep, eh? ;)

Currently puzzled. This may be because I’m now tired and need a break! But…

The UCA202 requires you to specify different endpoint and alternate values for OpenOut depending on what sample rate, etc, you wish to play or record. How do I use the USBAudio swis to find out what values for endpoint, alternate, etc, will be needed when I want to play a given rate, etc? EnumerateRates and EnumrateResolutions don’t seem to list this. Or am I just missing it?

I’ll take a break. :-) Sorry if this is obvious.

Jim

Note: The ARMini Image is for a BeaglexM. It will not work with a Beagleboard C4.

Ahhh – right, I didn’t realise. The thought was there 8)

How do I use the USBAudio swis to find out what values for endpoint, alternate, etc, will be needed when I want to play a given rate, etc? EnumerateRates and EnumrateResolutions don’t seem to list this. Or am I just missing it?

As usual, it’s simpler than you think. Just read the documentation for OpenOut/OpenIn and provide what it asks for – the resolution, sample rate, number of channels, subframe size and format code. USBAudio would like to help you :-)

As usual, it’s simpler than you think. Just read the documentation for OpenOut/OpenIn and provide what it asks for – the resolution, sample rate, number of channels, subframe size and format code. USBAudio would like to help you :-)

Well, I may have done something wrong, however… As soon as I got the UCA202 I tried that, and it didn’t work. I had to explictly give the endpoint and alternative values when making the call. And the values change with sample rate. In fact I think I then found that you didn’t have to give the ‘correct’ values again later if you played again using the same rate. But you did if you changed the rate.

Hence my question as it seemed/seems that I needed to give the endpoint and alt for it to work when calling OpenOut.

I’ll check again tomorrow. I may well have done something else wrong at the time. May well be that something else caused my first attempts to fail.

All that said, how do you list all the endpoints, etc, and associate them with sample rates, etc, in your Test program? I’ll have a look but may get clouded by it being in BASIC.

Jim

Just remembered another detail of my first tests with trying to play using the UCA202.

I started off using my player program and tried to use it in the same way as for my DMPlus, etc. i.e. Just giving the sample rate, number of channels, etc, to OpenOut and giving nothing for endpoints, etc. Didn’t work. I noticed that the program was telling me that although I was trying to play and transfer 2bytes per sample the device was telling me it wanted one byte per sample. i.e. in 8 bit mode. This continued until I gave OpenOut the specific endpoint and alternate values for the rate at 2 bytes per value. It then worked. But maybe this was something else I was doing wrong. I’ll check tomorrow and report.

Jim