How to do USB audio

Ok try IsocRecorder.zip

I’ve had to make changes to work with release2 (class 2) devices so that part is untested. It should get as far as line 137 which will tell you the frequency set.

If it works I don’t know if the wav file will be playable it will be 24bit in a 4 byte channel – the empty byte isn’t removed.

Jim: Forget about clock multiplier. There is no clock multiplier.

If it works I don’t know if the wav file will be playable it will be 24bit in a 4 byte channel – the empty byte isn’t removed.

I’ll try it shortly and report back. Leaving in the null bytes is OK provided the header says the file is 32bit / 4bytes per sample / etc. That’s what I’ve been doing.

Jim: Forget about clock multiplier. There is no clock multiplier.

Confirmed. arecord -v tells me the exact rate: 96000 (96000/1) which I think also says so.

Jim

Leaving in the null bytes is OK provided the header says the file is 32bit / 4bytes per sample / etc.

It won’t it will say 24 bits / 4 bytes. Which I think should work from what I’ve read. If you want it to be 32 change line 34

It won’t it will say 24 bits / 4 bytes. Which I think should work from what I’ve read. If you want it to be 32 change line 34

Never mind… it works fine anyway. :-))

YES! Your modified recorder makes 96k/24 recordings from the 2i2 and I can then play the results. (So far, just exciting test tones.)

So what’s wrong with my [expletive] recording program then?!

Jim

I thinks its because you are using buffersize which is the size of the USB buffer as the size of the block to read and write when it should be sizeof(datablock)

I’ll check.

However my first reaction is that the buffersize value changes with the chosen rate as I make it 0.2 sec worth. But the size of the datablock ‘array’ is fixed at the max amount of space I need for the highest possible rate. However maybe I’ve muddled these in the program.

Part of my problem is the familiar one. I look at the program and tend to see what I thought I wrote rather than what I typed! This affects me when I write articles as well. There I go and do something else for 2 – 3 days before reading again.

I may be misunderstanding this but I can’t see it. To clarify I will summarise and hope that any muddle on my part can then be pointed out!

I start the program with a

char datablock[307200];

This defines a block of 307200 bytes starting at the memory location/address datablock. I am using ‘char’ because I developed that habit decades ago because the old compiler didn’t
provide a ‘byte’ type.

I set buffersize as a signed (4byte) int to be large enough to contain 0.2 sec of audio
data at whatever sample rate is to be used. Since as a hack I’m forcing 4 bytes per value for the 2i2 I use

buffersize=srate*channels*framesize; buffersize=buffersize/5;

as the framesize is 4. The result should be that the value of buffersize is the number of bytes per 0.2 sec bufferload.

I then Open for input with

  iblock[0]=srate;                  /* sample rate */
  sblock[4]=(char)bits_per_sample;  /* audio resolution (bits) */
  sblock[5]=(char)framesize;        /* bytes per channel for transfers */
  sblock[6]=(char)channels;         /* number of channels */
  sblock[7]=(char)1;                /* 1 for LPCM */
  sblock[8]=(char)0;
  iblock[3]=buffersize;   /* output buffer size (bytes) */
  rin.r[0]=(int)deviceID;
  rin.r[1]=(int)sblock;
  _kernel_swi(USBAudio_OpenIn,&rin,&rout);
  recordhandle=rout.r[0];

The aim being that I tell the OpenIn the size I’ll be using to capture 0.2 sec of audio per buffer fill. sblock and iblock are pointers (addresses) to the same place, but one is offset in 4byte ints and the other in bytes. Makes it easier to load a mix of bytes and ints into the block for the OpenIn. (The comment about output buffer is because I copied some of this from my player program. :-) )

That all seems to work and give a non zero recordhandle.

However when I then start

  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);

But although this seems to work fine for 44.1k and 48k it never seems to reach the condition set in the while() for the higher rates. Given the low rates are OK and I’ve allocated a datablock big enough for 192k at 4 bytes per value I’m puzzled. Its also much like what I use in other programs. So what’s the mistake? I still can’t see it, so it must be pretty daft! :-/

