How to do USB audio

A few years ago I’d have said “t’works”, but these days the meaning seems to have changed… :-)

Yes. Your recorder worked OK at 44k/16. I then changed one of the settings and also got it recording 48k/16. I only recorded about 20 sec each time as it was a simple test to see if the input was being recorded. But neither recording showed any obvious signs of crackles or gaps. Promising.

I’ll do some more experiments, but a good start. :-)

I’ll see if I can get it playing. I have in mind to modify my demo player so it will read in settings from a file based on the vendor ID or the device name. That way it could use all the settings offerred by the UCA202. Interesting in that it will play 22k and 11k as well as other ‘low’ rates. That may be dead useful for people who want to play using programs ported from Linux / games as the PandaBoard hardware won’t do these low rates and this gives DigitalRender a headache. Leads to the ‘chipmunks effect’.

Jim

But why is the above &84 ? In the list I see from Dave’s prog it is shown as 4.

USB endpoints have an endpoint number (0 to 15, 0 being exclusively the control endpoint), and an endpoint address. For output endpoints, the address is the same as the number. For input endpoints, the address is the number OR 0×80. The MS bit of the address tells you the direction.

That’s one of the errors in the ARCAM DAC’s descriptors; they gave the synchronising endpoint’s number, whereas the USB specification requires the endpoint’s address.

I’ll see if I can get it playing. I have in mind to modify my demo player so it will read in settings from a file based on the vendor ID or the device name.

Alternatively, you could use the USBAudio module to find all the information you need directly. Saves you having to hard code device information into your application.

It’s &84 because the top bit signifies the direction. If bit 7 is a 1 it is an IN endpoint. Dave has stripped it off maybe because the special field used when opening the endpoint didn’t like the top bit being set – I’ve changed that.

Your device only plays 32000,44100 and 48000. It records at 8000 – 48000.

Any problems are likely to be above 44100/2/16 so a recording at 48000 would be interesting. Change xAlternate% to 1 and xSampleRate% to 48000 (see above for where) and you should get a 48000/2/16 recording.

Any problems are likely to be above 44100/2/16 so a recording at 48000 would be interesting. Change xAlternate% to 1 and xSampleRate% to 48000 (see above for where) and you should get a 48000/2/16 recording.

I already tried 48/16 as reported above. On a short test it worked fine.

It’s &84 because the top bit signifies the direction.

Does that mean I also have to include the &80 when calling OpenIn to set up recording transfers via Dave’s module?

Jim

Trouble is a device name is invariably ‘c-media electronics’. Its very poor. Your behringer device is ‘burr-brown from TI’ about as much help as a chocolate fireguard.

Excellent Jim. It looks like the problems I’m seeing are limited to the beagleboard.

Alternatively, you could use the USBAudio module to find all the information you need directly. Saves you having to hard code device information into your application.

I’m currently thinking about the ways to do this. A complication I know I’ll face in due time is their being more than one audio device. e.g. I may well have the UCA202 and a DMPlus connected and working. To use one for ‘record’ and the other for ‘play’.

At present I’m also debating with myself about how to generate a list of the ‘modes’ (recipy for choosing the endpoints, etc, for a given input/output) between doing a scan with your module or having a lookup file.

Perhaps the best course is for me to take a part of my player and cut out the playing part for now, and focus on getting it to probe the connected devices for what settings are available and which are a match for the task asked. However I’ll probably also need a file for specifying which device to use in some cases.

Jim

Can confirm the UAC202 plays OK. Did a quick check by hacking a version of my player. 44k seems fine. But with a short test I think I heard an occasional crackle playing 48k. This with the UCA202 connected directly to a front USB socket of my ARMiniX. Using the UCA202’s headphone output to listen to the results.

I’ll do longer tests later on. Some time in the future if crackles persist I’ll try making a capture from the spdif output of the UCA202 to compare sample-by-sample with the source file being played. May give a diagnostic as to what is going on.

But for now I think I’ll focus on being able to probe and list devices so I can understand and decide how to use the results for matching settings to suit a file to be played, etc, and also handle multiple devices connected at the same time.

Good to find the UCA202 works, though. Probably means the other Behringer devices also work. I’ll see if I can get one of their better class 2 ones sometime.

