How to do USB audio

Dave.

Questions that come to mind.

How do I choose device$ without looking at USB?

How do I choose configuration without looking at USB?

How do I know how big a buffer to supply USBAudio_OpenOut.

Why use bytes and words in the structure passed to USBAudio_OpenOut make them all words and you are less likely to make a mistake filling it in in BASIC.

Why pass parameters% and volume_bitfield% since one is read from the other. In fact why pass either of them when SYS "USBAudio_SetVolume", stream%, volume_setting would be enough information for your module to read volume_bitfield% itself.

I’d also make the buffer size specified in milliseconds with a default setting of 0.

How do I choose device$ without looking at USB?

I’m not sure I understand the question. Here are some possible answers:

You get a list of all the audio devices by calling USBAudio_EnumerateDevices. (If you’ve only got one USB audio device, the list will contain exactly and only the item you want; otherwise you’ll have to parse them out of a comma-separated list.)

You find out more textual information for each one by calling USBAudio_GetDeviceName. By the time you’ve done that, you should be able to identify which is which. (Again, if you only have one, there is no problem to solve.)

How do I choose configuration without looking at USB?

Yes. Have you ever found a USB audio device that claims to have more than one configuration? If you have, I’d be very interested to see what those configurations are and what they mean. Realistically, you choose configuration 0, which, if I understand correctly, is the current one. So it’s really a recipe; do this (using configuration 0), it just works.

How do I know how big a buffer to supply USBAudio_OpenOut.

That’s a matter for the number of bytes per second total throughput (which you know), and how long you might be away before you come back to fill the buffer again (which you presumably know).

Why use bytes and words in the structure passed to USBAudio_OpenOut make them all words and you are less likely to make a mistake filling it in in BASIC.

Could do; but the byte values can only be bytes, so any attempt to fill the top 3 bytes with a non-zero value would be a mistake. There are other examples of mixed length fields in RISC OS; look at Wimp_CreateWindow for example.

Why pass parameters% and volume_bitfield% since one is read from the other. In fact why pass either of them when SYS “USBAudio_SetVolume”, stream%, volume_setting would be enough information for your module to read volume_bitfield% itself.

In the simple analysis, you’re right. However, doing it this way gives the freedom to treat channels differently (which you would want to do to fake a balance control, for example) where controls exist in the individual channels as opposed to the master channel, by passing a bitfield with one channel per call. 99% of the people won’t need the facility 99% of the time, but the versatility is there, and it’s easy to not use the versatility, by just following the recipe.

I’m puzzled by your reference to stream% when setting volume. stream% is for the isochronous stream; volume settings are control transfers. In order to do all the control transfers according to stream%, I would have to make the module remember the device name associated with stream%, because I can only perform control transfers by device name – and the earlier transfers involved in USBAudio_GetDeviceName would still have to be by device name because there is no isochronous stream open yet, so there would be an inconsistent API.

I’d also make the buffer size specified in milliseconds with a default setting of 0.

It looks a bit obtuse to me, but what do other people think?

The USBAudio module is there to help application writers. That determines the level of general RISC OS and specific audio programming knowledge that its users can be expected to possess.

1) Enumerating devices just lists audio devices with no way of knowing which one is which. Providing a call to get the names so you can match against a name doesn’t help because you need to know the name to match.

2) Without knowing about USB configuration is meaningless.

3) I mean the block used to pass/receive parameters

4) using byte size fields doesn’t stop overwriting data by using ! Instead of ? and having to remember which fields are what length. Windows structures were written when memory was at a premium they wouldn’t be written like that now.

5) in your set volume you pass device$ and parameters. Parameters comes from openout which also returns stream so stream and parameters are not both required. You can find parameters inside your module from the stream handle. What’s wrong with having the module remember everything. Encapsulation is a good thing.

6) millisec buffer. You said it yourself

That’s a matter for the number of bytes per second total throughput (which you know), and how long you might be away before you come back to fill the buffer again (which you presumably know).

The new record work on a quick test i will test it later some more and let you know.
regards Rob

Apologies, I’ve not been keeping up during the last week or two. (Otherwise occupied.) And for the same reason I’ve probably forgotten some of what I’ve been told previously. Have a couple of questions…

Dave: Does your module now work for playback/recording on ARMiniX?

