How to do USB audio

No the Rpi uses a different controller so USB audio won’t work with it.

Jings! If that also applies to Linux it makes it useless for the kinds of things I once had in mind for it!

Jim

Its working on linux I think.

Re the USBmodules You may want at try and get Andrew to add the latest SCSISoftUSB and DeviceFS to your rom distribution then you won’t have the shutdown error. They have been in the ROMs for a while now.

Jim, I tried your USBAudioProbe on my Iyonix(and latest USBModule) but scan_for_devices is returning 0 devices.
And yes, my cheap CMedia is plugged in and lit up.

Regarding the RasPi, There are various projects around that connect high end DAC’s directly to the pins. While USB is of course useful, for optimum quality, removing the USB interface has a few advantages, and there may be gains by not further loading the heavily used USB/ethernet as well?

For day to day use, I’m sure USB audio would get used, there is no other audio in for example.

…just want to report that my quite old Turtle Beach Audio Advantage Micro (audio out only device, must be like 8 years old or something) works also without any problem with !UAPlayer and !IsocPlayer. According to the USB descriptor it is made by “C-Media INC.” and supports 2 channel / 48 KHz. If somebody wants me to run a test just tell me.

Thanks for trying it out Kuemmel. Can you tell my which computer you used?

Ronald.

In the case of a raspberry pi you may be right. It appears that the raspberry pi USB controller is very basic not really suited to a desktop environment due to its lack of buffering. The pi controller has to be serviced 8000 times a second without fail to feed isochronous data. By contrast the ehci controller the other devices use can cue isochronous data up to 1 second in advance. I’ve seen ehci interrupts be missed for 4 millisecs on an Iyonix but this doesn’t matter because the queued data will be sent on time whether the interrupts signaling completions occur on time or not. So the ehci controller smooths out the lumpyness caused by irregular interrupts caused by activity on other devices. The pi is only double buffered – ie only buffered 1 microframe ahead (compared to ehci which can be 8096 microframes) so there’s no great advantage over using i2c which also has next to no buffering except that if you can get USB working then video should work too.

The problem of getting a consistent 8000 interrupts per second is not really a problem for interrupt/bulk/control endpoints as they don’t work in a guaranteed time frame and can retry if necessary – though missed interrupt transfers may cause keyboard/mouseclick problems.

@Colin: I used a Pandaboard ES, latest Risc OS version.

Colin: I tried your new modules last night, successfully, on the BBxM and the Iyonix.

I can play 48000/16/2 on the BBxM from USB spinning rust without interruption – also over ShareFS from a file hosted on the Iyonix’s PATA spinning rust.

I think GetFeature is implemented, and SetFeature only needs a loop construct added. The some more documentation and I’ll make the next release of USBAudio available.

Jim: assuming your last published link is valid for your updated USB probe software, it didn’t work for me either. (I didn’t make time to investigate because I was working on the module.) It saw a single device, but didn’t get the manufacturer or name strings, and the rest of the data it got were nonsense.

Its working on linux I think.

In that case I’m not understanding what you meant by a “different controller”. Are your USB modules specific to a given bit of USB hardware being used as the controller? So a new set would be needed for different hardware?

Re the USBmodules You may want at try and get Andrew to add the latest SCSISoftUSB and DeviceFS to your rom distribution then you won’t have the shutdown error. They have been in the ROMs for a while now.

I’ll ask him about that.

Jim

Jim, I tried your USBAudioProbe on my Iyonix(and latest USBModule) but scan_for_devices is returning 0 devices. And yes, my cheap CMedia is plugged in and lit up.

