How to do USB audio

“No matching parameter set” happens when you try to play a file that requires a resolution, number of channels, sampling rate and subframe size that your USB audio device doesn’t support. UAPlayer doesn’t attempt to do any translation of the samples to meet the device’s requirements.

Well there is a small mitigation: if you provide (for example) 24 bit or 32 bit samples and 4 bytes per subframe to a 20 bit device, UAPlayer works out that there is a compatible set of parameters and asks for those.

What are the resolution, number of channels and sampling rate of the file you’re trying to play? What device are you trying to play it through?

I’m increasingly worried that the sample rates supported by modern audio devices often don’t include some of the rates we want and we used to have on earlier hardware. For example, iyoPhone requires 8 kHz, which is supported by the Iyonix’s internal sound card, but not by any inexpensive USB audio device I’ve yet seen. It’s fairly common for devices to support only 48 kHz, which is no use even for playing a CD.

Sample rate conversion, done properly and efficiently, requires lots of CPU cycles (multiply-accumulates). It’s OK on a general purpose DSP, but would consume an intolerable amount on any ARM CPU.

So, to be useful in practice, what sample rates do we need so support, and what devices can we short-list that support them?

Or can we get DSP going on one of the modern platforms that includes a DSP?

The device is the reportet and the samples are yours (48kHz and 44,1kHz). Both shouldt work.

Raik.

Your device plays 44100 and 48000 2 channel 16 bit audio so after loading the new USBModules run !IsocPlayer then double clicking an a 44100/2/16 or 48000/2/16 wav file should play.

To get !IsocRecorder to work change line 44 in Run from

 usb$=FNusb_findDeviceByVendor(&d8c,&13c,-1)

to

usb$=FNusb_findDeviceByVendor(&d8c,&139,-1)

ie change the &13c to &139

!IsocRecorder will start recording as soon as it is run and save the recorded file on the ram disc.

You device can only record 48000 or 44100 16bit mono

After recording double clicking on the recorded file will play it.

Raik: if you mean the samples from my web site, they are mono (recorded from a headset). Your device only supports stereo replay.

If you rip a track from a CD as a stereo WAV file, it should play OK.

There are some devices that support both mono and stereo playback (I have one, and I have access to another), but the cheapest ones don’t in my experience.

What strikes me about the devices I’ve seen is how many use ‘C-Media Electronics Inc’ firmware. Even one of Jim’s expensive dacs has it.

I can’t help but wonder if you aren’t going to be making things more difficult for yourself by doing it this way?
It isn’t so hard to make a little desktop application to oversee music playback…

One thing I would suggest is that you try – if possible – to separate the fancy UI and the physical playback. This is because you cannot tell what the latency of the Wimp polling will be.

For me the problems are that I’ve never successfully written anything as a desktop wimp apps, and don’t know enough to do something like !PlaySound + PlayIt which does as you suggest. So I’d have to do a lot of hard puzzling to deal with that in addition to checking I can get Colin/Dave’s modules to work and that I understand them.

So I initially will write something that runs in a taskwindow just for test purposes, then look at using the graphics ability of GraphTask to do something that provides a more convenient interface. Which means that after the most simple starting tests I’ll try using GraphTask. I appreciate this seems odd to anyone competent programmer who finds writing wimp tasks easy. But alas the plain truth is that I’m not much of a programmer and haven’t had any success with wimp apps in the past, and am baffled by module code.

As I’ve said before, I’d urge anyone who is cleverer than me to do a decent wimp amp + modules player. Something I’d welcome. I’m doing this to try and focus on my own learning how to explain. I can then explain Colin/Dave’s modules and their interfaces in terms similar to the examples I’ve given for other areas in the ‘ROSS’ document which I did to bring together audio details not in the PRMs. Helps me to learn and explain. Not trying to write a player that everyone else will then use. I’m happy if they just sigh when they see it and someone decides to do it properly.

I’d encourage an urge by someone to nudge me out of the way and do it properly because I’m clearly making a mess. :-) Failing that I’ll muddle along as best I can. As the French nearly say: It’s not magnificent, it’s a railway station. ;→

Jim

I’m increasingly worried that the sample rates supported by modern audio devices often don’t include some of the rates we want and we used to have on earlier hardware. For example, iyoPhone requires 8 kHz, which is supported by the Iyonix’s internal sound card, but not by any inexpensive USB audio device I’ve yet seen. It’s fairly common for devices to support only 48 kHz, which is no use even for playing a CD.

This is why I was makin a fuss about upsampling, etc, a while ago. From the tests I did (and the !Upsampling demo) it seems quite feasible with modern RO software to do the resampling in the player. Have my doubts it can be done so well at the module level, but I’m not competent to really say on that. I doubt anyone who wanted to play an 8k rate file would complain if the result wasn’t superb audio quality. But 44.1k to 48k is a real PITA to do well. Should be feasible in an app, though. That said, 44.1k to 96k is easier to do well.