And WRT recording/input: I’d be interested to know what sorts of devices work. I’m wondering about getting a decent USB ADC for stereo recording and input. Ideally something that will run up to 192k/24bit to use for both recording purposes and as a good quality basis for using the ARMiniX as an audio scope/analyser/etc. i.e. similar to my old !Iyoscope but without its limitations due to hardware. So comments on what sort of hardware can be expected to work would be useful.

Cheers,

Jim

Does your module now work for playback/recording on ARMiniX?

Yes (probably) and no. I don’t have an ARMiniX; I do have a BeagleBoard xM, and it works on that as far as it does on anything.

To tell the truth, I’m a bit depressed about the module’s development. There are three of us interested: me, Colin and you:

• I’ve got it working for Release 1 devices. Development for release 2 devices is very difficult, as I don’t have a Release 2 device (and I have no intention of spending the amount of money that appears to be necessary to buy one, as I would never use it anyway; I only bought the Release 1 devices I have in order to develop the module; I don’t use them for anything else);

• Colin thinks I’ve designed it all wrong;

• you just want it finished.

Nobody else has shown any interest as far as I can see.

I wonder if the best thing I can do now is to make the source generally available (I always planned it to be part of the standard distribution of RISC OS) and let someone else take over and develop Release 2 support.

No don’t do that dave it’s good to have two streams of development it open up more ways to develop software in the future.
I will give it a try over the holidays the same as the new usb modules from colin, so don’t get down hearted, work though your designs to improve
the two approaches for the better.

Dave, I’m sorry you feel that way about your work on the USB audio module. The problem concerning (positive) feedback might have something to do with the fact that most users don’t understand what you’re doing and why they might want to see this project succeed.
I remember Jim’s original bounty proposal suffering a similar fate. Everything sounds like it’s some sort of special interest thing. Perhaps we lack the spirit of the RPi community in that regard, which would be a shame. All IMHO of course!

Colin thinks I’ve designed it all wrong

:-) I think everyone designs things wrong – doesn’t mean I can do any better. I even undo changes to RISC OS I dont like in my own version. All you can do is do it as you want it. I’m not in favour of discussing designs/interfaces. If I wanted to program someone else’s design I’d do this for a living. You should have just produced something and if people, ie me, don’t like it tough – you know it solves the problems you see. You won’t see a discussion document from me.

Nobody else has shown any interest as far as I can see.

I’m interested, but generally too busy to get involved, as doing so would probably involve spending hours and hours reading USB specifications so that I have a clue how everything fits together at the USB layer. Plus I don’t have any devices to test with!

I’ve had a read of the past few posts, and FWIW your API looks sensible to me. If it turns out that it isn’t sensible, then you’ll surely find out about it as soon as someone tries using it for a real project instead of just simple test apps. But until that happens, try not to worry about it too much :)

Plus I don’t have any devices to test with!

I think that is probably the crux of the matter. I don’t have any usb audio devices – indeed, I haven’t really got a clue where to obtain such things. It is all a bit ‘chicken and egg’. Until RISC OS can interface with usb audio devices most users are unlikely to buy them. I have been following the thread with interest, but have no way of being any more active or helpful.

Dave, I’m watching this with interest, but can’t test anything as I don’t have any suitable devices. But it means that once Jim is happy with the overall system I’ll be more likely to get something suitable and make use of it, but only as a user. I have no idea how to program audio software, but I do like the idea of having quality output from my system.

If you want to get the manufacturer’s name and model number:
DIM mfr% 256
DIM model% 256
SYS “USBAudio_GetDeviceName”, device$, 1, mfr%, 256 TO,,,, R4
SYS “USBAudio_GetDeviceName”, device$, 2, model%, 256

I’m afraid I don’t have much insight into USB audio in itself, it certainly sounds quite complicated!

On the proposed API though, a small tweak I would suggest is to allow the caller to find out the required buffer size rather than hardwiring 256’s in. A number of existing SWIs let you pass in 0 and you get back (minus or NOT) the size needed.

More generally, I see USBAudio as providing a similar role to SCSISoftUSB. There, the USB driver is at the bottom of the stack, SCSISoftUSB in the middle, and SCSIFS at the top. So USB driver remains generic, and USBAudio builds upon that conceptually higher up the stack, and some play/record application is at the top of the pile.

Dave, I think the responses show that people are interested. FWIW I’ve also had emails wrt your work and Colin’s. I think, though, that most are simply awaiting until they think it is “finished enough” for them to use. Particularly because they’d have to buy a USB DAC that will suit them and they’re confident will work OK.

