How to do USB audio

If you don’t want USBAudio_OpenIn and USBAudio_OpenOut then use

USBAudio_Open
Entry
    R0 = "USB8"
    R1 = direction
    R2 = audio format block

Having the direction in either the swi name (USBAudio_OpenIn, USBAudio_OpenOut), the register or the block passed in a register makes no difference to the underlying code they are all just a means for the caller to tell you the direction. Having the direction in the format block or register means you have to define a value for IN and a value for OUT. May as well just have 2 swis where the swi number is the direction.

Removing the direction from the block means the block can be refered to as ‘the audio format block’

OPENUP, OPENOUT and OPENIN functionality could have been achieved with OPEN direction, file there is nothing different about them. Its all a matter of taste but I think individual names aids code readability. In fact C achieves the same functionality with a single fopen command.

_swix(USBAudio_OpenIn,_INR(0,1) | _OUT(1),"USB8",&fmt, &file);

or

#define USBAudioOpenIn 0x80
#define USBAudioOut 0
_swix(USBAudio_Open,_INR(0,2) | _OUT(1),"USB8",USBAudioOpenIn,&fmt, &file);

or

#define USBAudioOpenIn 0x80
#define USBAudioOut 0
fmt->direction = USBAudioOpenIn;
_swix(USBAudio_Open,_INR(0,1) | _OUT(1),"USB8",&fmt, &file);

Which do you think looks neater.

If you look at IsocPlayer line 109 you can see the what I’ve used to decide whether to play the file.

buf% is a buffer containing the first 36 bytes of the file. Line 90 where I have said ‘left here for reference’ shows how I expect the wav file header. It is possible to have chunks between buf%+12 and the "fmt " chunk – the player isn’t all singing all dancing.

The file that resulted in ‘Bad Request’ has passed the format checks and should play on any of your DACS.

After line 121

!controlData% = buf%!24              :REM set frequency

add

PRINT !controlData%

and after the first

PROCendpointControl

on line 122 add PRINT "HERE" on the next line

I think the error occurs when setting or reading the frequency so lines 122 or 123

I presume you don’t see

Sample frequency: 44100

printed out?

With the changes does 44100 and ‘HERE’ get printed out?

I modified the code to include

    DIM controlData% 32

    !controlData% = buf%!24
    PRINT !controlData%
                :REM set frequency
    PROCendpointControl(aSET%,aCUR%,eSAMPLING_FREQUENCY%,3,controlData%)
    PRINT "Here 1"
    PROCendpointControl(aGET%,aCUR%,eSAMPLING_FREQUENCY%,3,controlData%)
    PRINT "Here 2"
    PRINT "Sample Frequency: ";!controlData% AND &FFFFFF     :REM read frequency

The result was to get
44100
Here 1
Bad Request…

So it looks like the second call is going wrong.

Jim

Good the second one is only there to read the frequency back just put a REM in front of it

   PRINT "Here 1"
    REM PROCendpointControl(aGET%,aCUR%,eSAMPLING_FREQUENCY%,3,controlData%)
    PRINT "Here 2"

I’ve added the REM. This gets me as far as the program showing “Started”. It then shows a flashing cursor but no sound emerges.

I added an ncount% variable which should increment during every main REPEAT UNTIL loops, and print out a statement at each 50th run around the loop. But nothing appears. So it looks like it is entering the first loop and being ‘eaten’ by someone thing before it gets to the UNTIL.

I’ll have to put this on hold until tomorrow. I’ll then check to see if you’ve suggested what I should try next. Failing that I’ll add some “Here” printouts in the code in the loop to see if I can determine where the process is vanishing!

Jim

Given that the wave file is the correct format and its not a problem extracting the PCM data could you

1. Open a taskwindow and type dadr. return. (note full stop in dadr.) I’ll call this taskwindow A
2. then type dadp. in taskwindow A – don’t press return.
3. double click on IsocPlayerRun
4. when you see “started” press return in taskwindow A where you wrote dadp.
5. kill (not close) the taskwindow A as soon as starts printing – a couple of screenfulls of data is all I need

post the text that appeared in taskwindow A

Couldn’t resist having a quick try at this, but I’ve probably done it wrong as I’m tired at present. So I’ll have another go tomorrow. However I tried the process of using dadp. and got the results at

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