FWIW for anyone who has missed them and interested: The Upsampling demos are on my audiomisc.co.uk software page. They use x2 as the simplest example. But using pre-computed sets of coefficients other ratios would work about as quickly. Just need sets of coefficients to cycle around as the phases change between the sample instants. At present I’m assuming any ‘learning’ player I write will just ensure a match of byte-depths so as to play, say, 16bit on a device that wants 24 or 32. But I could add a demo of resampling as part of the player as well if I ever get that far and its would be useful. I’m a long way from that at present, though!

Jim

What strikes me about the devices I’ve seen is how many use ‘C-Media Electronics Inc’ firmware. Even one of Jim’s expensive dacs has it.

I think many makers have simply used the same USB interface chip/software as it works OK. This may be a “good thing” from our POV as it makes for a more stable target. :-)

How they process the data once it emerges from their USB interface in the DAC is another issue. For an audio company that’s probably where their focus is placed and what they sell on.

Jim

Re Downsampling- Using Colins record prog I put an inbetween buffer that discards every second 16 bits and sets the affected words in the header. This did achieve a 24000 mono wav but the quality is not good due to a mosquito like static proportional to the amplitude of the audio. From googling, the approach for downsampling seems to be to use a low pass filter /before/
the sample reduction. I’m not sure if any smoothing of the reduced samples is done. I am wondering if reducing to 8 bit audio would cut the high frequency, or perhaps a physical low pass filter inline with the microphone. I think the low levels of a microphone might prove to be difficult to filter wihout attenuating, but I might experiment with a line level device and an equalizer to see. I’m trying these low tech approaches only because they dont take up processing power.
The buffer from USB, is there any way to make it return word aligned data? From memory you had to take whatever the device gave you.
There seems to be room to do something while receiving data if the lengths of the blocks are anything to go by. I’m assuming that if things are tight it would go for more of the 1k+ blocks rather than a minority of times.

the approach for downsampling seems to be to use a low pass filter /before/ the sample reduction.

Absolutely right. Once you’ve removed energy above the new lower Nyquist frequency, you are justified in removing the excess samples.

I’m not sure if any smoothing of the reduced samples is done.

The low pass filtering inherently smooths the reduced samples.

From googling, the approach for downsampling seems to be to use a low pass filter /before/the sample reduction.

You can do the filtering and downsampling in the same calculation. e.g. just use the same sort of method I use for upsampling via a ‘transverse array’ in the time domain. This also covers any “smoothing” you want to do. The demos show how you can either use the classic sinc-based way or mimic an analogue low-pass filter, etc.

I’m not sure if any smoothing of the reduced samples is done. I am wondering if reducing to 8 bit audio would cut the high frequency, or perhaps a physical low pass filter inline with the microphone.

Converting to 8bit isn’t likely to reduce the HF. Indeed, unless you dither it may add garbage. An analog filter on the input can fix the problem if it works well enough. Indeed, in principle all ADC processes should be preceeded by a filter to define the accepted bandwidth to a range that avoids such problems. Although you may find a cheap ADC lacks this because they saved the money.

Jim

The buffer from USB, is there any way to make it return word aligned data? From memory you had to take whatever the device gave you.

No you get the data in the format sent from the device.

I’m making some progress with using Dave’s USBAudio calls, but this has thown up something I’d like to clarify.

EnumerateResolutions gives me one resolution for my DAC Magic Plus. This is 24 bits. However to play a wave file via Colin’s player that gives me something like

which looks like the USB2.0 method using 4 bytes per value to me.

Does that mean that EnumerateResolutions does indeed specify the actual DAC resolution and not the size of the values that have to be sent for a DAC like this?

I was hoping that USBAudio calls would tell me the number of bits/bytes per value to be streamed/saved.

That in turn raises another matter I’ve not got to testing yet. Hope to sometime tomorrow.

I’d thought I could try using the USBAudio calls to tell me what I’d need to save to a ‘file’ using the naming system Colin’s modules / prog uses. But the above implies I’ve either missed something or that isn’t the case.

I’ll have another look at your test codes tomorrow, had enough for today, but I thought I’d post this in case you can clarify my dimness!

BTW Not previously had much to do with Unicode. So I was surprised to see that the DAC ‘names’ returned have a first byte that gives the length of the unicode string. Convenient. Is that standard? If so, makes life much easier. :-)

Jim

@Colin

I have a short try on my Pandora. Wow, both IsocPlayer and -Recorder are working fine. Record and Play the mono wav.
Many thanks.
I hope I find the time to testing more. I have not a stereo wav by the hand. I will convert one with lame.

