How to do USB audio

Yes, but the point is, the usb device is locked to only send that much data in real time, so it is just another useage of /that/ device. The same thing is going to happen if you want to play an MP3 flac optus or whatever compressed file you choose to play, they will be supersized as they go into the 48000Hz 16 bit wave device, normally without creating temp files though. You can farm out this work to a remote playing device to avoid expanding the compressed audio on your local machine in many ways if you prefer to do it that way. Up until now the average audio output of RISC OS machines could be matched or bettered by using a portable device, the desktop gives a more direct interface to your media libraries, and there will still be a need to send media files to a TV or related player, rather than playing video’s in RISC OS. Audio, OTOH can be handled reasonably well, especially with Dave and Colins improving of the available options.

I have had a play with the cheap ‘3D SOUND’ dongle with mic and out sockets.
It plays in 44100 or 48000, maybe this is doing an internal upsample like cheap devices do, No way of knowing really, I guess an audio quality check would be what matters.
Recording is also only in 44100 or 48000 mono or 22050 24000 2 channel.
Using a modified !Run file and the same C-Media section but with a product ID of &00e.
Only an xSamplesize% of 2 is allowed

Rather than use “end by pressing any key” which for some reason led me to using ESC, I reduced the number of keyboard scans and stopping the recording session now requires a firm press on the End key, with this change.

ctr% += 1
IF ctr% = 30000 THEN
ctr% = 0
IF INKEY(-106) THEN ctr% = -1
ENDIF
UNTIL   ctr% = -1

Edit:
I have just noticed you can change the number of recording channels from 2 to 1 in the C-Media section, which halves the file size for microphone use.

Processing the mic input in a quick way for compressing or reducing the size will be another thing, I have noticed programs with functionality for telephony and opus has a voip mode. The new opus 1.1 claims 30% less cpu useage for arm, but they will be using the extensions I imagine. Opus seems to be crawling on my Iyonix.
The ssrc is the fastest downsampler for 44100 down to 11025 by a factor of 2, sr-convert is ridiculously long about it, sndfile-resample with the quick setting twice as slow as ssrc.
I haven’t tried sox or ffmpeg yet.
There may be a quick and dirty downsampler around suitable for long duration voice level recordings when the quality is not important. ( a monitoring application)
Edit: having found that 24000 stereo can be recorded, I imagine stripping one channel would be a quick way to downsize the output file.
There may be a complication with which channel a mono mic will go to. I think computer mics use one contact for power to the mic, but confusingly the mic sockets seem to record stereo on that jack.

The ssrc is the fastest downsampler for 44100 down to 11025 by a factor of 2,

I may be wrong as my memory is unreliable. But I think sox uses ssrc. Whatever, it gives good quality results using its defaults.

having found that 24000 stereo can be recorded, I imagine stripping one channel would be a quick way to downsize the output file.
There may be a complication with which channel a mono mic will go to.

Alternatively, simply summing/averaging the two may be quick enough. Watch out for unintended overflows, though! I think I caught at least one version of Audacity showing the signs of this. That said, in general I’d advise keeping recorded values well below max as otherwise even the simplest process can produce overflows or clipping.

Jim

My cheap sound dongle is a C-Media device and only records 44100 and 48000 mono. There seems to be a lot of devices with C-media firmware I’d be interested if you’d run USBDescriptors.zip with the device plugged in to see what its capabilities are.

Colin, here is the C-Media ID &00e descriptor

Jim, yes I have read good things about the sox resampler, I built the smaller libsoxr but it doesn’t come with a ready made resampler binary.
ssrc uses Fast Fourier Transform, ISTR sox uses something else.

Having now sent off something I had a deadline to write I hope to switch my attention (such as it is!) to experimenting some more with USB. One part of that will be to get some new devices to try. I’ll report on that when I have more ideas. The other is to write some simple ‘C’ progs to get familiar with how to use the modules.

Colin: I know that Dave has published an API document, but I can’t recall if you have. Is this now set well enough and available? Otherwise I’ll have to try an work things out by head-scratching over the BASIC in your player!

