How to do USB audio

/* toggle state needed for bulk endpoints */
epipe→nexttoggle = pipe→endpoint→datatoggle;

It was added to both EHCI and OHCI 2 yrs 4 months ago the cvs log says.

remember the data toggle bit per (bulk) endpoint rather than per
pipe, as required by the spec
This helps in cases where pipes are opened/closed without reconfiguring
the device in between, eg with the ugen driver.
only for UHCI/EHCI, don’t have an OHCI to test

Looks like things need updating.

Colin: I take it you have some USB audio devices?

Just one of those cheapo headphone adapters ie stereo out socket and mono in socket, and a webcam.

Have you been looking into achieving something like this?

handle = Audio_openPCM("USB8",44100,2,4,16);

ie opening an endpoint based on audio format – failing if the device could’t set the format.

Its just that in writing a module to test the USB library I’ve added to USBDriver it dawns on me that that is all we need along with the associated function to write to the device.

actualsize = Audio_write(handle,buffer,size);

The question I do have though is, is “USB8” enough to identify a unique audio stream. ie is it likely that a device has more than 1 output ‘speaker’ interface in which case using the device id as an identifier to open an endpoint is not good enough.

I tend to think play safe and have the audio module enumerate ‘speaker’ destinations and the user can pick the one they want to open from a list generated by the audio module.

thoughts?

Have you been looking into achieving something like this?

handle = Audio_openPCM("USB8",44100,2,4,16);

Pretty much, yes. I only need to combine the code I have with an open operation to get that. Don’t forget the direction, though.

The question I do have though is, is “USB8” enough to identify a unique audio stream. ie is it likely that a device has more than 1 output ‘speaker’ interface in which case using the device id as an identifier to open an endpoint is not good enough.

I don’t have a watertight answer here, and I don’t know how to give one unless I look at all the USB audio devices in existence. However, I have a fairly complicated one (supposedly 8 channels analogue output, plus TOSLink in and out – still less than £10 from a UK supplier on eBay), and, IIRC, it really only gives you one interface to throw data at or get data from. Controlling the paths may be another matter.

The open call needs to return several parameters – interface, endpoint, alternate, feature unit ID etc. – that will be required by other USBAudio calls, e.g. to change volume, mute or unmute.

The above features will probably be good enough for a first release of USBAudio. After that, it will be a case of reacting to feedback from users.

Looking ahead, it will be interesting to see how audio over Bluetooth can be brought into USBAudio – if at all. Currently USBAudio only enumerates devices conforming to the Audio Streaming and Control device classes. Bluetooth dongles seem to expose isochronous endpoints, but so far I’ve only seen these endpoints as Bluetooth. I haven’t got as far as looking what happens when you pair a dongle with an audio device and exchange audio.

And another thing – the user base is likely to be severely restricted unless and until we can get support for full speed devices through hubs. The only USB audio devices I’ve yet heard of that operate at high speed have much higher price tags than full speed ones. Those price tags will deter most of our users here, I believe.

The open call needs to return several parameters – interface, endpoint, alternate, feature unit ID etc. – that will be required by other USBAudio calls, e.g. to change volume, mute or unmute.

Thats all done in the USB Audio module

handle = USBAudio_open("usb8",441000,2,4,16);
USBAudio_setVolume(handle,channel,50%);
vol = USBAudio_getVolume(handle,channel);
USBAudio_setMute(handle,on);
mute = USBAudio_getMute(handle);
etc.

no need for USB to be known about.

Re Bluetooth.

I think the thing to do is virtualise the Audio interface into a separate module so that all modules can register an implementation of that interface. So an Generic Audio module uses a Audio_MiscOp swi with the following reason codes

Audio_open
Audio_close
Audio_write
Audio_read
Audio_setVolume
Audio_getVolume
Audio_setMute
Audio_getMute
etc.

So bluetooth would implement the swi

BluetoothAudio_MiscOp

with the same reason codes and register the device with the generic Audio module along with the BluetoothAudio_MiscOp SWI. If it can play and record it registers twice, once for each direction, then Audio_open can ignore direction – it’s implicit in the device ID. You also end up with a list of ‘speakers’ and a list of ‘microphones’

The Application programmer only uses the generic Audio module API which lists devices giving device ID’s

Doing it this way also means that Audio on the motherboard or any source you can think of can be made into a module and plugged into the generic audio module.

And another thing – the user base is likely to be severely restricted unless and until we can get support for full speed devices through hubs.

Yes but I think given scant resources getting audio working seamlessly on an Iyonix is the first step. Then you know everything works and so can be made to work on other machines by fixing the controller driver.

