How to do USB audio

Will this pave the way for a version of Christian Ludlam’s !AudioIn app and driver that interfaces with USB audio?

Yes, but let’s not get our hopes up too much about the timescale. I have the source, and at some stage I would very much like to have a go.

There are some other mundane matters to be sorted out in order to get it working, such as reading the descriptors of audio devices such that the correct interfaces, endpoints and alternates can be found automatically, and the properties listed. You need this to set the sample rate, for example. It’s not difficult in principle, but there’s a significant amount of handle cranking to be done.

For good measure, ISOOut.wav is a recording made with the same Plantronics headset and a cheap “7.1 Channel Sound” USB audio interface. I had to set the microphone feature unit’s gain up by 20 dB to get that, which I still think isn’t enough gain, but is on the interface’s top limit.

I thought it was sad to spend Saturday night bashing the keyboard, but bashing the keyboard and talking to the computer takes it to a new level :-)

I haven’t seen !AudioIn but looking at the endpoints for audio devices I’d like to see an interface which presents a variable list of sliders for each device one for each feature (volume,tone, equalizer etc) that the device supports and do these things on the device rather than in software.

Regarding your mic dave I notice the different alternate interfaces are effectively a bandwidth feature ie you can select a lower bandwidth (maxpacket size) which has the side effect of limiting the frequencies available. I think rather than selecting the highest bandwidth endpoint for all frequencies you could use the frequency list from the highest bandwidth to present to the user and if a low frequency is selected a lowest bandwidth alternate interface supporting the frequency can be chosen. I wonder if alternate interfaces are just used to select bandwidth generally any thoughts? EDIT: I’ve just written a load of rubbish its more complicated than that.

I’ve now had an email back from Andrew wrt the ARMiniX. He is – as usual – busy, so has only had time to quickly scan this thread earlier this morning.

I’ll summarise what he wrote to me in case it helps clarify how/if this can work safely on an ARMiniX.

On an ARMiniX only the card reader is ‘scsifs’ (i.e. USB filing system IIUC). The rest is SDFS which isn’t USB-connected. Although networking is USB connected so might be affected by any USB resets, etc.

ARMiniX shares its usb support with Beagle and Pi. mUSBdriver hasn’t been implimented because the PandaBoard has internal USB pins on its main USB bus that are used for the internet connection.

EHCIdriver is the USB 2 for Iyonix, Pi, Beagle and Panda.

OHCIdriver was the USB 1.1 driver and is essentially obsolete so far as Andrew knows.

Hope this helps. I assume the point is that the main HD – even though an SD card – isn’t accessed by USB (SCSIfs) but via an onboard SDFS (equivalent to ADFS). Hence shouldn’t be affected by USB ‘changes on the fly’ whilst the machine is running. Does that make sense?

Jim

Re !AudioIn look-alikes…

Yes, but let’s not get our hopes up too much about the timescale. I have the source, and at some stage I would very much like to have a go.

One hesitation I have at present is that we should also bear in mind how this would fit into the ROSS in a sensible way. As distinct from being a totally seperate ‘bolt on’.

Having it work by almost any means would be very welcome. But ideally if we can use audio in and out via USB it would be nice if it then could be linked into SoundControl, SharedSound, etc.

At present this probably matters less for ‘recording/input’ USB devices than for ‘playback/output’ ones, though.

However at present players like PlayIt, DiskSample, etc, assume hardware that connects via the ‘internal’ routes. So the general question would arise, how to allow the user to change the input and output devices to cover removables. As yet the ROSS doesn’t even consider this being possible!

Regardless, I’d much rather see USB inputs and outputs working via whatever initial method worked, even if it means special purpose software initially.

FWIW I’ve been doing some parallel hacking WRT using DigitalRender to bypass much of the ROSS and let me experiment with ‘better’ resampled output to play audio with better quality than the ROSS currently allows. (When the progs are in a fit enough state I’ll make them public so others can play with them and see what I mean.)

Jim

I thought it was sad to spend Saturday night bashing the keyboard,

Ahem.

Hands up who spent Saturday night bashing on a keyboard.

Jim this file USBReinit.zip will show if the softload will work. It rmkills all the usb modules then rmreinits them all – so doesn’t load anything new. Running the file will start printing a module list, then pause, then should just continue as before when the usb modules get reinited.

The only possible problem I see is that the internet ‘may’ not work after running the file. It may require an *rmreinit internet.

If you run it from the ram disk it shouldn’t have any problems.

You can read what the file does in a text editor.

Jim. I don’t know anything about the ROSS or any of its clients I’m only interested in getting USB working. If I get it working the USB interface for other programmers will be similar to loading a wav file a chunk at a time and saving it to another file. If you look at the BASIC file included in USBModule.zip audio out will work the same way. Ideal, I would have thought, for you Jim you’d be able to transfer a wav file directly to the device bypassing all system software in basic – assuming the format matches as the device won’t do any conversions.