However I’m not sure I waited long enough. And I have to keep powering the machine as each failure seems to change its state so any later attempts behave differently. i.e. first tries give a “started” followed by nothing happening. A retry without a repowering gives an error.

Hope the above helps. but if not I’ll try again tomorrow and try to get it right.

Jim

It looks like you didn’t do a dadr. before running IsocPlayerRun. The module is continually logging information after !USBModule is run. The file you sent is just up to the detection of your arcam dac – which should have been cleared by dadr. . dadr. resets the log (clears it) so the idea was you clear the log, run the program and then read the log with dadp. after a couple of seconds. If you take too long to read the log the beginning gets overwritten – the log buffer is circular – and it’s the beginning I’m interested in.

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

Colin, I take your point about the direction, so I’ve split it out to two calls.

The parameter block doesn’t look like much of a fit to the WAV file header, though. I forgot about a whole lot of parameters, especially those that the open calls should return, so now it’s a 24 byte block, 12 bytes of which must be supplied to the call, and the other 12 of which are returned by the call. I hope the comments in the document are helpful, but this is the place to discuss it.

One other thing occurs to me: percentages are a poor way to control volume. I’m proposing the USB way of doing it, which is in dB (including a fractional part). It’s easy and it fits with human perception.

Anyway: I look forward to people’s thoughts!

It looks like you didn’t do a dadr.

Yes. Sorry about that. Wasn’t really thinking clearly at the time and got into a muddle. I’ve had another go this morning it it gave the results I list below.

*dadr.
*dadp.
Debug start
USBDriver: Service call reason 210
USBDriver: Service call reason 210
USBDriver: Service call reason 210
USBDriver: Service call reason 210
USBDriver: enter sleep:usbsyn                  irqstate:0
USBDriver: leave sleep:usbsyn                  irqstate:0
USBDriver: device_initialise: flags = a0000001, fs_stream = 208bdb54
USBDriver: looking for 1, iface 1, alt 1, type deaddead, dir a0000001
USBDriver: interface 0
USBDriver: interface 1
USBDriver: interface 1
USBDriver: endpoint 1
USBDriver: attributes 1
USBDriver: init_dev: found interface 1, endpoint 1
USBDriver: enter sleep:usbsyn                  irqstate:0
USBDriver: leave sleep:usbsyn                  irqstate:0
USBDriver: enter sleep:usbsyn                  irqstate:0
USBDriver: leave sleep:usbsyn                  irqstate:0
USBDriver: Isoc_construct
USBDriver: COLIN Isoc_construct ep = 1
USBDriver: COLIN Isoc_construct 00000000
USBDriver: Got xfer 200235d4
USBDriver: 200235d4 wakeup write, resetting count to 0
USBDriver: 200235d4 start_write
USBDriver: Isoc_fill_xfer_write: length=2112 nframes=8 f0=264 f1=264 f2=264 f3=264 f4=264 f5=264 f6=264 f7=264
USBDriver: Isoc_fill_xfer_write: length=2118 nframes=8 f0=264 f1=264 f2=270 f3=264 f4=264 f5=264 f6=264 f7=264
USBDriver: rediscover bus 1
USBDriver: Adding explore callback on bus 20023dc4
USBDriver: rediscover bus 2
USBDriver: Adding explore callback on bus 208f2204
USBDriver: rediscover bus 3
USBDriver: Adding explore callback on bus 208f02ec
USBDriver: bus discover 208f02ec
USBDriver: dev:2001b094 uctl:2001e0f4 
USBDriver: dev:2001d3b4 uctl:2001e0f4 
USBDriver: dev:2001e0f4 uctl:2001e0f4 
USBDriver: discovering 2001e0f4
USBDriver: enter sleep:usbsyn                  irqstate:0
USBDriver: leave sleep:usbsyn                  irqstate:0
USBDriver: enter sleep:usbsyn                  irqstate:0
USBDriver: leave sleep:usbsyn                  irqstate:0
USBDriver: enter sleep:usbsyn                  irqstate:0
USBDriver: leave sleep:usbsyn                  irqstate:0
USBDriver: enter sleep:usbsyn                  irqstate:0
USBDriver: leave sleep:usbsyn                  irqstate:0
USBDriver: enter sleep:usbsyn                  irqstate:0
USBDriver: leave sleep:usbsyn                  irqstate:0
USBDriver: enter sleep:usbsyn                  irqstate:0
USBDriver: leave sleep:usbsyn                  irqstate:0
USBDriver: enter sleep:usbsyn                  irqstate:0
USBDriver: leave sleep:usbsyn                  irqstate:0
USBDriver: enter sleep:usbsyn                  irqstate:0
USBDriver: leave sleep:usbsyn                  irqstate:0
USBDriver: finished callbacks, total sleep = 0
USBDriver: bus discover 208f2204
USBDriver: dev:2001b094 uctl:2001d3b4 
USBDriver: dev:2001d3b4 uctl:2001d3b4 
USBDriver: discovering 2001d3b4
USBDriver: finished callbacks, total sleep = 0
USBDriver: bus discover 20023dc4
USBDriver: dev:2001b094 uctl:2001b094 
USBDriver: discovering 2001b094
USBDriver: finished callbacks, total sleep = 0
*

