How to do USB audio

Jim, without loading the new USB modules
I get the following even if I do use reset on the device from USBInfo

Type in sample rate => 48000 number of channels => 2 bits per sample => 16 OK, scan looking for ability to play: rate = 48000 channels = 2 bits/sample = 16 Using USBAudio_EnumerateDevices to find out what is connected List of devices by ID = No devices found! Devices counted = 0

I’m not giving this much time at the moment, and it is probably something that can be sorted out later if your stuff is working.

Rick,
Thanks for your in depth review.
I noticed that the vga convertor that you linked to has a different case and audio socket position, but they are probably equivalent. Also I noticed one on Ebay that uses the larger HDMI plug suitable for RasPi.
Your review sounds favourable, and a great added bonus for having to run it to use a VGA monitor. My particular 1360×768 LED monitor is poor with the RasPi so I would probably get an improvement using VGA. The very low power useage of the small LED monitor is hard to beat so I could perhaps use an old mechanical VGA switchbox to allow both Iyonix and RasPi to use the one analog input.

Edit: From the wiki, introduced with HDMI 1.4 the ability for a TV to send digital audio ‘upstream’ (probably a surround amp) via HDMI interconnect. Something to check for when buying a TV.

I get the following even if I do use reset on the device from USBInfo

That tells me that the USBAudio_EnumerateDevices swi call is finding no audio devices. Either the device isn’t reporting itself or you aren’t using the version of Dave+Colin’s modules that match the swi numbers.

That in turn means that my programs won’t be able to know what USB number the device may have, so can’t work or get any other info. My progams can’t work without Dave/Colin’s modules as they just make calls to Dave’s USBAudio module.

So to see if any of my programs work, you need to have Dave and Colins’ modules loaded. Then report the details of what my probe gives if the player doesn’t work.

If Colin or Dave’s players work, the mistmatch is almost certainly a matter of the swi numbers. If the version of my prog you’re using has the swi numbers defined in hex, its the latest version of Dave’s module you require.

Otherwise, you’ll need to find out details of the USB Audio device you have by using !USBDescriptors, !USBinfo, etc.

Jim

or you aren’t using the version of Dave+Colin’s modules that match the swi numbers

The EnumerateDevices SWI’s number didn’t change.

The EnumerateDevices SWI’s number didn’t change.

In that case the problem seems to be either that the module(s) aren’t loaded or the device doesn’t respond. However with luck Ron will give more specific details for when he does have the modules in place. At present I can’t diagnose anything as don’t know the details. Clearly step 1 is that EnumerateDevices finds and lists the USB numbers. Alas Ron’s most recent report simply shows what I’d expect when your module isn’t loaded. Not a problem with the program, but a null result because no module.

Here I can get a ‘list of zeros’ from the UCA202 if the modules are loaded but the UCA202 needs a usbreset. Until that is done and the probe can list meaningful results, it won’t work, despite being listed. Ron’s problem may be similar, but I can’t tell from what he reports so far.

Jim

I’ve now had a reply from a USA company who make a stereo USB ADC+DAC that works up to 192k/24 and has phono unbalanced connectors suitable to connect direct to home audio equipment. They intend it mainly for measurement and test purpose so the specs look good. All being well I’ll get one soon to try and get working. Then report on the results.

It may be useful for people as a DAC for playing audio as well as an ADC for tasks like making digital playing copies of LPs, etc. But I’m also interested in it as a basis for a device let me use an ARMiniX as an audio test and measurement setup.

Jim

Jim, so sorry, I was only loading Colin’s !UsbModule, and not Dave’s USBAudio, so now both C-media devices are being found. If your program requires a module you should use the normal method of checking for it in your !Run file.
RMEnsure USBAudio 0.02 Error USBAudio 0.02 required
or some similar thing.
I’ll try your player out tomorrow.
Cheers

Ron: Relieved to see that the puzzle is resolved! I agree I should use rmensures. However until now I’ve assumed we’re all softloading the modules for our experiments. But all being well I’ll add rmensures at some point.

I’m now close to having a demo/test of recording at a point where I’ll make a copy available. At present this chooses a device on the basis of the user specifying maker and device strings. So lets you use one device for recording and another for output if you wish. But as with my other progs, pretty elementary and clumsy code just so I can check how things work.

I keep trying to do something else, but finding I’m drawn back to the USB Audio. 8-] I’ve now had a reply from Behringer about their 96k/24 USB ADC/DACs as well, so will follow that up.