Jim

Fairly “off the wall” question/idea…

Would the ResourceFS approach (as per Colin’s demo) work using !GraphTask running a program in ‘C’? Since I’ve almost never done any wimp programs that might make it easier for me to do a more ‘interactive’ demo player.

I’ve just done some quick tests using !GraphTask from

http://www.armclub.org.uk/free/

and the supplied (BASIC) progs run happily on my ARMiniX. However the help file does say

“Works if you:

Does that rule it out?

I’m thinking of a player that will graphically show the file details, elapsed time, and give a slider bar to change the point being played, etc.

FWIW Under Linux I’ve used SDL for doing a GUI for playing (and grabbing) audio. But of course there you don’t need to deal directly with the desktop multitasking.

Jim

Jim.

ResourceFS?

Yes you can write the program using !graphtask but it will have the same problem of any application space program ie it will pause when f12 is pressed.

I’d be inclined not to use stdio.

The USB part is simple. Just open a file, write bytes to it and close it.

When using my IsocPlayer a line comes up something like

USB8#nopad;noblock;size176400;samplerate44100;samplesize4;interface1;alternate1;endpoint1:

that’s the filename.

Ronald.

I don’t know how you got 24000 and 22050 stereo the device claims only to be 48000 or 44100 mono.

Yes you can write the program using !graphtask but it will have the same problem of any application space program ie it will pause when f12 is pressed.

For my idiot-simple test/demo purposes I’m not worried about it being vulnerable to f12, etc. Just want something that gives more userinfo and control to illustrate and look a bit neater. No-one in their right mind would use what I’d write as their standard player, I hope! I hope someone cleverer than me writes a sensible desktop app or alters a familiar player to output to USB! Maybe the ugly nature of what I’d do would spur a better programmer offended by the awfulness of what I did. 8-] But it will help me suss out things without having to learn how to write wimp apps whilst I’m trying to make sense of the USB audio as well.

I just had a go, and yes, I altered a line in your main player program to specify the input file for simplicity. Then dropping the resulting prog onto graphtask caused it to run the program and play the file OK. Output appearing in the graphtask window. So I’ll use this to play… erm learn with.

I presume from what you say that I write the bytes having added/removed bytes when needed to match the DAC requirements? e.g. if the DAC wants 4bytes/sample and I’m playing a 16bit file I give the dac 2 data-from-file bytes followed by two zero-bytes per sample?

Once I get the hang of this I can also use it to play… experiment with inbuilding conversions, etc. eg experiment with adding upsampling or scaling using 24bits, etc.

Also, when I get an ADC it may let me write an equivalent to my old !IyoScope for ARMiniX, etc. Found that useful as a scope/FFT/signal analyser at times.

It will also help me when I finally get back to writing the ROSS document and I add a section on the ‘proposed’ API, etc, details for inclusion of USB audio.

Jim

‘I don’t know how you got 24000 and 22050 stereo’
Other settings also worked but the playback was incorrect, probably because the data rate is fixed to two speeds 96000/88200 1ch 48000/44100 2ch (sndfile-info). Recording at 12000 resulted in a longer track with the music playing back at half speed (slowwwly), in other words the same size file in a 12000Hz container.
The driver/device refuses anything other than xSamplesize% = 2 but you can adjust xSamplerate% and xChannels%.
xBits% = 8 produces screeching noise only, but I didn’t try more combinations.
I dont know enough about the lower level, do you thing it would be possible to change the xSamplesize% at the device?
I guess there is a bit of flexibility there for processing, Maybe a program can change the bitrate in a 12000Hz container easier than downsampling 48000Hz to 12000Hz, but I really haven’t tried anything yet.

