How to do USB audio

OK, there’s a new version of the module on my web site in USBAudio.zip. No doubt you’ll let me know if this fixes the problem.

Yes. :-) Problem fixed. I can now run my program and have the data play at any rate the device supports OK. Thanks! :-))

I’ll see if I can use sox to generate some 32bit wave files and try them using your player.

Jim

Yes, Dave, on a quick test your player now works OK with my ARMiniX + DMPlus. :-)

I used sox infile.wav -b32 outfile32bit.wav to generate a 32bit version of a 44.1k/16bit wave file. Had to then run this though my !WAV_Cleaner as sox insists on giving a 32bit file an extended header. But the resulting 32bit wave file played Ok with your player.

Not yet tried using a 96k or 192k file as all the ones I have are large. So I need to snip off a small section and then make a 32bit version to try. All being well, I’ll check this later on. But it looks OK. :-)

Once that’s done I’ll modify what I’ve written to start playing wave files, padding sample sizes as needed.

Thanks. :-)

Jim

Just tried a 192k 32bit wave file (44-byte header) with your player, Dave.

Worked fine. :-)

Jim

Thanks for the good news, Jim. Maybe my efforts have been worthwhile after all :-)

@Colin

The descriptors output file you can find here .

Thanks

Thanks for the good news, Jim. Maybe my efforts have been worthwhile after all :-)

Yes, I’d say so. Not only you’ve produced some very useful modules, etc. You and Colin have also succeeded in overcoming my dimwit bafflement about how these things work to the point where even I’ve managed to make a working program! After that, anything is possible and you can both tell others that even an idiot can make use of your modules. :-)

BTW I still have a pen ready WRT the two prize/2 awards. Despight being an audiophile nutcase. 8-]

Jim

N.B. My own reward this afternoon is to go and try another of the old 2ndhand LPs I bought. The one I tried yesterday Mercury Mono LP of Pines/Fountains of Rome, rec c1960 had amazing peaks on it. Up to +18dBRIAA. Biggest I’ve found on any old LP and not from the few scratches! Today I’ll try a Gerald Moore LP where he accompanies various singers. Mono c1960 again… Hi rez, eh?

Raik.

This change that you made is correct and it should have worked.

IF usb$ = "" THEN
REM Syntek Semiconductor Video Capture Controller
usb$=FNusb_findDeviceByVendor(&5e1,&408,-1)
xInterface% = 2 
xAlternate% = 1 
xEndpoint% = &84 
xSamplerate% = 48000
xSamplesize% = 4 : REM 2 channel 2 bytes per channel 
xChannels% = 2
xBits% = 16
ENDIF

Could you download USBModuleDebug.zip make the same change to the version of !IsocRecorder in there. Then after running !USBModule from USBModuleDebug.zip run !IsocRecorder. Almost instantly the window will fill up with debug information. Can you send me the debug information – either post it or you can send it via email – my email address is in the !readme file.

Thanks

Jim (especially, because he’s used the call) and anyone else:

Would it be better if USBAudio_EnumerateResolutions returned not just a list of resolutions, but a list of resolution and subframe size pairs?

Would it be better if USBAudio_EnumerateResolutions returned not just a list of resolutions, but a list of resolution and subframe size pairs?

Yes, that probably would be more convenient/logical. It confused me at first go that I had to use EnumerateSampleRates to get the frame sizes. I think the documentation should specify what these mean fairly simply as well. e.g. say “bytes per sample for the transfers via the buffer” and explain the distinction from “bytes/bits of actual audio”. However that’s something I can do when I write about this if it won’t fit comfortably into your API listing.

Also, in practice do any devices have a frame size that varies from one sample rate to another?

As an extension of the above, I’ve been wondering. Might it be sensible or feasible for a call to give the programmer some info on what buffer sizes / range would be advisible / best? Or is that simply too complex to make sense? Failing that I think documentation will end up giving advice along the lines of “use 0.1 to 0.25 secs worth”. However one thing I’ve not yet experimented with is if I should change the buffer size with the sample rate, or simply use the same buffer size for all rates.

