Audio Recording API

I am thinking we should use something like the LINUX Sound library as base for a RISCOS sound libary
https://www.alsa-project.org/alsa-doc/alsa-lib/

I presume that would be “Something like the concept, but without a trace of GPL infection” when the text is expanded.

During my search for good available software for RISC OS I came across Jason Tribbeck www.tribbeck.com
It turned out that he is interested to write the needed drivers for RISC OS to solve the sound issues for ever.
He will post here in the next hours his proposal as PDF as it is several pages long.
Please read it and comment. We have prepared this to get an agreement as fast as possible as we don’t want to discuss for month and then at the end have no result. So please only comments that are result orientated so that we can go forward.
The idea is to have a foundation that can be later extented or adopted to new hardware. So help us to discover missing issues. But don’t forget this is the base not the whole final solution.

Thanks to Stefan’s prodding, I’ve been having a look at not only audio capture, but the audio system as a whole.

It’s been quite a few years since I have done anything with the sound system (getting !Equinox working on a 16-bit sound system, IIRC), so I was quite surprised as to how much it had changed. I had to rejig the text quite a bit when I found new things out, and I’m really hopeful it doesn’t misrepresent the current situation.

My thoughts are downloadable from below:

http://www.tribbeck.com/index.php/download_file/2206/0

The goals are to:

• Allow audio input
• Support multiple interfaces at the same time
• Have higher resolution formats
• Provide backward compatibility with what has been done before

Since modern hardware has I2S as the audio communications mechanism, any changes to allow audio input on such a system has to involve changing the audio output, as the communications occur simultaneously – hence this being a wider view than I had originally planned.

Seems good. The only question is what happens with concurrent feeds, especially SoundDMA ones? Will it block something? Will it be possible to choose which one has the exclusive access?

It’s today incredible to see a desktop game stopping DigitalCD from working just because it fires a sound.

If a game decides to use a SoundDMA linear handler, rather than SharedSound driver, then it’ll probably be the game that takes priority (it’ll register itself, and that’ll replace the SharedSound driver). This is, I believe, what currently happens anyway (I’ve not had the chance to try it yet, and I wasn’t 100% sure – so am willing to be corrected!)

It might be possible to reorganise things so that a linear handler is always the first one called, and then SharedSound overlays its audio on top of it.

The problem then comes if the game decides to use 24-bit or 32-bit samples – I didn’t really want to have to have all the SharedSound handlers have to cope with multiple formats, or modify SharedSound to do a lot of post-processing work. So maybe the option is that if the game is 16-bit audio, then SharedSound can still do it’s thing, but if it’s not, then SharedSound won’t do anything.

Although I was mainly thinking of professional audio applications that may want a higher resolution – and in that case, a user probably doesn’t want to have audio from other sources ‘interfering’ what they’re doing.

I didn’t really want to have to have all the SharedSound handlers have to cope with multiple formats

Why not. But SoundDMA could do it?

Nota: a tool to choose the stream to play (when you can’t mix the different streams) would be nice. With a switch possible at any time, without crashing everything.

It’s currently one step at a time, and it’ll be complex to do – so something for a later date.

Adding 24-bit and 32-bit support to SharedSound requires adding support to it in the applications, rather than SharedSound (unless SharedSound takes the 16-bit data from the applications, and upscales it to 24/32-bit – which is computationally more expensive than getting the SharedSound applications to support these new formats directly, although that is an interim possibility).

LinearHandler applications that require the higher resolutions will need to be coded to do it when they need it.

SharedSound applications will have to do it when they don’t need it (because you have no idea when an application will switch to 24/32-bit because that application needs it). They’ll also have to cope with switching sample formats mid-stream.

I suppose what I’m saying is that SharedSound applications need to be proactive and support all the formats directly. LinearHandler applications just need to be reactive.

Note that encoded transport mechanisms (such as MP3) will not really work with SharedSound anyway – unless the MP3 is decoded as LPCM, merged with SharedSound, and then re-encoded as MP3. This will be pretty CPU intensive (although by the time it’s implemented, it might be a doddle!)

And multi-output devices would be fun with SharedSound (which of the 8 outputs do you want the two channels going out?)

It’s currently one step at a time, and it’ll be complex to do – so something for a later date.

OK for me :)

In the beginning was the beep, and the beep was WaveSynth-Beep.

Any document that begins with this phrase is worth reading.

I’ve read your proposal a few times and I think I understand it. It seems logical, structured with a nice phased approach.

What the document doesn’t explicitly say is who could or would do the work. I’m hoping you, but don’t want to assume.

Ta – I was quite pleased with that line!

I am on the shortlist of one :)

Just need to get the hardware together (I’m designing an I2S board for Raspberry Pi that I can easily debug [attaching logic probes to]).

I am on the shortlist of one.

That’s one hell of a short straw to pull.

Hats off to you. As an ex VTi Sound sampler and Sonor user it’s good to see you back.

Strictly speaking SoundChannels is not the only legacy 8-bit sound module, quite a few modules bypasses it and register directly with SoundDMA. That said I don’t think any of them are 32-bit compatible.

Personally I would not touch the SoundDMA API, I would just implement the whole new API in SharedSound and make SoundDMA redirect to SharedSound. That way you change only one set of APIs and you gain the advantage that non-shared sound applications don’t mute the sound from the ones using SharedSound.

Yep.

If a game decides to use a SoundDMA linear handler, rather than SharedSound driver, then it’ll probably be the game that takes priority

If something registers with the SoundDMA linear handler, SharedSound will stop working. This is easily resolved however, just take over the SoundDMA linear SWI and redirect it to SharedSound.

I would not touch the SoundDMA API, I would just implement the whole new API in SharedSound and make SoundDMA redirect to SharedSound