Yes but I think given scant resources getting audio working seamlessly on an Iyonix is the first step. Then you know everything works and so can be made to work on other machines by fixing the controller driver.

Can’t recall if I’ve already said this, but in case it helps at some point: I do still have a working Iyonix as well as my ARMiniX. That said, I;m quite happy to leave it to the two of you to sort out the Iyonix step(s). But I could then test on my Iyo using some of the DACs I have here.

Jim

Jim: does your Iyonix have at least RISC OS 5.20 (which needs a new !Boot)?

Jim: does your Iyonix have at least RISC OS 5.20 (which needs a new !Boot)?

No. I updated it a few months before I switched to using my ARMiniX. But to a version < 5.20. I’m a bit reluctant to upgrade it at present in case something else ‘breaks’ (I lost the ability to use RiScript which was a PITA at the time.) Could I not softload some relevant modules instead to do any tests?

FWIW I keep the Iyonix for a few special tasks. One today is an example. I’ve been transferring recordings I made over a decade or so to files. Most are OK being ripped with my Linux boxes. However some won’t read reliably on their modern DVD optical drives. Whereas the Iyonix has a genuine CDROM drive that reads such discs fine, albeit more slowly. Two discs today ‘stalled’ when I used cdparanoia with the -z option on two Linux boxes. But read fine with cdparanoia on my Iyonix.

Jim

You should be able to softload 5.20 and leave the physical ROMS at 5.16 or 5.18. Then if you remove the softload, all will be back to where you are now.

But to update the ROM to v5.20 (even as a softload) I thought you also need the HardDisc image v5.20? Once that is installed and working, it will also work with a physical v5.18 (and presumably earlier as well). Indeed, it is recommended to install the disc v5.20 before changing the ROM.

True. It is a pity there isn’t a painless way to do the hard disc upgade.

It is a pity there isn’t a painless way to do the hard disc upgade.

From my experience, I would describe it as laborious and time-consuming, but not really painful.

But to update the ROM to v5.20 (even as a softload) I thought you also need the HardDisc image v5.20?

For my Iyonix I think I’ll leave upgrading for now. My current !Boot on it has a lot of handwritten tweaks, etc. So I suspect it would take some time to sort out properly. However I’ll do it at some future point if it will be very useful for testing the USB audio. And if simply softloading some modules would do the trick, I’d be happy to give it a go.

FWIW I now only use it for a few special purposes, so don’t mind the risks/time but reluctant at present. Partly because I’m using it some of the time at the moment. However this may well have changed by a few weeks from now and I’ll then have a go at upgrading it.

Jim

For my Iyonix I think I’ll leave upgrading for now.

There’s no need to upgrade I can include the DeviceFS upgrade needed on an Iyonix.

I’ll try and add Asynchronous support today and you can try it out.

There’s no need to upgrade I can include the DeviceFS upgrade needed on an Iyonix.
I’ll try and add Asynchronous support today and you can try it out.

Sounds good. [With apologies for the pun!] :-)

Will that be ‘Class 1’ ?

Jim

Will that be ‘Class 1’

yes.

OK.

That should make it easy-peasy to test as all the DACs I’m using are set to Class 1. :-))

Given it works, would it be useful for me to try more than one DAC? Given time I can probably try two or more.

Jim

Given it works, would it be useful for me to try more than one DAC?

Of course. Why wouldn’t you?

Of course. Why wouldn’t you?

Time. :-)

Given it works I’ll also be wanting to do things like record the output from a USB DAC (both analogue and digital) to check the timing regularity and if the samples are indentical to the input. That can take a while.

I’ll use one DAC for initial tests of the “Can I hear music?” type. If that works I’ll try some others and report. Then use one to do more detailed tests on actual performance.

If this goes OK, the next question that will be burning in my thoughts will be how soon it can be got working on the ARMiniX, etc. ;→ But if this works OK, then I’ll be happy to say the ‘Prize’ is due. :-)

Jim

Time. :-)

Hope you’ve got plenty of it. I can’t test the added code here so testing it over the internet could be sloooowwwww – then again it might work first time :-)

Anyway I’m just trying to knock up a test program for you to try. It won’t do any conversions to the audio data so do you have any wav files in the native format of the DACs you have ie 24bit LPCM

With wav files I can read the Audio format from the file so you will only need to change the file name in the test program to get it to play.

Which DAC are you likely to try first – I can then make sure the test program can detect it.

Anyway I’m just trying to knock up a test program for you to try. It won’t do any conversions to the audio data so do you have any wav files in the native format of the DACs you have ie 24bit LPCM

Yes. I have a range of LPCM wave files. 16bit or 24bit at all the standard rates. I can also generate and convert them for test purposes. So if your test prog needs to have 24bit wave files I can easily generate 24bit versions of 16bit source files on the fly or beforehand.¹ All with the common 44-byte header.