Doing the latter is simpler to program. But means choosing a buffer big enough for, say, 192k even when playing 44.1k. The result being a much longer buffer ‘duration’ for 44.1k than 192k. Whereas the former means more work as you change the values, but would keep to a set duration per bufferload.

Jim

in practice do any devices have a frame size that varies from one sample rate to another?

I don’t think there is any way to know that.

I would like it to be possible; I cannot for the life of me understand why your DAC uses 4 bytes per sample when it only has 24 bit resolution. If the manufacturers really think that’s useful, I wish they would add a mode for 3 bytes per sample – obviously at the same 24 bit resolution.

I cannot for the life of me understand why your DAC uses 4 bytes per sample when it only has 24 bit resolution. If the manufacturers really think that’s useful, I wish they would add a mode for 3 bytes per sample – obviously at the same 24 bit resolution.

I’ll ask via a contact to see if I get a reply. However my guess is there are two reasons.

1) That they may think this makes it easier for programmers to manipulate values as 32bit ints before sending. Lets people use int/long (as relevant for the compiler, etc) rather than having a value type 3bytes long.

2) They have 32 bits per value in mind. Some of the more recent DACs are 32 bit (or more).

Not that it makes a lot of difference from my POV as to cope with 16/24/32 bits per file value, depending on the file, I have to fiddle with bytes anyway.

Jim

they may think this makes it easier for programmers to manipulate values as 32bit ints before sending.

If you have 24 bit values, bulking them out to 32 bits requires lots of processing – either as a batch before, or live, which is more work that just collecting and sending 24 bit values. It also increases the bandwidth requirement by a third – and the increase is entirely a waste.

If the bulking out process is done as a batch prior to sending the data, it increases the storage volume by a third. Again the increase is entirely a waste.

Dave, I’m not arguing against what you say. I was just speculating as to why they made the decision. :-)

I’d be much happier if the DACs did any reshuffling, and could simply be told. “here comes 2bytes per value” and “here comes 3bytes per value” so you could stream the LPCM file contents. But the makers have clearly thrown this problem over the wall to those of us trying to play using their DACs.

Its a bit like the way – as a power amp designer – I used to moan that speaker designers made speakers with input impedances whose phase angle and size went all over the shop. Making driving the speaker a real challenge at times. They just did it because it gave better performance without them having to bother with doing more to give an easier load to drive. Just threw the problem over the wall to amp designers. Shifted the cost from speaker to amp. So made their products easier and cheaper to make and sell.

Jim

I’m currently experimenting with things like buffer size choice, displaying elapsed time for a played file, etc. One possible extra swi might be useful. This is a USBAudio_Pause swi.

Behind that is a question: When playing I’d like to have a ‘pause’ button as well as ways to move forward or back to mimic the usual player controls. Am I correct to think that at present to ‘pause’ I’d have to stream zero values to the DAC? Of does simply sending nothing cause it to pause until a stream starts again, with no risk of problems? I’ve not tried this, but assume it depends on if the device/handling zeros values in the buffer once it has taken them or gets confused if the input of new values pauses. So would we need either the playing app to send zeros, or have the USBAudio module do it?

Jim

“Pause” is a real time function. USBAudio doesn’t do any real time stuff at all.

Not at the moment – and I’ve no idea how to do it anyway.

I can see we need Colin to chime in with ideas, because the buffer (thinking solely of replay now) will have some stuff in it, and that stuff might correspond to quite a long playing time, if the calling app asks for a large buffer. Presumably we wouldn’t want the stuff to continue to play out until the buffer has emptied, and only pause then.

All of which suggests some way of pausing the USB stack’s operation of taking stuff from the buffer and outputting it.

(Having said we’re talking solely of replay, there is a complementary problem on record, of course.)

All you can do is stop sending data to pause. USB will continue sending 0s. If the buffer is large there will be a delay before the pause happens – until the data runs out. If you are writing a proper player in a module you can fill the buffer for example every 1/100 sec in the background and keep the buffer short. You only need a large buffer when writing from a foreground app.

Fast forward rewind etc is for a player program to implement. Its the program which decides what it is putting in the buffer and from where in in the file.

