How to do USB audio

Has anyone tried a Cambridge Audio DAC 100? I can’t remember!

I’m now getting predictable questions wrt which DACs will work OK and which not. So want to make a list of ones known to work.

BTW CJE have said they have ordered some Behringer UCA202s and should have them for sale at a show soon. And I’ve now been told that the 2i2 (96k24 ADC+DAC) I can try out should be posted to me later today. So all being well, I’ll know if that works in a few days time.

Jim

I can confirm that simultaneous record and replay works.

I just threw together a back to back USB audio application, using the iMic at 32 kHz/16 bit/stereo, with a DRU-R100 USB radio as the source and some usb-powered speakers as the replay destination. Turn on another FM radio adjacent, and I can hear an echo because of the time delay going through the iMic and buffers.

Good to hear that symultaneous in/out works. I’m hoping to use that sometime!

I’ve now done some measurements on the behaviour of the UCA202 and the results look fairly good.

The sensitivity for input is that 1.212 Vrms at 330Hz gives -0.5dBFS. Which implies that the max level without clipping is about +/- 1.8 Vpeak.

The THD is about 0.01% so fairly minimal.

And no sign of any gross clocking problems at either 44100 or 48000 sample rate. i.e. no obvious signs that samples are being lost or duplicated, etc.

The noise level seems a few dB above the nominal 16bit, but not enough to bother anyone I suspect. And the response seems pretty flat.

I’ve modified my recorder program so that it displays the peak levels during recording. Makes it easier to monitor what you’re recording and avoid clipping or recording at too high or low a level. When I get a chance I’ll put a copy on the website for people to use if they wish.

And I’ve been told that the 2i2 (96k/24 capable) has been posted to me. The delay is because it went 2nd class mail. Profit motive rules. The daughter who took it to the post office used some of the money for ‘iced buns’. :-)

Jim

I’ve now put a copy of my slightly improved audio recorder up at

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

As supplied it runs single-tasking. But you can alter the !Run file and it will then work with !DrawTask or run in a TaskWindow if you prefer. Main improvement is that it now shows the signal levels as recording proceeds.

So far I’ve only been able to test it with the UCA202. One the 2i2 arrives I’ll set about ensuring it works with that as well. At some point I’ll put links to the progs onto my main software page along with a brief explanation of their use.

Jim

I’ve been soft loading Colin’s Iyonix RISC OS image for a couple of days. It works, but there are some things I’d like to straighten out.

1) When I boot the Iyonix, it is more likely to boot when I don’t have a load of USB devices plugged in. I can also hear the floppy drive being tried sooner with just the keyboard. (This is the ROM, before any softload.) But boot of the softload seems even less reliable; I’ve had it hang several times this evening. It really didn’t want to boot this evening; all the devices I had were plugged in via a D-Link 7 port hub. The devices were keyboard, mouse, DRU-R100 radio, webmail notifier and iMic.

2) What is the correct thing to do when closing a USBAudio output stream? I’ve had numerous hangs on quitting my UAPlayer app while playing something, until I changed it to stop filling the output buffer and wait until it was empty before closing the stream. Is there a quicker way?

3) What is the correct thing to do when closing a USBAudio input stream? I’ve not played much with this, and I’ve not had anything hang. But it doesn’t work the same with input; you can empty the buffer, but you can’t guarantee that it will still be empty when you close the stream. There may be no problem; I’d just like to know.

4) While running the back-to-back record-replay test, I found that it would report “Bad request” when I dragged the volume slider – usually not straightaway, but always very soon. The code is almost all from UAPlayer, which never has that problem reported. There is no code to use the record side controls – the only record side stuff is OpenOut and Close – so I don’t think it’s directly related to the USBAudio module. I can get a USB capture to see what was sent and what was received. (Clearly it will be quite busy with isochronous audio flowing.)

When I boot the Iyonix, it is more likely to boot when I don’t have a load of USB devices plugged in.

Are the devices plugged in directly? Or via externally powered hubs? I always use external hubs to ensure the power drawn doesn’t come from the host machine.

I’ve taken for granted that you must allow a complete transfer of the most recent buffer-full of data before closing. Am I misunderstanding what you said?