If you look at the descriptors your device only has 1 interface to record data (only 1 Audio Streaming interface with an IN endpoint). The interface is described in a collection of descriptors one after the other. So the recording interface on your device is:

    Standard Interface Descriptor
    +----+---+----------------------+----------+------------+
    :Off :Sz :Name                  :Value hex :Value dec   :
    +----+---+----------------------+----------+------------+
    :  0 : 1 : bLength              :        9 :          9 :
    :  1 : 1 : bDescriptorType      :        4 :          4 :
    :  2 : 1 : bInterfaceNumber     :        2 :          2 :
    :  3 : 1 : bAlternateSetting    :        1 :          1 :
    :  4 : 1 : bNumEndPoints        :        1 :          1 :
    :  5 : 1 : bInterfaceClass      :        1 :          1 : Audio
    :  6 : 1 : bInterfaceSubClass   :        2 :          2 : Streaming
    :  7 : 1 : bInterfaceProtocol   :        0 :          0 :
    :  8 : 1 : iInterface           :        0 :          0 : ''
    +----+---+----------------------+----------+------------+

This is where xInterface% and xAlternate% comes from xInterface% = bInterfaceNumber and xAlternate% = bAlternateSetting.

         Audio Streaming Interface General Descriptor
        +----+---+----------------------+----------+------------+
        :Off :Sz :Name                  :Value hex :Value dec   :
        +----+---+----------------------+----------+------------+
        :  0 : 1 : bLength              :        7 :          7 :
        :  1 : 1 : bDescriptorType      :       24 :         36 :
        :  2 : 1 : bDescriptorSubType   :        1 :          1 :
        :  3 : 1 : bTerminalLink        :        7 :          7 :
        :  4 : 1 : bDelay               :        1 :          1 :
        :  5 : 2 : wFormatFlag          :        1 :          1 : PCM
        +----+---+----------------------+----------+------------+

This tells you that the interface transfers PCM data.

         Audio Streaming Interface Format Type Descriptor
        +----+---+----------------------+----------+------------+
        :Off :Sz :Name                  :Value hex :Value dec   :
        +----+---+----------------------+----------+------------+
        :  0 : 1 : bLength              :        e :         14 :
        :  1 : 1 : bDescriptorType      :       24 :         36 :
        :  2 : 1 : bDescriptorSubType   :        2 :          2 :
        :  3 : 1 : bFormatType          :        1 :          1 :
        :  4 : 1 : bNrChannels          :        1 :          1 :
        :  5 : 1 : bSubFrameSize        :        2 :          2 :
        :  6 : 1 : bBitResolution       :       10 :         16 :
        :  7 : 1 : bSamFreqType         :        2 :          2 :
        :  8 : 3 : tSamFreq[0]          :     bb80 :      48000 : Hz
        : 11 : 3 : tSamFreq[1]          :     ac44 :      44100 : Hz
        +----+---+----------------------+----------+------------+

This is the descriptor which tells you the format of the data. This is where xChannel%, xSamplerate%, xSamplesize% and xBits% comes from. xChannel% = bNrChannels, xSamplerate% is either 48000 or 44100, xSamplesize% = bNrChannel*bSubFrameSize and xBits% = bBitResolution. Note the bit resolution does not affect the sample size. bBitResolution is really the significant bits in a bSubFrameSize sample.

xBits% and xChannel% are not used to open the USB endpoint they are used to create the wav file header.

         Standard Endpoint Descriptor
        +----+---+----------------------+----------+------------+
        :Off :Sz :Name                  :Value hex :Value dec   :
        +----+---+----------------------+----------+------------+
        :  0 : 1 : bLength              :        9 :          9 :
        :  1 : 1 : bDescriptorType      :        5 :          5 :
        :  2 : 1 : bEndPointAddress     :       82 :        130 : Endpoint 2 - IN
        :  3 : 1 : bmAttributes         :        5 :          5 : Isochronous, Asynchronous, Data Endpoint
        :  4 : 2 : wMaxPacketSize       :       64 :        100 :
        :  6 : 1 : bInterval            :        1 :          1 :
        :  7 : 1 : bRefresh             :        0 :          0 :
        :  8 : 1 : bSynchAddress        :        0 :          0 :
        +----+---+----------------------+----------+------------+