In this case the flow of messages stopped quite soon. I waited for a second or so to see if any more would appear. When none did I killed the process and saved the results.

Hope this is now OK. Apologies if I’ve still done something wrong. I can appreciate that trying to diagnose by ‘remote control’ can be a real pain. I sometimes am asked to do similar for ancient audio kit someone is trying to repair so I know how frustrating it can be!

Jim

Its fine Jim. It looks like IsocPlayer is working ok so at least I don’t have to debug the test program :-)

Other than that it appears that there is no response from your Dac when sending data. That may be because the feedback endpoint didn’t open.

You should be getting a lot of sequences like this

USBDriver: Isoc_fill_xfer_write: length=1412 nframes=8 f0=176 f1=176 f2=180 f3=176 f4=176 f5=176 f6=176 f7=176
USBDriver: 201953d4 write_cb, status=0, actlen=0

You are not getting the write_cb responses. I’ll take this to email if you don’t mind.

I’ll take this to email if you don’t mind.

Fine with me. :-)

Jim

I’ve updated my proposed USBAudio API again at http://davehigton.me.uk/Audio/USBAudioAPI.htm

I’ve extended the parameter block to 28 bytes in order to make space for the configuration number. Although I’ve only ever seen configuration 0, I’m sure something will pop up eventually requiring a non-zero value.

I would appreciate any comments on the API.

My module seems to work. It certainly makes it very easy to do the simplest things with a USB audio device, and doesn’t require the application writer to know anything about programming USB whatsoever.

It will be time for a public beta soon.

Colin/Jim: has there been any other development of the USB stack?

Yes Jim has all his dacs working on his iyonix. As luck would have it an affordable asynchronous headphone dac has just appeared (dacmagic xs) in the last week. It’s really good can’t get anything done for listening to it – I can’t program with music on. Sounds better on my iyonix than it does on my windows laptop.

I’ll give your api some consideration and come back to you.

Sounds better on my iyonix than it does on my windows laptop.

Fantastic!

To add to what Colin said. At present I have a DAC Magic Plus setup with a Halide Bridge so that it has two USB inputs with slightly different behavours/interfaces. Both will work using my Iyonix, but at present I’ll be testing using the Halide Bridge, leaving the DAC Magic’s own USB as an input from a Linux box. I’ve also had the original (i.e. before the ‘Plus’ was released) working which actually uses the same USB interface as the ‘C Media Headphones’ adaptor. I was a few days ago focussing on the Arcam rDAC, but have since moved on to the above.

The DAC Magic Plus and Halide Bridge have successfully played 24bit up to 96k sample rate from the Iyonix. So have at present probably set the ‘best so far’ quality for a RO audio system. I’m tempted to say “work continues…” but of course it is Colin/Dave that are doing the work. All I’m doing is testing and reporting what I get with each version of the software, etc.

Jim

I’m using my Pi as a media player, currently with RASPBMC and a simple HDMI to TOSLink adaptor.

However I do plan to use it with RISC OS (and Linux and Raspyfi) via NOOBS

This device looks interesting:

http://www.amazon.co.uk/Teralink-Native-24bit-Converter-Electronics/dp/B00A2QM16I