Jim

A complication I know I’ll face in due time is their being more than one audio device.

If you need more or different methods available from USBAudio to help enumerate and identify devices, please let me know. It has always had the ability to enumerate all USB audio devices, and, for each USB audio device, to obtain the identification strings.

I have also kept it deliberately in a form that will support multiple USB audio devices. In theory, if you had 120 (we have to allow for some hubs, a keyboard and a mouse!), it will still work just as well.

But you will doubtless let me know!

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.

So we have to work out why it’s missed.

In what sense is it missed? Are the data not transmitted, or does the interrupt not occur?

A transfer can be seen like this

typedef struct
{
	char* microframe[8];
} frame_t;

where each microframe points to a block of data you want to transfer from or to. This is much simplified but it will give you an idea.

The controller has a ‘frame index’ (frindex) which contains an index to an array of 1024 frame_t*: so the frame array looks like

frame_t* frame[1024];

frindex is a 14bit clock which increases every microframe. The bottom 3 bits is the microframe in the frame_t it is processing now, ((frindex >> 3) & 0x3ff) is the frame it is processing now and the top bit (bit 13) isn’t used by the driver – it’s probably there so you can detect wraparound.

So you schedule your transfers by making frame[xyz] point to a frame_t and when frindex = xyz the microframes in your frame_t are processed one at a time controlled by frindex increasing.

So you have the controller going around and around frame[] processing any frame_t pointers it encounters.

I said that frame_t was more complicated and one of the things you have is a status for each microframe. When you setup the microframe you set the status to ‘active’. When the controller processes that microframe it removes the ‘active’ flag and sets any other status flags it needs to – like if there is an error in the transfer. You can also choose a microframe to cause an interrupt when the controller removes the ‘active flag’

So the whole process of the controller processing the microframes in a frame is automatic.

What I am seeing is frame_t structures where there are microframes which have not had the ‘active’ flag removed meaning that they haven’t been touched by the controller. Invariably the first 2 microframes are processed which is why up to 44100 works ok in USB1 and sometimes only a couple of microframes are missed. The trouble is with audio those missed frames distort the sound – a mouse/keyboard may miss the odd keypress but that is less noticable.

As to why these microframes are missed by the controller… ‘shrug’. The ehci spec implies that it may be due to the controller not having access to memory at a particular moment – whatever that means.

I have seen missed microframes on the iyonix but that is when playing 192/24 from a USB harddisc. Doing the same from a USB stick works ok – as it does from ram disc and the internal HDD.

I suspect electrical noise – out of desparation :-). Bulk transfers have retry mechanisms so are likely just to slow down as transfers are retried.

If you need more or different methods available from USBAudio to help enumerate and identify devices, please let me know. It has always had the ability to enumerate all USB audio devices, and, for each USB audio device, to obtain the identification strings.

As yet I’m far from clear what would be the best approach. Ideally, a single value/number like a maker ID would be fine. But the problem there is when the same maker ID may cover different devices with different behaviours and details. If that is the case, the maker and device strings are probably the safest way, although these also may be ambiguous at times.

The “USBXX” numbers aren’t ideal because they may change, even during a session of work.

Might be be practical to define a ‘hash’ routine that generates a value from the strings, say? Then use that to match a device for choices? Or is there a simpler method? Otherwise I suspect I’d prefer strings. That’s what I use on Linux with ALSA for purposes where I need to target a specific device whose USB ‘address’ (and ALSA number) may change.

Beyond that I’ll probably have a better idea in a few days after I’ve struggled… erm experimented a while with trying to get some sense out of being able to read details when I have multiple devices, etc.

Jim

As to why these microframes are missed by the controller… ‘shrug’. The ehci spec implies that it may be due to the controller not having access to memory at a particular moment – whatever that means.

Might this simply be a hardware fault for the PandaBoard? TI seem to have assumed they can neglect USB1? Or is this a RO problem?

FWIW I’ve now had two SDHC cards (one ADFS the other Fat32) develop problems having used them a lot. Not sure this is the cards or maybe the file transfer equivalent of a missed microframe. Any guesses? The internal HD seems OK but that is not USB on an ARMiniX.