This is where the xEndpoint% value comes from xEndpoint% = bEndPointAddress.

         Audio Streaming Endpoint Descriptor
        +----+---+----------------------+----------+------------+
        :Off :Sz :Name                  :Value hex :Value dec   :
        +----+---+----------------------+----------+------------+
        :  0 : 1 : bLength              :        7 :          7 :
        :  1 : 1 : bDescriptorType      :       25 :         37 :
        :  2 : 1 : bDescriptorSubType   :        1 :          1 :
        :  3 : 1 : bmAttributes         :        1 :          1 :
        :  4 : 1 : bLockDelayUnits      :        0 :          0 :
        :  5 : 2 : wLockDelay           :        0 :          0 :
        +----+---+----------------------+----------+------------+

And finally the interface has this descriptor which describes the delay in locking on to the frequency.

If the device had a stereo recording interface as well as a mono recording interface it would need another set of interface descriptors describing a stereo interface ie it would have bNrChannels = 2 and different interface,alternate and endpoint numbers.

I think your stereo is 2 channels playing alternate mono samples ie you’ve just changed the wav file header. There is no way to tell the device to send stereo

I’ve been looking again at your code, Colin. Alas, I’m still getting stuck by trying to work out what SYS/SWI calls, how, set up the transfers. I’m still not clear on various points and suspect I’m muddling different things together. Also having trouble seeing what’s happening because I’ve not used BASIC for so long that I keep having to work out or check simple lines! :-/

My initial assumption is that to have the program work I need to:

A) Locate what (if any!) USB audio devices are available and determine what sample rates, etc, they can accept, and details like how many bytes per value they require.

B) Tell the device what rate, etc, I want for a transfer.

C) Initiate a save and then save the data payload into the ‘file’.

D) Clear the transfer so the device knows this has finished.

But I suspect I’ve misunderstood. Is it that I should simply regard playing as the process of saving a file of the data payload and all the specs are in the filename? That does ring a bell with what I did using !AudioIn to use the Iyonix as a scope.

So, you gave the example

USB8#nopad;noblock;size176400;samplerate44100;samplesize4;interface1;alternate1;endpoint1:

I want to check the syntax here.

Is there no preceeding file system before the “USB8”? And I guess I should also ask how I determine that USB device ‘8’ is the one to use. However I can always do a *usbdevices first and find out for now. :-)

size seems to be samplerate * samplesize, whose values seem clear enough.

But how do I determine the interface, alternate, and endpoint values?

For initial tests I can note them from running your own program. But at present I can’t see though the BASIC to see how you find the values for such things.

Sorry I’m a numpty wrt BASIC, etc.

Jim

Jim: the whole point of writing the USBAudio module was to abstract application writers from USB, and thus not have to understand much (if anything) about USB.

So why not use the USBAudio module, which, after all, does have a published interface?

And example code, too, in the form of my UAPlayer application.

‘I think your stereo is 2 channels playing alternate mono samples ie you’ve just changed the wav file header. There is no way to tell the device to send stereo’

Yes you are right, I did suspect it might be just reordering, which is why I refrained from saying stereo, and described it as 2ch. I have now checked with a proper left-right test signal and can say that it is recording both left and right as one and then pouring the mono stream into the 2 channels.
I think the very quick (and probably a bit dirty) way to downsample this fixed sample rate would be to filter it with BASIC by redoing the header and dropping every second 16bits.
 

Jim: the whole point of writing the USBAudio module was to abstract application writers from USB, and thus not have to understand much (if anything) about USB. So why not use the USBAudio module, which, after all, does have a published interface?

I was/am planning to also do that. However at present I’m trying to avoid also writing a WIMP application as that adds complications for me. Also, one of the main points is to let me learn and illustrate when I write documentation others can follow. I tend to take the view that the best way to understand something is to learn enough to be able to make it work and satisfy myself I’ve understood the necessary details sufficiently.

So if I find writing something using what seems like the simple ‘direct’ “write to a file” ResourceFS method, then I’ll switch to something based on your module as my first effort. I’d still want to come back to the ‘file’ method, though in time.