That is the approach I would also take.

The problem isn’t in SoundDMA, LinearHandlers or SharedSound. The problem is in the applications that have implemented SharedSound.

At this moment in time, they’re all expecting 16-bit to be the format, so when they do their mixing, it’ll be in the 16-bit domain, with 16-bit input, and 16-bit output.

If SoundDMA’s LinearHandler became a provider to SharedSound (which is one way to allow SharedSounds to mingle with LinearHandlers), then every application that is currently hooked into SharedSound must’ve been written to support 24/32-bit audio paths – otherwise they’ll either:

a) not work
b) work badly
c) the path would need to be degraded down to 16-bit

I do like the idea of a single API, but until every SharedSound application you use has been upgraded to support 24/32-bit audio streams, then you may as well not bother with getting something to produce high quality audio output.

Few applications will need 24/32-bit (and when they do, it’s for a reason +), and most people probably won’t notice any difference.

We could simply stay at 16-bit, but we might as well have a go at making it a bit better for the future. Unless we can ensure that all SharedSound applications are upgraded (or we have a method for dealing with these), then supporting applications which might be forced to stay at 16-bit will be complex – and something for a later discussion.

+ What I’m thinking is something akin to Cubase where the user is trying to write music – this would benefit greatly from higher resolution sounds, and the user probably doesn’t care that their background music has stopped, since they’re writing their own. In all likelihood, they are using a dedicated card for their music creation anyway…

If I was writing such an app, then I would probably warn the user when they selected the higher resolution that this could cause background sounds to be cancelled.

And I would argue that if you don’t need high quality audio, then only use SharedSound – your output is going to be messed around with anyway, and never write a SoundDMA interface (but I suppose it depends on how much you want your app to work on older systems…)

Let me have a think about this. I was trying to get something which was more manageable with single steps to upgrade functionality incrementally (I knew SharedSound would be problematic, so I wanted to do this later). Completely reorganising the way the sound system works wasn’t what I was planning :)

We need to implement something that is future proof and we don’t need to care for homemade apps that have been programmed 30 years ago that nobody uses anymore. We cannot care for programs that 10 people use and neglect the need of the future 10 million RISC OS users.

The current SoundDMA could be plugged in ShareSound, because it’s used by many applications and it causes many problems. That does not mean that a new SoundDMA could not be made for those applications that need low latency and exclusive access to sound devices. Both are possible.

And later, it will be time to know what to do with SharedSound. It must be able to mix 8/16/24/32 streams. By upscaling or downscaling (lighter on CPU). This could be an option: upscale to the best format in use OR downscale all to 16bit.

If SoundDMA’s LinearHandler became a provider to SharedSound (which is one way to allow SharedSounds to mingle with LinearHandlers), then every application that is currently hooked into SharedSound must’ve been written to support 24/32-bit audio paths – otherwise they’ll either:

That is something I don’t understand. Either you can connect to SharedSound in 16-bit mode as it is now and so SoundDMA can connect to it too or you can’t rely on 16-bit and you break every existing application using SharedSound.

I want to thank Jason Tribbeck for his professional approach to solve this issue and to contribute to RISC OS’s future.

PS: Jason has also shown interest to integrate AMCOG Digital Signal Processor
AMCOG RDSP

Can you change the USB api while you are at it – maybe expose the netbsd api. The usb api is far to slow and you lack the fine control you’d like when writing a driver. I did get get DigitalCD working once with usb audio for about 5 seconds then lost the will to live.

I use Colins IsocUSB stuff for record/play (Ti, Pi, xM) if I need…
ARMX6 has it comparable in ROM.

@Andre: I probably didn’t explain it well enough – but I think the best way to explain is with drawings + explanation, which I’ll try and do a bit later (there’s also something I want to have a quick look at beforehand).

@David: That’s basically the approach I want to look at.

@Stefan: I think that getting SharedSound to support 24-bit and 32-bit in the future, and it seems like this is something that is desired sooner, rather than later…

We need to implement something that is future proof and we don’t need to care for homemade apps that have been programmed 30 years ago that nobody uses anymore. We cannot care for programs that 10 people use and neglect the need of the future 10 million RISC OS users.

I have been reading this thread with some interest.

Stefan, I am somewhat concerned by your attitude here, we still have many users using older machines and software, why should they stop using them, because you could not care less about them. Plus we will not have 10 million RISC OS users. You are dreaming. Please come in to the real world. I really hope this is not how you are going to do your kickstarter campaign by putting off potential supporters with comments like hide things from your girl friends and wife you mentioned in another thread which is very sexist. If you are promoting things, and these comments above about not bothering with older programs.

There is mention of the USB drivers, there is already a bounty for this and for it to be based on the BSD USB drivers, support that work rather then what seems a scatter gun approach you seem to be promoting.

You are really putting me off Cloverleaf.

we still have many users using older machines and software, why should they stop using them,

I think it is a fine balancing act to ensure that the OS moves forward and supports modern standards and depreciating older set ups.

If changes can be done in a considered way,which Jason is setting out, then fine as it the best way for all but if it is not something that that can be done then equally supporting newer features on newer hardware/software may be the only option.

You may say that stops older machines being used but where do you draw the line A305 era, A5000 era, RiscPc era, Iyonix era..

As far as I see it we should leave the 26 bit era machines, dare say Iyonix, where they are now and concentrate on more modern machines and therefore nothing is broken it just means you don’t get the benefit but you don’t lose anything you have now.

If new programs take advantage then you have to have a newer machine.

As to language then all I would say is I can’t put many sentances or words together in anything other than English so if I said it then that is another thing and being inclusive we should look to help where we can in putting a context around something we may take for granted.