Can you check the source code. Did you use the newer version (#defines given in hex) with Dave’s new module? Otherwise the swis may not match. If you did, can you use the software from Dave, etc, and tell me what details that gives of the device.

Also, what USB numbers are listed as found at the start of the report? You should see a string like “USB” where is the device number of a set of such comma separated. If no such string then the first swi call isn’t returning any audio devices. Look for the line that starts with

List of devices by ID =

That should be followed by a string of the USB numbers for audio devices. If that line is blank then USBAudio_EnumerateDevices didn’t find any.

One point to make is that I have not yet been able to write anything to deal with devices that return a ‘range’ of sample rates. I don’t have one to test against (yet). So I’m sure there will be devices my Probe and Player wouldn’t cope with. However I’d expect them to be detected and you should get a non zero count.

Regarding the RasPi, There are various projects around that connect high end DAC’s directly to the pins. While USB is of course useful, for optimum quality, removing the USB interface has a few advantages, and there may be gains by not further loading the heavily used USB/ethernet as well?

Can’t comment directly on the RPi and this obviously depends on the wishes of the user. However for me the main point of USB audio is it gives the user the choice to use a range of devices, and to shift that device from one machine to another. e.g. In my case I can now use my DAC Magic Plus (and other DACs) with my Iyonix, Linux Box, and ARMiniX via a USB switch and hub. Makes more sense if you want an expensive high quality DAC as you can use it even when changing main hardware.

For day to day use, I’m sure USB audio would get used, there is no other audio in for example.

Each person will do what suits them, of course. But from my POV having started to use USB for play or rec makes it logical to also use it for the reverse. That’s why I’m currently on the hunt for 96k/24 or 192k/24 ADCs I can use. 8-]

Jim

it didn’t work for me either. (I didn’t make time to investigate because I was working on the module.) It saw a single device, but didn’t get the manufacturer or name strings, and the rest of the data it got were nonsense.

Dave: Is the device one that returns a ‘range’ of sample rates? If so, I’ve not yet written code to detect and handle that. I don’t have a device to test it against. If your device is of that kind, I’ll try adding the code and ask you (and maybe Ron if that was his problem) to let me know if it then works.

Jim

The pi is only double buffered – ie only buffered 1 microframe ahead (compared to ehci which can be 8096 microframes) so there’s no great advantage over using i2c which also has next to no buffering except that if you can get USB working then video should work too.

“i2c” is that a typo? I thought sound interfaces on the Pi used “i2s”.
If not does i2s have the same buffering problems?
The GPU on the Pi can do a lot AIUI, I wonder if it could be used for sound and get round buffering etc problems. It might do but the documentation is probably not available:-(

Another point people may wish to check when Probing or using devices.

The UCA202 I have shows two behaviours that aren’t shared by my three other devices.

1) I have to plug it in after I’ve loaded Colin/Dave’s modules. If it is plugged in when I install the modules any attempt to query it returns rubbish. And any attempt to use it plays as silence. i.e. something may accept input from the buffer, but no coconut.

That means I have to either only plug it in after the modules are loaded, or unplug it and plug it in again. Do that, and it works. This leads to the next oddity.

2) It seems to always be returned as the ‘first’ device. Seems to really want this.

Jim

Its working on linux I think.
In that case I’m not understanding what you meant by a “different controller”.

I remember you once saying that the good thing about USB is that when porting RISC OS to a new computer you just have to get USB working to get a lot of devices to work. Well to get USB to work you have to write a USB controller driver for the USB hardware on the computer. ehci and ohci controllers are fairly common so with little effort the existing ones can be made to work on other devices. The pi controller is totally different. It resembles something you’d get on an embedded microprocessor for use in device mode.

I have made changes to the part of the USB stack that is common to all computers as well as the computer specific areas (ohci and ehci) to get everything working.

Dave: Is the device one that returns a ‘range’ of sample rates?

Yes, however I don’t understand why your code would fail to see the two identifier strings. There is no connection between the SWI to return the strings and the SWIs to return the sample rates etc.

I have to plug it in after I’ve loaded Colin/Dave’s modules. If it is plugged in when I install the modules any attempt to query it returns rubbish.

I cannot understand why that should happen.

Chris.

“i2c” is that a typo?

It was a guess. Ronald said they were connecting to the pins and I assumed they were using some interface on the io pins. I haven’t had a detailed look – and it takes a while for details to sink in :-). If the audio connection they use requires accurate timing then its always a problem without hardware buffers to keep the device fed while the computer is doing something else.

Documentation is a real problem. Ehci has a large specification document – mind numbing but at least it gives you a chance.

Dave: Can you tell me the name, etc, of the device you’re using? Or alternatively can you or someone say the name of a cheap one that does this? I’ll see if I can get one to experiment with.

I have no idea either why the UCA202 behaves as it does. But it seems to be very fussy about how it sets itself up as part of the USB system.

Jim

Just to let people know I’ve now put up a tweaked version of my demo player at

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

Here it plays OK using the UCA202, DAC Magic Plus, rDAC, and Halide bridge. But I’m sure it won’t work with all DACs and files! If you give it a try please read the supplied !Help file first. As supplied it plays single-tasking. But it should also work using a TaskWindow or !GraphTask.