I want things “finished” in the sense that they can be got working and people use them. But I don’t expect ‘release 1’ to be a halt to any changes or alterations or improvements. Indeed, I expect that whatever you and Colin release people will then start playing about with alterations and extensions and asking “can we…?” That’s computing as well as hifi. :-)

Can you please confirm the address to download from and I’ll try and give your modules /player a tryout tomorrow on my ARMiniX. I’ll also see if I can get my Class 1 old DAC to check as well as the Class 2 Pro.

More generally: Once you and Colin have general release versions you think people can use I’m happy to try and advise on some of the ‘good quality’ DACs about. That, along with your and Colin’s experience will probably help people get started. Alas, I can’t say much from direct experience about the USC DACs that are low-priced. But I can maybe have a go at changing that as well if I have a chat about it with you and Colin first.

Similarly, at some point I want to write something to document the APIs, etc, you’ve developed even though they will change in future. That will also help me and other people to make use of what you’ve done.

Jim

To tell the truth, I’m a bit depressed about the module’s development. There are three of us interested: me, Colin and you:

Oh there are more that are interested. The thing is that most probably think there is nothing they can usefully contribute and are therefore content to sit and listen.

In due course buying a few bits and adding them to the home setup will occur, at present income <= expenditure but when that situation improves and a bit of shopping is done a few bits of software added to the OS, or in it, will be needed.

I’m a bit depressed about the module’s development.

The primary thing – does it work for YOU?

If I wrote software expecting feedback and responses, I would have given up decades ago. I primarily (not always, but usually) write stuff for me. If it is useful to others, then so much the better.

There are three of us interested: me, Colin and you:

I think you’ll find there are three people actively interested. I am peripherally interested, but given that I listen to MP3s on ear lugs played by a mobile phone, I’m probably not the right demographic. However… There is a need to bring the OS’s audio capabilities into the Modern Era and when this is complete, potentially a lot of people will benefit. They just don’t know it yet. ;-)

I’ve got it working for Release 1 devices. Development for release 2 devices is very difficult, as I don’t have a Release 2 device (and I have no intention of spending the amount of money that appears to be necessary to buy one,

The solution is simple. Support release 1 devices. If in the future some people want release 2, they can donate/gift suitable hardware.

Basically – worry about release 2 devices some other time. The only advice I would give there is to cast your eye over any specs you might have to see if there are any things that would be good to include in the API ahead of time; but other than that, forget about it for now.

Colin thinks I’ve designed it all wrong;

:-) It seems entire countries would rather start a conflict than to try to compromise; so if two people don’t agree, who’s to say this is incorrect?

In the case of the design, there will always be people who don’t think something is right. In another thread I asked if GraphicsV could have a call to return the EDID information. Jeffrey says the IIC is more powerful/flexible, and he is right, but I am wondering why a program would need to fart around with IIC calls to read display settings info. The driver ought to have done this already. [as you can tell, I am a fan of the driver/library doing stuff so the application doesn’t have to]
A difference of opinion. His way will prevail, ‘cos, you know, he’s the one coding it (^_^) but it just goes to show that for even basic things, people will have different ideas of how it ought to be.

As for your module – do you believe it is well designed? Take a step back and look it objectively. Better fix things early than late (trust me, I’ve been there…). If you do that and think “I like it how it is”, then… all’s good.

[subnote: make sure your module copes well with insane inputs – it is amusing how quickly some parts of the system can fall over with dumb nonsense input data; when really the system ought to return error &BA115 "Bollocks!" – in fact, I would nominate that to be the standard response of any part of the OS/Wimp/usermodules if gibberish input is provided.]

you just want it finished.

Yeah, all the world is impatient. I have a little game (think !Patience, not Starfighter3000 !) I have been working on, but I have said nothing about it here or my blog or anywhere. That way, I can do it as and when I feel like it, with no pressure or hassle. This is all I’m going to say about that project; I only bring it up to point out that when people know of something, they’ll want it and want it right now. Just feel for the poor bloke developing ImpressionX – I bet he gets a load of emails asking “is it ready yet? is it ready yet? is it ready yet? is it ready yet? is it ready yet?”.

Obviously people interested in the project would like it sooner rather than later, but beyond that, work at your own pace.

At any rate, don’t jack it in!
Get it working perfectly (in your own time) with release 1 devices, then package it up for ROOL for inclusion within RISC OS itself.
As for the future?

Somebody much wiser than me said: the future is not set . . . there is no fate but what we make for ourselves.