I am currently thinking I’d start with the Arcam rDAC. But this could be the DAC Magic Plus if you think that more convenient. I also have the Halide Bridge and the ‘original’ DAC Magic model available. I think I’ve already provided USB details of all these. But if you don’t have them, please let me know.

If your software only sends out the ‘native’ format (24bit) then once it works and I understand it I can write a convertor for it to handle a range of formats if necessary.

Jim

¹ Not sure if you already do this. But if not I’ll point out the excellent ‘sox’ program has been ported to RO. That will do such conversions easily.

Ok try this USBModule.zip

There’s no need to unzip it if you are using SparkFS. It should work with Halide SPIDF bridge,Cambridge Audio and ARCAM DAC.

Before doing anything I’d have the volume low on your device if you can control it. Don’t use headphones fully over the ear until you are happy that no pops and crackles are occuring – Running !USBModule causes loud crackles on my device while the modules are changed. This is the debug version of the module so I can get debug info from it if necessary.

The first thing to do is run !usbmodule. A task window will pop up listing the modules. It will pause and a few seconds later continue as the new modules initialise. This need only be done once – it doesn’t change anything permanently on your machine. This will change the DeviceFS module, USBDriver module and add DaDebug module. It’s best not to be using a USB disk when you do this.

Now you are ready to go.

Change infile$ at the beginning of the BASIC progamme IsocPlayer to point to a wav file you want to play.

Run IsocPlayerRun – a task window appears

If the wav format is understood you should see the word ‘started’ and should hear the music at the end of the file you see ‘finished’.

You can abort playing by pressing escape – closing the window leaves files open.

There should be no crackles/distortion while playing.

Pressing f12 or heavy multitasking will cause playback problems – buffer doesn’t get filled in time.

The asynchronous part is untested so may cause crackles if its not working – you should hear something.

Think thats it.

I’ve updated my draft USBAudio API discussion document at http://davehigton.me.uk/Audio/USBAudioAPI.htm

It’s still very incomplete. Don’t bother looking at GetConfigurationDescriptor, because, like the comment says, you aren’t likely to need it. (I documented it because it was one of the stages in development that I needed.)

Comments welcome.

Assuming I can find the time and inclination to work on the documentation rather than the code over the next few days, I will update it some more with calls like SetVolume, SetMute, etc. – the calls are working, but it’s my determination to document them rather than continue with the module’s development that’s lacking :-(

One other thing: I have used “device name” to refer to more than one thing. When I mean something like “USB8”, I’m using the same phrase as in Castle’s “USB API” document. The other meaning is what comes back as a string descriptor, which is probably technically correct but only of any meaning to those versed in USB. The whole point of the USBAudio module being to insulate application writers from having to learn all that, of course. So suggestions for alternative names are welcome.

For USBAudio_Open I think R1 should just be a format block ie the direction shouldn’t be in it. So you have something like

Audio_OpenOut
Entry
    R0 = Pointer to buffer with null-terminated USB device name, e.g. "USB8"
    R1 = pointer to audio format block
    
Exit
    R0 = file handle

The size of the audio format block is dependant on the audio format. That way the API would cope with non PCM streams

You could use the WAV file "fmt " tag block. That way it can be passed directly from a WAV file. Otherwise including the format type at the beginning of the block eg.

blk + 0 = PCM
blk + 4 = frequency
blk + 8 = channels
etc.

will determine the format of the block.

For USBAudio_Open I think R1 should just be a format block ie the direction shouldn’t be in it.

In that case you’d have to have a USBAudio_OpenOut and a USBAudio_OpenIn, which would be identical in every other respect. Is that really what you want?

It’s not even like OPENOUT and OPENIN – they behave differently because a file can already exist. For USBAudio_Open, the stream must be new.

I’ve just tried the USBModule package and player on my Iyonix. Alas, no coconut. :-/

I tried two files.

One is a 24bit 44.1k file I created with sox from a 16bit source, then ‘cleaned’ its header to the standard 44-byte format. This gives the error “Not PCM at line 113”. Which seems to be a misread of the header details. I’ll do some checking but I’, fairly sure the wave header is correct.

The other is a 300Hz test tone (again 24bit 44.1k rate) I created with !WAV_Gen. This gives a different error “Bad request at line 230”.

I tried both the rDAC and the Halide Bridge with the same results.

I can see each DAC show up with USBinfo. And the indicator LED on the rDAC turns green to show it has detected being ‘found’ by the computer when connected.

FWIW I then added a line to the player program just above 230 to have it print out usb$. This shows the correct number for the device in question.

Jim