Would your module also work from GraphTask? Or would that be problematic?

Actually, presumably I could use your module to get device details even if the program then used the ResourceFS / file approach for playout?

And is it a bad thing if I nudge Colin into specifying his API / SWI uses explictly? Will make it easer for me to explain to others. :-)

Jim

Jim,
Can I suggest that if you are writing a Basic Wimp program you should have a look at my Reporter module. It provides debugging commands that can be added to the program so you can easily see what it is doing and why, with variable values, in real time. See website

I’m trying to avoid also writing a WIMP application

Would your module also work from GraphTask?

No connection with either of the above. It will “just work”.

You do seem to see complications where none exist…

Can I suggest that if you are writing a Basic Wimp program

Not doing that. I’m writing in (Norcroft/Acorn/ROOL) ‘C’ (or at least intending to). One of my problems is that it is many years since I wrote anything in basic.

But I’m hoping to have the program work using !GraphTask which is a way of allowing a taskwindow to show graphical results. i.e. I can draw things like colour progress bars/thermometers, etc, to give an apparent GUI more like a typical wimp amp.

Jim

bq.bq. Would your module also work from GraphTask?

No connection with either of the above. It will “just work”.
You do seem to see complications where none exist…

When lucky, yes. :-)

I’ll have a play using your module with GraphTask. But no doubt I’ll end up head-scratching over BASIC again. 8-/

Jim

Forget about BASIC your first problem it seems to me is you don’t know how to read and write to a file using RISC OS.

Here’s a small C library (rofile.zip) it’s not fully comprehensive but it will open and close files and the read/write functions are suitable for nonblocking transfers – ‘remaining’ is the number of bytes not transferred.

It may help get you started.

Forget about that you want open and close to be based on Daves module.

Oh and what has ResourceFS got to do with anything?

Forget about that you want open and close to be based on Daves module.

OK. I’ll have a go tomorrow. (Had to go out this afternoon.)

Oh and what has ResourceFS got to do with anything?

Probably a sign of my lack of understanding. But I’d though that the way your modules allow the use of ‘file’ transfers was an instance of a ResourceFS-like filing system.

Jim

But I’m hoping to have the program work using !GraphTask which is a way of allowing a taskwindow to show graphical results. i.e. I can draw things like colour progress bars/thermometers, etc, to give an apparent GUI more like a typical wimp amp.

I can’t help but wonder if you aren’t going to be making things more difficult for yourself by doing it this way?

It isn’t so hard to make a little desktop application to oversee music playback, this is one I wrote a billion years ago for playing CDs – http://www.heyrick.co.uk/voyager/mewzyck.html – I might even have the source still kicking around someplace. ;-)

One thing I would suggest is that you try – if possible – to separate the fancy UI and the physical playback. This is because you cannot tell what the latency of the Wimp polling will be. As the system uses co-operative multitasking, applications cede control when they are ready. While you can work out how long each loop around is using heuristics, what happened in the past is no reflection on what will happen the next time around.

You’ll notice that multitasking players (pick one!) tend to have the back-end as a module which will get on with the boring grunt work pushing data around (on callback or buffer empty event) and the front end will do all the interfacing with the user. [this also means it should survive an F12, but things might get unstuck if the user is out of the desktop when the current song finishes!]

Sorry, I’m new on this thread ;-)
and also sorry, I think I not understand all posts right :-(

Last year I have buy a box called “Xpress Dock” for my Pandora-Dock and works fine with Linux

The box is a USBHub 4x … works also with RISC OS
a USB to
1. Ether… works fine with EtherUSB if I set the Vendor_Product_IDs manual
2. VGA grafic"card"… works with Linux
3. Audio in/out device … works with Linux

With 3. I play around a little bit on my Panda and with the Software from this thread.
The output from DecodeDesc, ModuleTest, USBDescriptors… you can find here

I try also !UAPlayer after I load USBAudio. If I drag a ISOSample on it I became a

Error: No matching parameter set at line 1580

What can I do, what is my mistake?

Is it possible tu try audio in?

Many thanks.