Jim

Jim.

I have to plug it in after I’ve loaded Colin/Dave’s modules. If it is plugged in when I install the modules any attempt to query it returns rubbish.

What does *usbdevices show after running my modules. Is your device listed there? Does it start working after *usbreset 8 where 8 is the number of your device listed by *usbdevices

It seems to always be returned as the ‘first’ device.

where is it listed by *usbdevices?

Dave: Can you tell me the name, etc, of the device you’re using?

Yes; it’s a Griffin iMic – but this may not help you very much, as it is some years old, visibly different from the model that’s on sale these days. Also Griffin say that the iMic is “specification independent”, which is a way of saying that what one person buys may be very different from what someone else buys on the same day. They make them with whatever is currently cheap and available. All of which means that, if you were to get hold of an iMic, it may well not give you the same results as I’m getting.

I also have access to a Logitech headset that supports a continuous range of sample rates. I haven’t tried it yet. This is also a problem in that it, too, appears not to be a current model.

Dave I was looking through your API again and have a comment. You’ve implemented these two SWIs as requested

USBAudio_NameToVIDPID
USBAudio_VIDPIDToName

but they don’t to what I intended. I don’t want a list returned. The purpose of the call is to uniquely identify the device or fail. I know that this is impossible without the device having a device ID but we need some identifier which will convert back to a USB Device when the machine is switched back on or reset.

As you show VID/PID are not enough lets face it you can have 2 identical devices plugged in and reading the device descriptors is not going to help. So the best I can come up with is this.

_swix(USBAudio_DeviceToID,_IN(0),_OUT(1),&device,&id);
_swix(USBAudio_IDToDevice,_IN(0),_OUT(1),&id, &device);

Note I’ve used ‘Device’ where you use ‘Name’ because you use ‘Device’ to mean ‘USBnn’ in USBAudio_EnumerateDevices whereas ‘Name’ is used elsewhere to mean he human readable name of the device.

&device is the address of the device eg ‘USB8’ &id is the pointer to a 28 byte block which is the device ID. The &id is a text string of hex numbers like ‘002b400230200010203040506’ it has the following format:

• chars 0 ID type – this allows you to change the format of the string in future if required.
• chars 1-4 vendor
• chars 5-8 product
• chars 9-12 device version
• chars 13-24 location of the device on the bus (6 two char values)

USBAudio_DeviceToID creates the ID that you can save.

USBAudio_IDToDevice returns an Device from the stored ID or fails if not found.

It does this by searching in this order:

1. check for a device at the location in the ID and if the vendor/product/version match return the device. else
2. ignore the location and just match the device/product/version. If there is only one match return the device. else
3. fail

The idea is a music program selects a device to use and doesn’t have to keep asking every time you switch on for a device – it would only ask if USBAudio_IDToDevice failed.

The above scheme isn’t perfect – without a device id it can’t be – but it would work with identical devices attached and survive a reset. It would fail if you swapped sockets of identical devices. If you don’t have identical devices it will survive plugging into a different socket.

Any thoughts?

NameToVIDPID returns a unique VID/PID pair.

VIDPID cannot guarantee to do so, hence the list.

I don’t see how your scheme helps any more than mine. If you unplug a device from one place and plug it in a different socket, the ID will be different. The device version is very likely NOT to be unique.

But if I’ve misunderstood, or there’s a better idea, I will happily accept it.

Some results on the odd UCA202 behaviour. Did two tests.

Test 1:

Powered up the system with my DMPlus connected. usbdevices told me it was device 12. Loaded the audio modules. Still 12.

Plugged in UCA202. usbdevices shows this as device 15. DMPlus still 12.
At this point I switched off the DMPlus. Used my player. And the UCA202 happily played the audio. Probe gave its correct details.

Switched everything off. No power.

Test 2:
Plugged in the UCA202 leaving the DMplus unpowered. Powered up. The UCA202 showed by usbdevices as device 5. Installed the modules as for test 1. Still shows as device five, but now the Probe gives rubbish and the device won’t play.

Did a usbreset 5. Now the UCA202 will play and Probe gives the correct details.

I’m not sure which details make what difference, but it seems like it wants a reset – perhaps provided by being unplugged and plugged in again – in some circumstances but not others. Might be it safe and sensible if programs that play/probe/record send a reset before they get started as a general rule? or would that upset some other devices?

Jim