While running the back-to-back record-replay test, I found that it would report “Bad request” when I dragged the volume slider

Do you get the same problems on newer/faster machines? My first thought is that what you’re doing may simply be too fast for the Iyonix so one process is falling over another. But as is already clear, I don’t understand the actual buffering and transfers beyond using them! :-)

BTW I’m also wondering if using two different devices for symultaneous in/out might be problematic if their clock behavious differ in some way. May work better using the same device?

Jim

Difficult one

1) iyonix boot

As regards not booting I generally have no problems. I tend to find that certain devices cause problems. For example if I plug my hub with a HDD on it into your beagleboard hub it won’t boot. from the lights on the hubs I can see that the light for the HDD was the last one lit. If I plug the HDD in your hub or my hub directly into the beagle board then it boots ok. My release 2 DAC won’t work in release 1 mode when plugged into a high speed hub plugged into an Iyonix but it will plugged into the beagleboard. Then again the beagleboard ignores my DAC in high speed mode at boot but not in full speed mode. Once booted unplugging and reinserting the dac makes it work. I’ve been tracing these little niggles recently but can’t see a solution. Can you narrow it down to a particular device?

I’m not sure either that part of the problem isn’t the Iyonix. USB has always been a bit iffy for me I’ve found some sockets seem to have less problems than others.

2) I just close the stream. Once started an output stream always sends data, even if you don’t supply any, until they are closed. I waited until the buffer was empty just to be sure I played the end of the file. When you escape in my player it just closes the files.

3) again just close the stream. Input Audio streams always receive data until they are closed

4) bad request

Tricky one. All failures of the control requests are turned into ‘bad request’. The usual cause is the device stalling the pipe which is a ‘bad request’. I’ve been recording at 48000 mono with my recorder and playing 44100 stereo with your audio player this morning through the cheapo 7.1 sound card thingy waggling the volume up and down like a trombone and I can’t replicate it. Control requests are handled by a different process by the controller than isochronous and that hasn’t been touched

I discovered with this experimenting that I have a device which has problems with your module. venuswebcam.zip contains output from your ModuleTest1. I’ve also included output from my !descriptors – just search for ‘venus’. It may be related to it being a high speed release 1 device instead of the usual full speed release 1.

Now have the Focusrite 2i2. Getting puzzling results.

When I first tried it, my probe program listed 44.1k/48k/88.2k/96k for both playout and recording.

My first few tests used 44.1/48k. Worked Ok. So I then tried 96k.

This froze the recorder program.

Since then whenever I use my probe program I get odd results

 USB Audio Probe 1.0
 ===================

 Scans USB to find and report on the details of Audio devices
 Also checks to see which can play a given wave file

 Type in sample rate => 0
  number of channels => 0
     bits per sample => 0


 OK, scan looking for ability to play:
 rate =       0  channels =  0  bits/sample =  0

 Using USBAudio_EnumerateDevices to find out what is connected
 -------------------------------------------------------------

 List of devices by ID = USB16
 Device 1 => USB16
 Devices counted = 1
 

 Now examine each device in detail
 =================================

 Device  1 details
 ------------------
 ID [USB16]
 Maker  = *Focusrite*
 Device = *Scarlett 2i2 USB*
 Number of resolutions available =  3 
 play using  24 bits per sample using  4 bytes per subframe
  rec using  24 bits per sample using  4 bytes per subframe

[Rates buffer size used/needed = 44]
 play  ch = 2  res = 24  bytes/ch = 4  lpcm  number of rates = 4
 rates are:    44100    48000    88200    96000  samples/sec
  rec  ch = 2  res = 24  bytes/ch = 4  lpcm  number of rates = 0
 rates are:    44100  samples/sec
  rec  ch = 187  res =  0  bytes/ch = 0  eh?   number of rates = 0
 rates are:        0  samples/sec


 Now report any devices able to play the file
 --------------------------------------------

*

In effect the report for rec rates seems scrambled. Despite the above 48k recording still works and so does 44k. But 88.2 or 96k attempts freeze the recorder.

The freeze may be a bug in my recorder but the real puzzle is the probe report giving changed results.

I tried !USBDescriptors and that crashed with a divide by 0 partway though the replies from the device.