Obviously the interface can be used to create a backend for the current system but I fear that the current system would only support a subset of the usb device’s capabilities. Personaly I’d write a new interface (more futureproof?) for USB devices and adapt the machine sound devices to that.

Jim this file USBReinit.zip will show if the softload will work. It rmkills all the usb modules then rmreinits them all – so doesn’t load anything new. Running the file will start printing a module list, then pause, then should just continue as before when the usb modules get reinited.

Seems fine. :-)

I tried it in a taskwindow. It started listing the modules then stopped at the ‘Univ’ of UniversalKey (module number 131 on the list). I started thinking the machine had frozen and would need a restart. But as I wondering if I should do a power cycle the listing suddenly continued and completed.

I could then save the results to a file.

And I could then use NetSurf to access this page and write this message OK.

Jim

Jim. I don’t know anything about the ROSS or any of its clients I’m only interested in getting USB working.

I am ambivalent/conflicted about this. :-)

On one hand, yes, I’d prefer USB audio to be handled by the most direct ‘pass the parcel’ route possible. And would also like to see us being able to use USB audio input and output devices as soon as practical. So if the job can be done, and is easier by simply having dedicated code, I’d welcome the results! Hence I do want to encourage and enthuse anyone having a go at this.

OTOH in the longer term I think we will need somehow to integrate this with the existing design of the ROSS. But I think this is a longer term “WIBLI” as it would be termed on the TechWriter email list.

WIBLI = Wouldn’t It Be Lovely If…

The long term problem is people being able to use the same software for both USB and internally supported sound hardware. Ideally by having some user choices via !Boot or some RO equivalent to ALSA (Linux).

All that said, I’ve tried to raise this and those capable of integrating such things into the ROSS are clearly busy with other tasks and – so far as I can tell – regard these areas as a low priority.

Which brings me back to the initial simple point. I’d much prefer to have such things sooner rather than later/never and by a simple direct route that would minimise interference by other aspects of the system.

So at present I’d be happy to shelve long-term worries about ROSS integration, etc. If it works, I’m interested in using it. And if it works and others use it, then maybe that will encourage those working on RO to push including this in the ROSS up their ‘to do list’ later on. :-)

In the end I prefer working in practice to waiting and hopeing for an ideal that may not come until I’ve lost my hearing or popped my clogs anyway!

So go for it, by whatever means seem most practical. Damn the torpedoes. :-)

Jim

I thought it was sad to spend Saturday night bashing the keyboard

If you don’t spend Saturday night bashing the keyboard, I think there must be something wrong with you :-)

And Sunday. And Monday. And Tuesday. And Wednesday. And Thursday. And Friday.

I understand that some people watch television on Saturday evening.

What I don’t understand is why they do it.

USBRmreinit Seems fine

In that case !USBModule in USBModule.zip will load in the same way. It just loads the new module instead of rmreiniting the old. So its just a matter of someone being brave enough to try it.

As I said my concern is messing a hard disc up – not the isochronous change. I don’t have a problem with memory sticks and card readers on my Iyonix which use the same system as hard discs on a ARMiniX (SCSISoftUSB). Dave’s tried it on his Iyonix. Rick’s tried it on a Pi and there hasn’t been a problem but its not much testing. I don’t envisage a problem but I’m paranoid enough to expect theory and practice to differ. As I only have my Iyonix I can’t test on other machines.

The other untested module is EtherUSB but the remote possibility of a problem with that at least doesn’t have any nasty side effects.

I’d be inclined to unplug the hard disc and replace it with a spare memory stick or card reader and card then run !USBModule from a ram disc like you run USBrmreinit and see if there are any problems accessing the disc.

I’d be inclined to unplug the hard disc and replace it with a spare memory stick or card reader and card then run !USBModule from a ram disc like you run USBrmreinit and see if there are any problems accessing the disc.

Not sure if I’m clear on the above. IIUC Andrew correctly the main ‘HD’ in the ARMiniX isn’t a USB connected-device. So presumably, can’t be upset by !USBModule?

If necessary I do have a ‘spare’ SD card for the ARMiniX that I’ve used to test an experimental version of the OS/HAL that Willi sent me some time ago. So I could use that for a test run if it is thought best. But from the above I’m not clear if it will be needed.

And I think that, first, I’d better get a USB audio input device. Otherwise I have no way at present to go beyond the first step. Does it seem reasonably to expect that a cheap generic USB audio input device is likely to be suitable? And may well work with Linux anyway? I’ll look at the CPC catalogue to see what they have on offer.

Jim

Your *usbdevices showed

11 1 11 0/ 0 Sunplus Innovation Technology. USB to Serial-ATA bridge

isn’t that your hard disc? or is it something else you have plugged in.

Your *usbdevices showed
11 1 11 0/ 0 Sunplus Innovation Technology. USB to Serial-ATA bridge
isn’t that your hard disc? or is it something else you have plugged in.