Jim

Would that be the hard disc connected to

'Sunplus Innovation Technology.'
 'USB to Serial-ATA bridge'

The “USBXX” numbers aren’t ideal because they may change, even during a session of work.

Only if the device is unplugged and replugged, or reset – the latter can only ever be performed manually IIUC, so won’t happen without your knowledge.

the maker and device strings are probably the safest way

That’s what USBAudio gives you now.

Might this simply be a hardware fault for the PandaBoard? TI seem to have assumed they can neglect USB1?

I don’t think the pandaboard has the same problem. You can play USB 2 the beagleboard can’t Playing US2 is the the more obvious test. USB1 mostly just gives crackles.

The reason that they didn’t include a USB1 controller on board is that the board usb sockets are not connected directly to the usb controller. The sockets are from an onboard usb2 hub so a USB1 controller could never have been used by external periferals.

I suspect electrical noise – out of desparation :-)

The trouble with that as an explanation is that, if it were the case, nothing would work.

What I am seeing is frame_t structures where there are microframes which have not had the ‘active’ flag removed meaning that they haven’t been touched by the controller.

Wow. That’s serious. But there has to be an explanation – a proper, good, reason.

I think the vendorid, productid and deviceversion is the safest way. I’ve seen webcams and sound cards with the same names. I’ve even thought the best way to determine the device the user wants to use (ie to configure a program) is to ask them to unplug and reinsert the device and then you know that they mean the last one in the list of devices. From there you can pick up the vendor/product/version for future use.

But there has to be an explanation – a proper, good, reason.

Yup. But if it is doing microframe 1 and missing microframe 2 and the processing of the microframes is all done in hardware…? More oddly on the beagleboard these missed microframes are happening mainly when bit 13 of the frindex is set you can hear the noise pulse. Buffer filling is not a problem the music plays in exactly the same time on my Iyonix with no noise using exactly the same code. If buffer filling was too slow it would take longer to complete.

The trouble with that as an explanation is that, if it were the case, nothing would work.

Prior to the revC4 board USB didn’t work properly there were dropouts and devices disconnecting. The solution on the internet was a 22uF capacitor on the 1.8v rail. This problem is supposedly fixed on the revC4 board.

Would that be the hard disc connected to
‘Sunplus Innovation Technology.’
‘USB to Serial-ATA bridge’

I may be wrong, but I think that connects the optical drive.

The survival of your hard disc is down to it being good old spinning rust

No, there’s no spinning rust. Just a 64GB SanDisc SDHC card. The ARMiniX uses a dual partition SD card as the main HD. There’s a small Fat partition that holds the bootloader, OS, and some stuff to control way this gets to connect RO to the hardware.

You may recall that for ages I’ve been installing your modules from my SDFS main ‘hard disc’ before you had it shift to ram.

Jim

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

The maker and device strings are probably the safest way
That’s what USBAudio gives you now.

Yes, I know. Its probably what I’ll use as the device identifier/locator. But strings can be a PITA for this as you may have to load and parse ones with spaces and assorted non-alphanumeric characters. Makes some operations more fiddly.

The problem with the USBXX values is that they may change. In theory the user will know they’ve done something to cause this. But in practice I and others will doubtless forget this. :-)

The reason that they didn’t include a USB1 controller on board is that the board usb sockets are not connected directly to the usb controller. The sockets are from an onboard usb2 hub so a USB1 controller could never have been used by external periferals.

FWIW I’ve now bought another 7-way mains powered Hub and connected it to one of the rear sockets on my ARMiniX. Plan to experiment with using this for devices I want to add and remove and see if it is better/worse/same as hanging things from a hub on a front socket. The rear sockets are direct from the PandaBoard IIUC. Whereas the front ones go via an added, seperately powered hub inside the ARMiniX.

Jim

Yup. But if it is doing microframe 1 and missing microframe 2 and the processing of the microframes is all done in hardware…?

I’m hoping that these missing frames are not going to turn out to be down to some hardware/HAL weirdness like the way the onboard audio clips! That seems to be something that isn’t fixable so you have to scale down the values to avoid it! At least that avoids the problem, at sacrifice of quality.

Jim