ModuleTest1 gives

*ram:moduletest1
USB16
Devices: 1
USB16
Lang ID: 0409
Manufacturer: Focusrite
Device name: Scarlett 2i2 USB
Descriptor length: 287
09 02 1F 01 04 01 00 80 FA 08 0B 00 03 01 00 20 
00 09 04 00 00 01 01 01 20 02 09 24 01 00 02 08 
77 00 00 08 24 0A 29 03 07 00 09 08 24 0B 28 01 
29 03 08 11 24 02 02 01 01 00 28 02 00 00 00 00 
0F 00 00 06 12 24 06 0A 02 00 00 00 00 00 00 00 
00 00 00 00 00 00 0C 24 03 14 01 03 00 0A 28 00 
00 00 11 24 02 01 01 02 00 28 02 00 00 00 00 21 
00 00 00 12 24 06 0B 01 00 00 00 00 00 00 00 00 
00 00 00 00 00 0C 24 03 16 01 01 00 0B 28 00 00 
07 07 05 84 03 06 00 08 09 04 01 00 00 01 02 20 
04 09 04 01 01 02 01 02 20 04 10 24 01 02 00 01 
01 00 00 00 02 00 00 00 00 0F 06 24 02 01 04 18 
07 05 01 05 00 04 01 08 25 01 00 00 02 08 00 07 
05 81 11 04 00 04 09 04 02 00 00 01 02 20 05 09 
04 02 01 01 01 02 20 05 10 24 01 16 00 01 01 00 
00 00 02 00 00 00 00 21 06 24 02 01 04 18 07 05 
82 05 00 04 01 08 25 01 00 00 02 08 00 09 04 03 
00 00 FE 01 01 0C 09 21 07 FA 00 40 00 10 01
** Sample rates **
Interfaces: 2
Interface 1, alternate 1
 Endpoint:       1
 Direction:      OUT
 Num channels:   2
 Resolution:     24
 Subframe bytes: 4
  Discrete (4)
  44100 Hz
  48000 Hz
  88200 Hz
  96000 Hz
Interface 2, alternate 1
 Endpoint:       2
 Direction:      IN
 Num channels:   2
 Resolution:     24
 Subframe bytes: 4
  Continuous (0)
  44100 Hz
  48000 Hz
  88200 Hz
  96000 Hz
** End of sample rates **
Entities found: 8
Entity type 10
 44100 Hz
 48000 Hz
 88200 Hz
 96000 Hz
 Terminal ID: 41
 Source ID:   0
Entity type 11
 Terminal ID: 40
 Source ID:   41
Entity type 2
 Terminal ID: 2
 Source ID:   0
Entity type 6
 Terminal ID: 10
 Source ID:   2
Entity type 3
 Terminal ID: 20
 Source ID:   10
Entity type 2
 Terminal ID: 1
 Source ID:   0
Entity type 6
 Terminal ID: 11
 Source ID:   1
Entity type 3
 Terminal ID: 22
 Source ID:   11
*

Which lists all the rec and replay rates OK when my probe doesn’t.

Any ideas/diagnosis? I don’t understand some of the details reported by ModuleTest1 and they look strange – but then I generally don’t understand such details anyway!

I’ll check my recorder program again as that may be problem wrt the freezes, but otherwise I’m puzzled at present. Close, but no cigar! :-/

Jim

It’s not enough information. If you send me the output from !usbdescriptors I’ll have a look at it.

If you are taking about my recorder program failing I can see 1 problem straight away – it doesn’t downsample the 4 byte subframe down to 3 bytes for the wav file.

Edit: forget that I just noticed you said usbdescriptors failed.

Can you send the output form USBDescriptors anyway.

If you are taking about my recorder program failing I can see 1 problem straight away – it doesn’t downsample the 4 byte subframe down to 3 bytes for the wav file.

Using my recorder (hacked to simply save the result as ‘32bit’ wave to save the bother of snipping the last byte per value.)

I’ll use !USBDescriptors again and put up the results. I’ll also stare at my recorder again in case I can spot something dumn I’ve done. Then I’ll try the 2i2 with Linux and see how I get on there.

Jim