Jim

Ok what happens if you set

buffersize=(srate/8)*channels*framesize;

and

 iblock[3]=buffersize*4;   /* output buffer size (bytes) */

Sorry, I get the same behaviour at 96k as before if I make those changes.

Is the idea that OpenIn and GBPB differ in that one wants a size in frames but the other in bytes? If so, the puzzle is why record is OK at 48k and also play (using essentially my same code) plays OK even at 192k.

Added: And if I try 48k that way the file seems too short for the real-world elapsed time taken to record it, and a test tone clicks regularly as if broken into snippets with missing sections.

My understanding is that for both the USBAudio OpenIn/OpenOut calls and GBPB the buffersize value is given in bytes. In general that seems to work correctly… except when I try to record above 48k.

Jim

It was just a thought. There doesn’t seem any point in not dealing in whole frames – that is how they are transferred. If the usbbuffer fills completely then bytes will be lost so you want usbbuffer bigger than the size you read.

My impression is that it never emerges from the loop. i.e. that rout.r³ never gets to zero.

Did you test that theory by printing out rout.r[2] and rout.r[3] inside the loop?

Did you test that theory by printing out rout.r² and rout.r³ inside the loop?

No! Thought of it but kept trying other things. I’ll try it, but probably tomorrow now.

Question is though: WHY doesn’t the loop finish? Works in my player at all rates and works here at the lower rates. What’s the problem? At one point I wondered if we’d hit some hardware limit on input. But your recorder blew that theory away. So I’m still baffled. Maybe Dave will now come along and spot the cause…

Jim

Typing this in again as I did it once and was dumped by the server.

Must be ‘tomorrow’ already as I have now tried showing the values.

As you’d expect, at 48k the values keep changing as data is shovelled though.

At 96k I get “43872 153600” over and over again. So yes, the loop never ends.

The above are rout.r[2] rout.r[3] and the buffer size set is 153600.

So why is the loop failing to do anything to proceed? And what is the mystical significance of 43872? Am I counting the names of God, or how many universes have a value of Pi equal to three even on small scales?… 8-]

Jim

Won’t help you here since the usual sample rates can be divided by 5 but:

buffersize=srate*channels*framesize; buffersize=buffersize/5;

will not be a multiple of channels*framesize if srate is not a multiple of 5.

You should use:
buffersize=srate/5; buffersize*=channels*framesize;

At 96k I get “43872 153600” over and over again.

43872 is the buffer pointer and 153600 is the buffer size. As bytes are read the buffer pointer increases and the buffer size decreases.

This shows that nothing is being read. I would suspect that the file hasn’t opened is there an error from USBAudio_OpenIn

Andre: Take your point about the way to set the buffersize. Yes, what I’m doing now is ‘safe’ with the rates I’m personally concerned about at present, but I’ll change to the way you suggest.

Colin: I’m not using the ‘X’ version of the swi. I can do that to check. However I’ve been relying on checking that the recordhandle value returned is not zero to indicate the open was successful.

FWIW The output wave file is probably OK as I the program creates the header just before it begins to run the loop. And I see a file containing the 44byte header appear. So I’m left feeling that for some reason the GBPB is failing to be able to read in. Yet it is OK at the lower rates.

More tomorrow! :-)

Jim

_kernel_swi uses the X version of the swi by default so will return an error the way you have used it.

OS_GBPB isn’t reading anything.

Didn’t know that _kernel_swi did that! I’ll see if I can check for any error, but I’ve assumed until now that if there was one the handle would have been returned as a null value.

I’m still puzzled by this because:

Play works. My recorder work up to 48k. Your recorder works at all rates.

So I’ve started wondering if this may be something going awry in the way the USBAudio call to OpenIn handles rates above 48k for this device. Or that I’m missing some detail of how I need to use it.

I’ll be busy with other things most of today. But when I get a chance I’ll modify my Probe program. I think the 2i2 returns having a ‘range’ of rate for recording but a set of rates for play. At present my Probe fails to make sense of a ‘range’ so I’ll see if I can fix that. I’m wondering if along with this something else needs to be done for the high rates to work for recording. Failing that maybe Dave can spot what I’d doing wrong.