Dave my thoughts about the api are that I’m having difficulty seeing where we are going with this and who we are catering for. I keep swinging between ‘let the programmer deal with descriptors themselves’ to ’forget about the programmer and write an audio module that plays files which can use plugins to do necessary conversions. Your plans look like they are somewhere between the 2.

What problem are we trying to solve

1) The user desides whether they want to play or record.

For the sake of discussion we’ll say we want to play a file.

2) The user decides what they want to play on

So how does the user know what output devices there are? I think you need a list of ‘speakers’ that you can output to that isn’t a list of USB devices it’s a list of Output Terminals which are connected to usb stream Input Terminals on the device.

eg a device may have a headphone socket which has volume controls and 2 line out sockets so you need a list something like

1 magic sound card – headphone – 1
2 magic sound card – speaker – 2
3 magic sound card – speaker – 3
4 CA Audio DAC – speaker – 1

where the first number is the device id, the bit before the ‘-’ is the device name and the bit after the ‘-’ is the device interface. The numbers at the end are the interface number which means that ‘magic sound card – speaker – 2’ is an approximation to a unique identifier which can be used to configure a ‘default speaker’. If you have 2 devices the same you are stuck with the first one found being the one used.

We’ll decide 2 – the first line out on the magic sound card

3) the user wants to write to channel to 2 with some format.

SYS “USBAudio_OpenSpeaker”,2,fmt%, bufsize% TO handle%

Use OS_GBPB to send data to device…

Use OS_Find to close handle.

4) user sets features with

SYS “USBAudio_SetVolume”,2,channel%,value%
SYS “USBAudio_GetVolume”,2,channel% TO value%,min%,max%

get/set mute etc.

No need to expose USB stuff (endpoints etc) at all is there?

If you need more than that for an application then the program needs to deal with the USB direct.

I think there should be various predifined channels that software uses, thet the user can define (in configure) where they end.

e.g.

hifi – this channel would be different to the others in that it defines the formats it can use, and it is up to the program accessing it to match the formats. (For example feeding an external DAC might allow DTS and AC3 as well as PCM)

All other channels would accept data streams in all formats supported by the operating system. They would also be able to be assigned a priority and whether they take the whole device or allow other channels to be mixed in.

media – media players could use this if the hifi channel didn’t support the sound format directly. (As opposed to being forced to to change the sample rate internally). I would expect this to be routed to the same physical device. If there was no HiFi device, this channel would be used by media players instead.

alert – system beeps and program alerts. (This would typically be routed to the desktop audio device, while media goes to an external DAC in a hifi system).

games – game sound

telephony 1 – headset
telephony 2 – speaker phone and ringer

legacy – anything using the current sound system

default – anything using the new system without a specified channel

The aim would be that the program chooses the channel depending on its purpose, and the user can define where the sound from that channel ends up.

Thanks for your thoughts, Colin.

I’m sure we don’t want programmers to have to deal with USB direct, so let’s rule that out. I think we can abstract all the functionality that most people need most of the time.

I would like to support the other extreme of functionality too (to play out a file or to record to a file). Right now I don’t know how to support that, so either I’ll need help or it will have to wait for a later release. I don’t think we have to have all the API determined from day 1 – although I would like to live in the ideal world where that is possible!

But there is another use that I have made of the Iyonix’s audio system: I used it in Iyophone (a VoIP user agent) to take real time audio from the microphone input and send real time audio
to the headphone output. The equivalent of that is somewhere between the two extremes you list, and is catered for in the present API.

The present API would also allow a USB audio device to be substituted for a computer’s sound system. It provides the half that handles the USB device, and provides an API through
which the integration can be done.

So how does the user know what output devices there are? I think you need a list of ‘speakers’ that you can output to that isn’t a list of USB devices it’s a list of Output Terminals which are connected to usb stream Input Terminals on the device.

The EnumerateDevices call does all it can to list the devices at a level that I think is appropriate, then you can call GetDeviceName to read as much textual identification as the device is capable of giving. You have probably seen that what they give is not great, but that’s all the devices give, so any more information has to be got via a different route.

No need to expose USB stuff (endpoints etc) at all is there?