Ok here http://jcgl.orpheusweb.co.uk/temp/2i2.zip are the results of using !USBDescriptors, my !USBAudioProbe, and USBinfo.

Note again that the first time I checked it, the device showed a different result for rec. And that I can use it to record 44.1k and 48k, but not 88.2k or 96k. I’m wondering if it has some kind of interface ‘switch’ I need to find.

Jim

Update: The 2i2 seems fine with my Linux boxes. I just did a test using

arecord -D hw:1 -r 96000 -c 2 -f s32_le test.wav

and then fed the inputs of the 2i2 with a 30kHz test tone (using my ROXTone program on another Linux box¹). The result is a nice 96k recording of a pretty pure 30kHz tone. I chose 30k to ensure that the actual recording wasn’t being ‘upsampled’ somewhere to give a 96k file from, say, an actual recording sampled at 48k. If that had been happening (despite my hw:1) the tone would either have vanished or turned up at the wrong frequency due to aliasing.

Only snag with the above as getting 32bit values in the file. i.e. with an added zero byte. But that’s trivial to fix. (The s32_le is needed as hw: does no conversions and the 2i2 sends/wants 4 bytes per value for transfers.)

I’ll see if I can get the results from a lsusb -v…

I guess it is encouraging that the 2i2 works with Linux as it means I can use one OK. But I’m hoping we can sort out the problem with it and RO! Having 24 bits per sample is nice, but the 96k is also very useful for me to use for measurements as well as making recordings.

Jim

¹ I’d set this to use the DAC Magic Plus at 96k/24 to produce a nice pure tone out.

That version of !Descriptors is old can you send the output from USBDescriptors.zip just to confirm what I have seen. From the decoding of Daves data you posted it should work perfectly. Does it play 96/24?

I’ll check using the new version of USBDescriptors. It works perfectly on Linux at 96k/24. But not on my ARMiniX. The problem may well be with my programs. In fact I hope it is! But as yet I’ve not spotted the problem. :-/

For reference I’ve now put the results from linux at

since I don’t understand them I’ve done a before, during, and after so it is possible to see what the 2i2 adds.

I’ll try the new USBDescriptors, but have to break off soon as I have to cook dinner.

Jim

OK, I’ve now downloaded the current !USBDescrptors. The result still crashes. I’ve put the results at

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

Note there are two files. One is with just the 2i2 connected. The other is with just the DMPlus connected. i.e. Each done with the other device not connected. Both runs crash! Am I doing something wrong?

Have to stop now but will resume this when I can.

Jim

I don’t know why !USBDescriptors isn’t working for you. The program displayed all of the descriptors here using the data you supplied to Dave.

Anyway it shows the info I was missing and I don’t see any problem. It’s a class 2 high speed device. If this doesn’t work nothing will.

Anyway it shows the info I was missing and I don’t see any problem. It’s a class 2 high speed device. If this doesn’t work nothing will.

Now had dinner but won’t do any more until tomorrow! I dunno why USBDescriptors now falls over. One thing I notice though is that Dave’s ModuleTest1 says Continuous(0) for the inputs and my Probe says 0 rates which I think comes from the same return. My Probe prog currently doesn’t understand ‘continuous’ returns.

Might this be what’s confusing my recording program? I just give the OpenOut a rate, etc, and assume it will be accepted. Do ‘continuously variable’ devices need different treatment?

I’ll check again in the morning. Too tired now! :-/

Jim

One final thought for the day. Might one of the ‘features’ be a clock multiplier value? i.e. I have to give it a ‘x2’ somewhere to get 88.2/96k rather than 44.1k/48? The puzzle is that 44.1k and 48k work fine, but double those rates doesn’t. Still haven’t spotted a problem with my actual program, but I am worn down, so may be blindingly obvious tomorrow! Hope so…

Jim

Does it ‘play’ at 96/24. You know your other devices play at 96/24 so the play programs are ok. If your device plays 96/24 then you know the frequency can be changed.

The good news is that there is no sign of a clock multiplier anywhere yet.

The mediocre news is that Release 2 doesn’t offer up the list of clock frequencies within the device descriptor; you have to interrogate the clock source. (Mini-rant: it’s just one of the things that makes Release 2 more difficult than Release 1 – for no apparent good reason.) Anyway, the EnumerateSamplerate SWI does the job, so, if the output from EnumerateSampleRates says it supports 4 frequencies, it does.