Jim

I’ve now put up a zip containing a version of three of my demo/test programs
!USBAudioProbe, Player, and, now, Recorder. Anyone interested in experimenting with them can find them via

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

Note that as before you must have Colin and Dave’s modules installed for them to be able to work. Reading the !Help file is necessary as you will almost certainly have to alter the ‘Settings’ file in, say, !USBRecorder for it to work. By default I have the recorder working with a Behringer UCA202 and it finds that by maker and device name strings. See !Help for details.
As usual, source code provided.

Jim

My apologies to all. I have just discovered that a call to USBAudio_EnumerateSampleRates will return rubbish unless some other SWI has just been called on that device and caused the device descriptor to be got and parsed.

I hope to have a corrected version available later this evening.

It’s up there now.

USBAudio_EnumerateSubframeSizes

ahem. Any news/progress on that? :-)

FWIW I’ve now written a rough draft of an article which I have a deadline for. Once that is done I have a couple of other jobs to do. When the above SWI may be included I hope to add it to my recorder app as it will make things much easier for users.

Beyond that I have two things in mind to do.

1) Write a modified version of my old !Iyoscope program which uses USB instead, so should work on any RO hardware that can use USBAudio to grab data. That should give people a scope/analyser/meter for audio-band checks and measurements. Indeed, with a 96k or 192k device might make a nice general scope/analyser.

2) Start work on a new section for the ROSS documentation. This being, of course, to add explanations and example chunks of code to make things clearer for others in future who want to write programs using USBAudio, etc. Once I’ve done a draft I’ll make it available for comment. I will assume unless told otherwise that the swis we now have are set and – all being well – will become standard in the OS at some point.

I’m also still awaiting one or two ADC/DAC devices. But as yet no idea what will turn up when. Behringer have now replied to my earlier emails so I’m trying to check some points with them.

Jim

ahem. Any news/progress on that? :-)

Ahem. Yes, I’ve done it. However, I also made a good start on documenting SetFeature, whereupon I realised that I haven’t implemented it properly. So you’re going to have to wait a wee while until I’ve got this increment up, running and documented. The increment includes GetFeatureVector, SetFeature and GetFeature, so that other ancillary features, such as bass/mid/treble, can be controlled and read.

After that, I think I’m going to take a break from working on the USBAudio module for a little while. I have some hardware projects that I really want to work on; I’ve had to put them on the back burner for a long time now. I will continue to provide support and bug fixes, and debate further work. Then at some point I’ll come back to it properly.

Is anyone aware of a USB definition for TRUE, in the context of sending a TRUE or FALSE value to something like the “mute” feature of a device?

I thought that any non-zero value would be taken as TRUE, but, in a moment of inspiration, I tried sending values 0, 1, FE and FF to the iMic’s mute featur. FE is taken as FALSE, same as 0. It looks as if the iMic really does look just at bit 0. I haven’t tested other devices yet.

But I’ve been looking through some USB IF docs, and I haven’t found a definition of TRUE.

I’d like to make sure that my documentation of the USBAudio module’s SWIs is accurate.

EnumerateSubframeSizes…

Ahem. Yes, I’ve done it. However, I also made a good start on documenting SetFeature, whereupon I realised that I haven’t implemented it properly. So you’re going to have to wait a wee while until I’ve got this increment up, running and documented. The increment includes GetFeatureVector, SetFeature and GetFeature, so that other ancillary features, such as bass/mid/treble, can be controlled and read.

OK. Once the new module is released I’ll update my progs to use it. Should make device selection and use easer. Particularly for someone using the recorder.

After that, I think I’m going to take a break from working on the USBAudio module for a little while.

Well deserved! Thanks again for the superb work you’ve already done on this. Your work and Colin’s has already transformed the audio capability of RO systems. My problem now is to find external hardware that makes the maximum use of what your work can provide. 8-]

Jim

Dave.

I’ve not seen a definition of a bool – or any other type – in the usb.org documents but it seems reasonable to me that TRUE is 1 and FALSE 0. This would tie in with a bool being generally considered a 1 bit value. C, for example, uses 0 and 1.

C, for example, uses 0 and 1.