I believe it is useful to expose some USB-specific information, especially the Feature Unit ID, because that’s necessary to set the feature. The user doesn’t need to understand it – as far as s/he’s concerned it’s an opaque number – just pick it up from where it’s delivered in the parameter block, and quote it when setting volume, mute, etc. If I keep this opaque number hidden, I have to keep state in the module; so far I’ve avoided the need for that, which is handy when devices can come and go, and you can be using more than one at a time.

Any more people’s thoughts are welcome!

I think you need a list of ‘speakers’ that you can output to that isn’t a list of USB devices it’s a list of Output Terminals which are connected to usb stream Input Terminals on the device.

I agree with the general approach described WRT how the user can see a list of audio input/output devices and select one in terms of some kind of name read from the device, etc. However I’m not sure about the best generic terms for this. ‘Speaker’ may confuse some if they have a DAC with line outputs which they have to connect to a hifi setup. having said this, I’m not sure what would be better than ‘Speaker’ if there is to be a word that covers all USB audio output devices. I tend to use as a general overall term ‘playout’ and ‘record’ for output and input devices, but these aren’t any kind of standard so I wouldn’t put ‘playout’ forward as a term. Maybe ‘Play’ and ‘Record’ are the best, even if not ideal for use as nouns!

I also suspect we’ll end up needing some kind of ‘ALSA script file’ the user can edit for situations where their hardware doesn’t fit what programmers have expected. Indeed, I suspect that different examples of the ‘same’ hardware will behave differently at times in use. Having a file with a standard set of ‘known’ devices and their settings this could me modified or extended in the light of experience without needing updates of – or tampering with – actual modules.

Jim

Jess

I think it would be simpler to just have a ‘system output device’ and you configure it to use the device you want from a list of known devices. You also need to be able to disable ‘system output’. It may be better to configure 2 devices, one that you want to use and another that will always be there. If the list of output devices includes a ‘null’ device then that would cater for machines without motherboard audio and be a way to disable the ’system output device.

The system device would be a mixer so all users of ‘system device’ share the device. This is more or less what we have now with the addition of device selection.

In programs the programmer defaults to ‘system’ but can allow you to select the device you want to use or if the program is device specific it can recognise it itself.

Dave

You only enumerate USB devices and this is not good enough. Suppose I have a device with 2 outputs and 1 input.

1. I use EnumerateDevices to get the list of USB audio devices
2. I read the device name using the usb id (eg USB8) and decide USB8 is the one. Presumably matching it with a name I’ve read before using USBDevices
3. I OpenOut the 2nd output on USB8. erm… I can’t

using the device name to identify the output doesn’t work. Whats more its all about USB

If instead you have a *USBAudioDevices command which listed audio inputs and outputs with unique names you can reduce everything to:

SYS "USBAudio_GetHandle",identifierName$ TO handle%
SYS "USBAudio_Open",handle%,fmt%,bufsize% TO fileSysHandle%

the exposure of any USB stuff isn’t required at all handle% is a proxy for all of it. To set volume you just need:

SYS "USBAudio_SetVolume", handle%, channel%, value%

However I would go further still and hide the DeviceFS interface so we just have

SYS "USBAudio_Open",identifierName$,fmt%,bufsize% TO handle%

handle is now not a filing system handle so you need:

SYS "USBAudio_read",handle%,buf%, bufsize% TO ,,actualBytesRead%
SYS "USBAudio_write",handle%,buf%, bufsize% TO ,,actualBytesWritten%
SYS "USBAudio_close",handle%

You could then write the same API for a motherboard audio devices

SYS "MBAudio_Open" ,identifierName$,fmt%,bufsize% TO handle%
	etc.

Then you can have a module with a ‘Generic’ version of the API

SYS "Audio_Open" ,identifierName$,fmt%,bufsize% TO handle%
	etc.

USBAudio and MBAudio register with Audio and the programmer uses the Audio interface to deal with all Audio devices regardless of how they are connected.

@colin

Obviously it would be much simpler, but it would also be a far less useful system.

If you can only have one system device (from the P.O.V. of programs), then it removes the simple option of having the system playing music to a hifi, while using it to do other work, with alerts coming from the desktop sound device, and would even make VOIP applications harder to use.

It would mean anyone who wanted to write an app that used an alternative sound system would have to to go to the effort of bypassing the main system.

Colin: I think you’ve simplified it beyond what will work. You don’t show any means to choose the number of channels, resolution or sampling rate, for example.