I am peripherally interested, but given that I listen to MP3s on ear lugs played by a mobile phone, I’m probably not the right demographic.

Fear not. In my experience most people have never had a chance to sit down and listen to a really good stereo system playing excellent source material. Once they have, many are hooked… 8-]

That said, my view of this to remember the maxim “The Best is the enemy of the Good.” i.e. If we all refused to do anything because the result wouldn’t be absolutely perfect then none of us would ever do anything. You just do something that seems useful and pushes the situation forward a bit. Once people see you’re getting somewhere and twig why it may be useful, someone cleverer will come along and elbow you out of the way so they can do it ‘better’. :-)

Jim

There are three of us interested: me, Colin and you.

Another expression of interest here! Sadly I don’t have a ‘real’ RISC OS machine or any USB Audio equipment, so can’t test anything, so haven’t contributed. But I’ve been following the thread, since it’s obviously adding a useful capability to the OS. As far as I can see, this work has already resulted in useful fixes to USB more generally, and I think your USBAudio module would be a great addition once it’s finished.

On the API issue, I hope you’re not too discouraged. I don’t really have the expertise to comment on the detail, but aren’t APIs always controversial? Everyone has a slightly different thing they want from an interface, and as the author of the module it’s entirely your call which bits of feedback you decide to act on, and which you can discard.

Anyway, great stuff on the work done so far :)

Thank you, all who responded, for your words of encouragement :-)

There does remain a problem of how to add Release 2 support. As was pointed out to me privately, even getting hold of a Release 2 device carries no guarantee that it will enable me to add comprehensive support. There seems to be a tendency for Release 2 devices to have less controls, so I can’t test support unless I get hold of a device that does. On the other hand, if they don’t have controls, they don’t need support for controls. All of which suggests that I add bits of Release 2 support as and when necessary, by liaising with the device’s owner.

On the proposed API though, a small tweak I would suggest is to allow the caller to find out the required buffer size rather than hardwiring 256’s in.

The 256 was only hardwired into the example, which in turn was an attempt to show how much the module abstracts the caller from the nuts and bolts of USB.

I don’t think there is much of a problem with the buffer’s length; it is only required to hold a list of the USB device names of all the USB audio devices connected to the host. Each one of those can only be a maximum of 6 characters (e.g. USB123), plus a comma between names. So 10 audio devices would only require a buffer of 70 characters including the terminator.

That having been said, I need to examine the code to ensure I handle the length appropriately.

Oh there are more that are interested. The thing is that most probably think there is nothing they can usefully contribute and are therefore content to sit and listen.

This sums me up perfectly. I am very interested in this project. I do like audio having written a few trackers and MIDI’s over the years, and indeed have a lovely Topping TP-30 DAC+Amp combo unit that I love dearly. Unfortunately, I only use RISC OS via RPCEmu at the moment so cannot try out your work, but when I do get a new RISC OS machine (Cortex-A57 would be nice even if using ARMv7) it will be used.

Please don’t get too disheartened with so much silence. Your efforts are appreciated. I have plenty of Korean Pop waiting to be played using RISC OS over USB :-)

I have plenty of Korean Pop waiting to be played using RISC OS over USB :-)

And if anything thinks that is ‘weird’ I can confess that one of my xmas treats for myself arrived this morning. Two items.

1) A double LP by “The Shadows”. Collection of their early singles.

2) A 6CD set of all their early material.

Trendy, or what? 8-]

But to retain some audiophile street cred I can add that the LPs are 180gm vinyl (as if that mattered much) and I plan to do high rez digital transfers from the LP for day-to-day playing – via USB of course. :-)

Jim

More seriously…

I’ve now tried Dave’s player/module on my ARMiniX with an original (Class 1) DAC Magic. Works fine for 44.1k and 48k material. Higher rates didn’t work, but I think this is a limitation of the DAC. Later today I’ll give the Arcam rDAC (also Class 1) a try.

I also tried the (Class 2) DAC Magic Plus, but as expected this did not work. Threw up “Device not found at line 2530” as the error. But I assume this means “Eh? Wot’s Dis?” at getting presented with a Class 2 device.

Jim

I still haven’t put the module with first steps of Release 2 support on my web site yet. I’ve been playing with 3D modelling using OpenSCAD :-)

I’d better put it up there tonight.

But to retain some audiophile street cred I can add that the LPs are 180gm vinyl

credibility goes up……

and I plan to do high rez digital transfers from the LP for day-to-day playing

……and back down again.