And assembler, for example, often uses 0 and not-0 (sort of like CMP xx, #0; BEQ false; BNE true).
A fair few of my APIs return zero or some sort of error code. Think of it as error state is False (0) or True (anything else).

It is -1 on BASIC and VB (two’s compliment).

Passing on something from the ‘Archive’ email list where someone is trying the USB audio modules:

> On my Iyonix, RO5.16, the installer runs, reports it has completed, and
> says “press space to continue”. When I do that the filer craches with
> an ofla,ofla message.

AIUI this is when he runs Colin’s installer. He says that the process completes but then fails as above.

The detail I noticed is the RO5.16. Might that be the problem? If not, any other thoughts? I’ve asked for more info on details.

Jim

USB Audio requires RISC OS version at least 5.20. What s/he is doing is doomed to failure.

Ok, I’ll tell him about the need for 5.20.

Jim

Jim.

I haven’t tried with RO5.16 but have tried with RO5.18 – which is the rom version I use – many times and always run from the zip file the same as the one I distribute. I’ve rechecked the version on my web site with 5.18 and it works without problems.

I can’t see that 5.16 would be a problem – other than an error when shutting down – all the necessary modules are changed.

The Iyonix is that last computer I expected a problem with.

Presumably he’s downloaded the modules recently – though I’ve never had the problem on any version.

I can only suggest trying to load the modules first thing after booting – but I don’t hold out much hope for that working.

I thought having my Iyonix at 5.18 would be old enough enable me to track problems – obviously not.

Dave.

Just to confuse things and keep everyone on their toes, not all RO5.20s are the same. Arminix 5.20 doesn’t have the DeviceFS and SCSISoftUSB upgrade that everyone elses 5.20 have.

So he gets the error on shutdown.

I haven’t tried with RO5.16 but have tried with RO5.18

So have I! :-) I realised after my earlier posting here that my Iyonix isn’t upgraded to 5.20. I’ve been using it running RO5.18. And just checked again; Yes, the modules and all my demo/test program work on it OK. Only snag is pauses in 192k/24 replay from the main HD which we’d expect.

I’ve just put an email on the Archive list saying that 5.18 should work. That said, upgrading to 5.20 clearly makes more sense now. I’d have upgraded my own Iyonix but forgot about that having got my ARMiniX.

I’ll see if I can encourage him to join the forum as things will probably be easier if he can discuss it here directly rather than my ‘pass the message’. in between! :-)

But in practice it makes sense to encourage upgrading – if only because people should to get the modules eventually in their ROM and cut out having to softload!

Jim

Just remember to point out that an upgrade to 5.20 must be accompanied by an update to !Boot. When I say “accompanied”, “preceded” would be more accurate – i.e. the update to !Boot should be done first. Once updates, it will work with earlier versions too – but the converse is not true, i.e. you can’t run 5.20 without an update to !Boot.

And unfortunately an upgrade to !Boot in this case is not the simplest thing to do – you can’t get it to work just by merging a new one. There are instructions out there to follow. The instructions strongly recommend taking a copy of the existing !Boot, so, if the instructions are followed, there is a robust Plan B.

I upgraded all my machines months ago, so I don’t remember the details.

Just remember to point out that an upgrade to 5.20 must be accompanied by an update to !Boot. When I say “accompanied”, “preceded” would be more accurate

Ah! Maybe that’s another reason why I chickened out and left my Iyo at 5.18 once I’d got the ARMiniX. 8]

I’ll mention that. He may decide to join Colin and myself using 5.18 for now! ;→

Jim

I’ve started working on writing sections of the ‘ROSS Document’ to explain in detail, with examples, how to use the USB Audio. Two immediate questions prompted by this:

Dave: Can you say the swi number you’ll use for EnumerateSubframeSizes even if not ready yet to release a module with it or your API? That will make it easier for me to add a starting reference to it before I get to any explanations later.

Colin: Any documentation/API info you can give on the changes/additions you’ve made to the module swis, etc? A quick scan threw up a USBDriver_GETAPI_APCS32 swi which seems to be added. But I don’t know any details of any of the changes you’ve made which a programmer might want sometime. Or do you regard this as a system level matter and all user progs have to go though either Dave’s module or the methods in your Isoc programs?

Whilst writing about such matters it occurs to me it would be useful if we started a list of ‘devices known to work’ along with any details of their quirks (e.g. the UCA202 needing a usbreset) or devices that we know won’t work. That’ll help others join in.

Mention that as I’m still trying to get actual info about the Behringer UMC202, and it looks like the QA400 I has in mind won’t work as I’ve been told it doesn’t use the standard USB Audio protocols. So a dead duck. Shame as it is cheap and 192k/24 for input and output. :-/

Thanks,

Jim