‘No you get the data in the format sent from the device.’
Colin
Thanks for making that clear, I spent quite a while catering for the 16bit boundaries, but for more extensive processing and downsampling to 8000Hz a buffer using a boundary dividable by 12 words would make things easier. a factor of 16 words would cope for other 48000 derived rates, so a size of 12×16 words or 24×32 words (or bigger?) would simplify the BASIC repeat loops. It may be easier to use two buffers so that one can be emptied before the second can be overflowed, and just toggle between them with a flag.

Dave and Jim, thanks for the support regarding filtering. a bit later, maybe.

Does that mean that EnumerateResolutions does indeed specify the actual DAC resolution and not the size of the values that have to be sent for a DAC like this?

Yes. That’s what I have always understood resolution to mean.

I was hoping that USBAudio calls would tell me the number of bits/bytes per value to be streamed/saved.

To find the subframe size (the number of bytes per sample for one channel), use EnumerateSampleRates.

Ronald.

I don’t think you need to double buffer. The DeviceFS buffer is circular so as a block of data is removed by your program the space becomes available for filling by usb. So you have to deal with the data removed before the circular buffer fills again in the background.

Dave and Jim, thanks for the support regarding filtering. a bit later, maybe.

FWIW I’ve written an article or two on this for ‘Archive’ mag that should appear soon. There is also some stuff on the web, which I’ll add to in time.

Jim

To find the subframe size (the number of bytes per sample for one channel), use EnumerateSampleRates.

Ta! :-) I’d stopped last night before I had reached looking at that swi. Have a go today.

Thanks,

Jim

Would it be more useful if EnumerateResolutions returned resolution and subframe size pairs, instead of just resolutions?

I see that you are returning values on an error in your API. This isn’t a good idea because _swix won’t return the value if there is an error. Thats the problem with using OS_ReadVarVal.

The other point I noticed is that the list of sample frequencies in enumerate sample rates is either a list of samples or a range – following the class 1 audio descriptor model. But class 2 audio allows multiple sample ranges. I think it would be better to just return a list of sample ranges.

I see that you are returning values on an error in your API. This isn’t a good idea because _swix won’t return the value if there is an error.

I may be having a dense moment (my mind is full of Windows rubbish right now!), but I don’t understand what you mean. Can you put some detail on what you wrote, or provide an example, please?

I think it would be better to just return a list of sample ranges.

Well, at least be able to return a list of ranges in addition to single values, yes. Right now the module only stores one range. When I can raise some enthusiasm, I’ll update it.

if you have

_kernel_oserror* e = _swix(OS_AnySwi,_OUT(2),&size);

size is unchanged if e != NULL.

Well, at least be able to return a list of ranges in addition to single values

Then you need a separate flag to tell the user that the list is a range list or a value list. May as well save the user having to write 2 procedures 1 to cope with ranges and one to cope with discrete values.

OK, I can now get the DAC to list its details OK using the USBAudio calls. But I’m clearly not understanding what to do to get playout.

Initially I tried just “write to a file” using fwrite and using a file with a name following the syntax like

However such attempts compiled and ran with no complaint, but gave no output. So that’s clearly wrong. I then tried going via USBAudio_OpenOut, etc. But there I get either no audio or the program crashes. e.g. if I use

void playout(void)
{
  char sblock[32];
  int* iblock;
  FILE* playhandle; 
  int playcount,playstop; 
  iblock=(int*)sblock; 
  iblock[0]=96000;
  sblock[4]=(char)24;
  sblock[5]=(char)4;
  sblock[6]=(char)2;
  sblock[7]=(char)1;
  sblock[8]=(char)0; 
  iblock[3]=8000;
 rin.r[0]=(int)"USB10#nopad;noblock;size768000;samplerate96000;samplesize8;interface1;alternate1;endpoint1:\0";
  rin.r[1]=(int)sblock; 
  _kernel_swi(USBAudio_OpenOut,&rin,&rout); 
  playhandle=(FILE*)rout.r[0];
  if(playhandle==0)
  {
    printf("Open failed!\n");
  }
  else
  {
    printf("start play\n");
    playcount=0; playstop=48; 
    do
    {
      fwrite(outblock,sizeof(int),8000,playhandle);
      playcount++;
    } while (playcount<playstop);  
    rin.r[0]=(int)playhandle; 
    _kernel_swi(USBAudio_Close,&rin,&rout); 
  }
  printf("play done\n"); 
}

If I try the above with just “USB10” the program runs but gives no output.

Sorry about this, I clearly still don’t get it. Can you kindly explain how the above should be changed or got to work?

Jim

Sorry if anyone read the utter mess that this site made of the above code until I found the magic formula of using pre and code nested. Afraid I find ‘textile’ a right PITA!