Jim

Fixing your probe program isn’t going to help. Its a simple matter to get information out of your program to find out what is wrong rather than guessing.

1) print out any errors from OS_GBPB and USBAudio_OpenIn

2) print the values returned if no error to see if they are what you expect. That includes printing out the values in the block passed to USBAudio_OpenIn.

Once you have done that if there are no errors and the block returned from USBAudio_OpenIn matches the endpoint I use then we have mystery.

I’ve started wondering if this may be something going awry in the way the USBAudio call to OpenIn handles rates above 48k

It doesn’t handle any rate differently from any other. Nor does it need to.

That includes printing out the values in the block passed to USBAudio_OpenIn.

That would be useful.

If USBAudio_OpenIn returns a non-zero number in R0, then either the stream is open and R0 is the stream number, or there was an error and R0 is a pointer to an error block, which would be a number in an entirely different range. So printing the stream number would also be useful.

Afraid I haven’t been able as yet to work out how to get at the error report from _kernel_swi. I can see that is should return a structure pointer, and I can see the structure details listed in kernel.h but despite experimenting can’t get a way to read the error number, etc. So I’d welcome someone explaining how to do this by giving a simple example. The old Acorn C/C++ book simply tells you to read kernel.h. Great for people who already understand. Just that I’m not in the relevant group. :-/

However I have printed values from regs, etc. And it does look like the OpenIn is failing. Having added the code to list register values I ran the Recorder twice. Once set to 48k, then to 96k The results are as follows:

First, 48k, which works:

 Simple USB Audio Recorder ver 0.5
 =================================

 Enter duration [mins] => 0.05
 Record for  3 sec [  15 0.2 sec blocks ]

Wanted Maker = *Focusrite*
      Device = *Scarlett 2i2 USB*
Record 48000 samples/sec  2 channels  24 bits per sample  4 bytes/frame
Output directory = RAM::RamDisc0.$
Buffer size set to 76800
List of devices by ID = USB15,USB12
Examine USB15
Maker = *Focusrite*
Device = *Scarlett 2i2 USB*

 *** Wanted Device Found = USB15 ***

Examine USB12
Maker = *Cambridge Audio *
Device = *Cambridge Audio USB Audio 2.0*


Done
Will record using USB15
 Enter output file name => fred/wav
Recording using device USB15
Output written to RAM::RamDisc0.$.fred/wav
OpenIn report: recordhandle = 239
start recording
Payload to write = 1152000

 min  sec   left  right [dBFS]
   0    0  -60.0  -60.0
Input to GBPB = 4 239 43988 76800 => Output 4 239 63164 57624
Input to GBPB = 4 239 63164 57624 => Output 4 239 63164 57624
Input to GBPB = 4 239 63164 57624 => Output 4 239 63548 57240
Input to GBPB = 4 239 63548 57240 => Output 4 239 63548 57240
Input to GBPB = 4 239 63548 57240 => Output 4 239 63548 57240
Input to GBPB = 4 239 63548 57240 => Output 4 239 63548 57240
Input to GBPB = 4 239 63548 57240 => Output 4 239 63548 57240
Input to GBPB = 4 239 63548 57240 => Output 4 239 63548 57240
Input to GBPB = 4 239 63548 57240 => Output 4 239 63548 57240
Input to GBPB = 4 239 63548 57240 => Output 4 239 63548 57240
Input to GBPB = 4 239 63548 57240 => Output 4 239 63932 56856
Input to GBPB = 4 239 63932 56856 => Output 4 239 63932 56856
...

Now 96k which doesn’t

 Simple USB Audio Recorder ver 0.5
 =================================

 Enter duration [mins] => 0.05
 Record for  3 sec [  15 0.2 sec blocks ]

Wanted Maker = *Focusrite*
      Device = *Scarlett 2i2 USB*
Record 96000 samples/sec  2 channels  24 bits per sample  4 bytes/frame
Output directory = RAM::RamDisc0.$
Buffer size set to 153600
List of devices by ID = USB15,USB12
Examine USB15
Maker = *Focusrite*
Device = *Scarlett 2i2 USB*

 *** Wanted Device Found = USB15 ***