Pass. I’ll have to ask Andrew.

Jim

Does it seem reasonably to expect that a cheap generic USB audio input device is likely to be suitable?

The “7.1 Channel Sound” thing I have was very cheap on eBay. It’s not great, nor is it very versatile, but it’s sufficiently functional for experiments.

The iMic looks like a better quality animal, and it’s certainly more versatile, but it’s far more expensive (though still not too bad). I was surprised to see that they are still available, bearing in mind how long I’ve had mine; albeit a version you buy now looks different from mine.

I’d be interested to know what devices you consider.

Does it seem reasonably to expect that a cheap generic USB audio input device is likely to be suitable?

The “7.1 Channel Sound” thing I have was very cheap on eBay. It’s not great, nor is it very versatile, but it’s sufficiently functional for experiments.

The iMic looks like a better quality animal, and it’s certainly more versatile, but it’s far more expensive (though still not too bad). I was surprised to see that they are still available, bearing in mind how long I’ve had mine; albeit a version you buy now looks different from mine.

I’d be interested to know what devices you consider.

I’ve put up some descriptor stuff on my web site.

Desc7_1.txt is the textification of the USB descriptors of the 7.1 thing I keep mentioning.

BlkDiag7_1.png is a conversion of a Draw file I drew earlier today which, I think, gives a block diagram of its functional blocks. (The missing “I” in the microphone Input terminal seems to be caused by the conversion in Spr2Png; it’s there in the original DrawFile.)

DecodeDesc.zip is the application that decoded the descriptors. Note that it is far from complete. Since the source is there, anyone can develop it or use the information within it.

I’m pretty certain that the ARMiniX has the same drive arrangement as our PandaRO and any other Dual partition SD card PandaBoard system ¹.
On Dual partition systems the Boot drive is the filecore partition on the SD card using SDFS.
Other drives such as SSD, 2.5" rotating and CD/DVD ROM drives will be connected to USB either directly or via USB to Serial-ATA bridge.

¹ All Raspberry Pi’s are Dual partition SD card systems. Pandora & BeagleBoard systems can be Dual partition SD card systems but most aren’t, if not the ‘Boot’ Drive will be a USB connected drive.

n.b. On all PandaBoard, Pandora, Raspberry Pi & BeagleBoard systems a RISC OS ROM image is loaded from a FAT formatted SD card and then $.!Boot is is run on the ‘Boot’ drive.

Your *usbdevices showed

11 1 11 0/ 0 Sunplus Innovation Technology. USB to Serial-ATA bridge

isn’t that your hard disc? or is it something else you have plugged in.

Here that’s integral to my hard disc, a Western Digital 2.5 in a Core box. BB -xm.

I asked Andrew about the relevant line in my *usbdevices report. His reply is that he thinks this is for an additional SSD or the CD drive. So in my ARMiniX is probably the CD drive connection. The CD drive (actually a DVD writer) is ATA and is fed via USB adaptor.

Jim

I’m wondering how to go about adding USB audio devices to RISC OS.

It seems to me that we need a USBAudio relocatable module, which would provide facilities to enumerate USB audio devices, enumerate their interfaces (in terms of a general audio device, not to be confused with the USB meaning of interface), enumerate what properties are controllable, show what the minimum/maximum/current values are, and allow them to be set. Then presumably it could offer facilities to open and close streams to/from them.

Any better suggestions?

Any suggestions as to what existing API we should copy from?

One interesting challenge: if you look at the block diagram you will see that, although there is one input interface and one output interface, there are three controllable paths, not just two. The third one is properly referred to as “sidetone” and is the level of microphone signal heard directly in the loudspeakers/headphones. That path has to be identified, enumerated and controlled too.

It seems to me that we need a USBAudio relocatable module,…

I’d agree. From the ROSS side it would be useful if this could adopt behaviours similar to SharedSound or SoundDMA wrt how the audio streams are handled. It would make writing user-level programs easier, and ease modifying existing ones.

That said, I do have a liking for *nix “everything is a file” approach and having a quasi-filer interface. That way you can “write to a file” to output audio or write to some other “file” to make hardware settings, ditto for reading. This is akin to the !AudioIn approach and the DRender: “filing system” that DigitalRender offers. To me this approach seems much clearer from the programmer’s POV, and will be more familiar than SWIs to someone used to Linux.

FWIW I still haven’t sussed how to use the SoundDMA 16bit interface to play audio. But found SharedSound and DigitalRender pretty clear. And getting DR to play audio using DRs ‘file’ method was easy.

Personally, I find the ‘file’ approach to be good. But I suppose this is a matter of taste. But it means you can do things on the basis that ‘files’ appear in the ‘USBaudio:’ filing system when a USB audio hardware item is connected. There can then be some conventions to give names that show if it is an input or output or something that can be ‘read’ or ‘written to’ for finding or making settings of the device.

That also seems akin to the camera interface.

Jim