I cannot for the life of me understand why your DAC uses 4 bytes per sample when it only has 24 bit resolution. If the manufacturers really think that’s useful, I wish they would add a mode for 3 bytes per sample – obviously at the same 24 bit resolution.

They do offer both – but not at the same time. In USB1 mode they have 3 bytes per subframe, in USB2 mode they have 4 bytes per subframe – in USB2 mode they are not concerned with bandwidth and they can upgrade their device to 32bit without needing a new interface.

The more I look at it the more I think that the bit resolution is the least important of the 2 values. You have a device with 20bit resolution I seem to remember but that has a 3byte subframe so the data is actually 24 bit but only 20 bits are significant. If we only match files to devices based on bit resolution your 20bit can’t be played natively but matching the subframe size it can – it will play on any 24 bit player.

Why would a manufacturer have interfaces with different bit resolutions in the same configuration when 1 bit resolution has no problems with any lower bit resolution – you are interfacing to a computer after all.

If the bulking out process is done as a batch prior to sending the data, it increases the storage volume by a third. Again the increase is entirely a waste.

No-one in their right mind would convert 24 bit files to 32bit files for playing on a device natively. Same goes for playing 16 bit files on a 24/32 bit device.

Colin now has a BeagleBoard system to use for development. Expect more successes over the coming weeks :-)

Thats what I like optimism – its a good way to start the year.

Anyway I’d like to thank you for lending me it. Nice box – shame all the ports on the beagleboard don’t face the same way.

Fast forward rewind etc is for a player program to implement. Its the program which decides what it is putting in the buffer and from where in in the file.

Agreed. However I wasn’t sure if I’d need to start streaming zeros to get a pause or if the system would simply take my temporarily ceasing to (re-)fill the buffer as leading to it/the DAC playing zeros. Or if something would get upset.

I can choose to have the player keep playing a bufferfull of zeros, but it’s clearly easier from my POV if I can send nothing. From what Colin says, I now take it I can just pause refilling the buffer and then resume again when the pause is ended. So far it seems that choosing a 0.1 sec buffer size for all rates works OK. Hence the delay in having an audible effect won’t be much of a problem.

Jim

If the buffer is too small moving windows or fetching pages in netsurf can cause problems.

If the buffer is too small moving windows or fetching pages in netsurf can cause problems.

Well, my own view is that you are either listening to music or doing something else. 8-] So what you describe can be taken as a hint to the user to make up their mind what they want to do. Sit up straight and pay attention! Music matters. ;-> ¹

TBH for my own interest/use I’d be more tempted to do a single-tasking player anyway. However I’m hoping that !GraphTask will produce something which is more useful as a demo for people. Either way, it’s letting me learn how things work.

That said, I’ve hit a puzzle on the !GraphTask side where graphics all come out white on black regardless of selected painting colour or ‘screen’ mode. I’m hoping Druck will explain what’s wrong on c.s.a.programmer so I can sort it out. FWIW All the !GraphDraw demos are in BASIC. So far as I know, I’m using the same calls in ‘C’ via OS_Plot, vdu, etc, but the colours get ignored.

Jim

¹ However, more rationally: I did experiment with larger buffer sizes, but I’m still not sure how big is OK as I want to have a ‘set duration’ for all rates, etc. – i.e. not a fixed buffer size in bytes, but a buffer 0.1 sec long whatever the sample rate or byte depths. So the buffers can get a bit big with 192k 24/32bit. How big is OK? FWIW I find a buffer duration in tenths of a second convenient for keeping track of the played duration. Other simple values like 0.2 would be OK with me, but as I say, what I’m doing is really just for learning/demo purposes at present.

Would it be better if USBAudio_EnumerateResolutions returned not just a list of resolutions, but a list of resolution and subframe size pairs?

Yes, that probably would be more convenient/logical.

Consider it done. The API is revised accordingly. If you use UAPlayer, you’ll need to update that too because it uses EnumerateResolutions. Anyway, you’ll find the USBAudio module and UAPlayer in the same archive at http://davehigton.me.uk/Audio next to the API document.

Lest I should mislead anybody, I’d better include something here that I forgot. EnumerateResolutions doesn’t return pairs of values, it returns triplets of direction/resolution/subframe size.