Examine USB12
Maker = *Cambridge Audio *
Device = *Cambridge Audio USB Audio 2.0*


Done
Will record using USB15
 Enter output file name => bill/wav
Recording using device USB15
Output written to RAM::RamDisc0.$.bill/wav
OpenIn report: recordhandle = 540194436
start recording
Payload to write = 2304000

 min  sec   left  right [dBFS]
   0    0  -60.0  -60.0
Input to GBPB = 4 540194436 43988 153600 => Output 536881188 540194436 43988 153600
Input to GBPB = 4 540194436 43988 153600 => Output 536881700 540194436 43988 153600
Input to GBPB = 4 540194436 43988 153600 => Output 536878116 540194436 43988 153600
Input to GBPB = 4 540194436 43988 153600 => Output 536878628 540194436 43988 153600
Input to GBPB = 4 540194436 43988 153600 => Output 536879140 540194436 43988 153600
Input to GBPB = 4 540194436 43988 153600 => Output 536879652 540194436 43988 153600
...

The recordhandle values are clearly very different, and although the register values for GBPB change for 48k they clearly don’t for 96k. (I’ve snipped the lists as they were quite long!

Anyone diagnose from this? It looks like the OpenIn is failing, but why? And if I know how to I’ll get the error number and string printed and report the results.

Jim

BTW I want to change my Probe so I can use it to show the ‘range’ output for the record sample rates correctly. If nothing else this is the first device I’ve got that does this.

I also wonder if this is why OpenIn is failing for some rates and not others.

FWIW Focusrite have just offerred to loan me a new 2i2. I may get this and see if there is newer firmware that behaves differently. The one I have is fairly old and has ‘version 1’ firmware. But I guess the bottom line here is that it works with Colin’s recorder, so should work with mine as well!

Jim

_kernel_oserror* err = _kernel_swi(whatever);
if (err != NULL) printf("%s\n",err->errmess);

Handle values are normally in the range 1 to 255. A value of 540194436 is clearly a pointer to an error block.

Thanks, Colin! I’d been shooting all around the target trying to guess how to get the error. Once I saw your example it made sense. :-)

Results now for 96k are below.

 Simple USB Audio Recorder ver 0.5
 =================================

 Enter duration [mins] => 0.05
 Record for  3 sec [  15 0.2 sec blocks ]

Wanted Maker = *Focusrite*
      Device = *Scarlett 2i2 USB*
Record 96000 samples/sec  2 channels  24 bits per sample  4 bytes/frame
Output directory = RAM::RamDisc0.$
Buffer size set to 153600
List of devices by ID = USB15,USB12
Examine USB15
Maker = *Focusrite*
Device = *Scarlett 2i2 USB*

 *** Wanted Device Found = USB15 ***

Examine USB12
Maker = *Cambridge Audio *
Device = *Cambridge Audio USB Audio 2.0*


Done
Will record using USB15
 Enter output file name => bill/wav
Recording using device USB15
Output written to RAM::RamDisc0.$.bill/wav
OpenIn Error: 8517895 Device does not support this format
OpenIn report: recordhandle = 540518372
start recording
Payload to write = 2304000

 min  sec   left  right [dBFS]
   0    0  -60.0  -60.0
Input to GBPB = 4 540518372 44084 153600 => Output 536881956 540518372 44084 153600
GBPB Error: 222 Handle is either illegal or has been closed
Input to GBPB = 4 540518372 44084 153600 => Output 536878372 540518372 44084 153600
GBPB Error: 222 Handle is either illegal or has been closed
Input to GBPB = 4 540518372 44084 153600 => Output 536878884 540518372 44084 153600
GBPB Error: 222 Handle is either illegal or has been closed
...

As you’d expect 48k gives no errors.

Afraid I have no idea why the OpenIn error complains about the format. So far as I can see, the only things I’m changing are the sample rate and the buffer size. And Colin’s recorder works at 96k.

Jim