But it does mean that the device should be settable to all of the frequencies that it supports, by the same means. If it can be set to both of any two values, then all values should be accessible by the same means.

It’s funny, isn’t it… earlier versions of the USBAudio module had a SWI to set the sample rate. Then I added OpenOut and OpenIn, which set the sample rate as part of their functions, so I removed the SetSampleRate SWI. I had to make the sample rate setting in OpenOut and OpenIn not return an error, because some DACs refuse to have their sample rates set explicitly – they adapt to the incoming sample rate, and return an error if you try to set them. So now there is no way to know whether the sample rate setting part of OpenOut or OpenIn has been accepted.

We have the clock chain laid out for us by USBAudio_TextifySampleRates. Entity type 10 is a Clock Source with terminal ID 41. Entity type 11 is a Clock Selector with a single input whose ID is 41, i.e. the Clock Source. (No, I don’t understand the point of a selector with a single input, either. Part of the joys of Release 2.) The Clock Source has 4 sample rates: 44100, 48000, 88200 and 96000.

Clutching at straws: you couldn’t have used a 16 bit unsigned integer somewhere in the process of setting the clock rate, could you?

So now there is no way to know whether the sample rate setting part of OpenOut or OpenIn has been accepted.

How about a swi to read the current sample rate. Even if there are cases where it will fail it will be useful as a debugging aid.

Does it ‘play’ at 96/24.

Yes. It is quite happy to play 96k/24. No problem. I’m still baffled so I’ve put a copy of the current source code for recording at

http://jcgl.orpheusweb.co.uk/temp/2i2source.zip

and I’d welcome anyone spotting what might be the problem.

Note that I’ve added some lines that are labelled as ‘HACK’ to force output to be 4 bytes per value. This saves me the bother of trimming off the least significant null byte from each sample.

As yesterday, works fine for recording at 44.1k/48k 24bit but stalls when I try 88.2k or 96k. The output is being written to RAMdisc.

It goes though

  printf("start recording\n");
  
  write_output_header(buffersize*duration_blocks);
  printf("\n min  sec   left  right [dBFS]");
  printf("\n   0    0  -60.0  -60.0");
    
  il=0;
  do
  {
    rin.r[0]=4;
    rin.r[1]=(int)recordhandle;
    rin.r[2]=(int)datablock;
    rin.r[3]=buffersize;
    do
    {
        _kernel_swi(OS_GBPB,&rin,&rout);
        rin.r[2] = rout.r[2];
        rin.r[3] = rout.r[3];      
    } while (rout.r[3] != 0);

as far as showing the 0 0 -60.0 -60.0

then seems to stall. I can escape, change to 48k and it works. Go back to 96k and it stalls. My impression is that it never emerges from the loop. i.e. that rout.r[3] never gets to zero.

I tried commenting out the fwrite so it didn’t have to bother saving the results in case the fwrite was taking too long. But it still stalls. I also put the “here” and “done” labels in. These don’t show up.

Colin: Given the USB details could you write a version of your recorder prog that you think should work at 96k? Doesn’t matter if it dumps the output as 4 bytes per value, it is just to see if it works in getting the capture.

Baffled, so I’m hoping someone can spot a stupid mistake in my program which when fixed lets it work. As yet I don’t fully understand the comments about the Entity types or how to try setting the rate if the OpenIn isn’t doing it.

Jim

Anyway, the EnumerateSamplerate SWI does the job, so, if the output from EnumerateSampleRates says it supports 4 frequencies, it does.

May be more complex than that. When I use the swi it shows 4 rates OK for playout but only one for rec. (44100). It returns what looks like a 0 to indicate a continuously variable rate. So does this mean setting the sample rate has to be done differently? I’m calling OpenIn with the rate specified and getting a non-zero recordhandle. But maybe this still isn’t setting up the device fully?

I’ll have a break and see if I can use arecord -v to suss any details. IIRC thet does report anything like a clock multiplier factor, although I don’t really understand it! (Been saying that a lot recently! :-] )

Jim