Audio Recording API

A couple of extra spanners to throw in the works:

• RISC OS 5 still supports RiscPCs which lack 16 bit audio, so some consideration is needed for how to handle those. Perhaps just “make the IOMD ROM keep using the old audio system”.
• I’m not seeing any obvious mention of surround sound / many-channel output. There’s no need to implement support for it now, but I think you at least need to consider what the API impact will be, so that you can try and make sure any new APIs can be cleanly extended to support it.

A couple of corrections:

• The SWIs that were introduced to allow selection of audio device were Sound_SelectDefaultController, Sound_EnumerateControllers, and Sound_ControllerInfo (you’ve got them listed as SelectDefaultDevice, EnumerateDevices, DeviceInfo). “Device” was the original name used for the SWIs, but then it was changed to “Controller” because “Device” was felt to be a bit too generic.
• Sound_ReadSysInfo and *Audio received extensions to add support for device selection; your wording makes them sound like they were completely new additions

This is the thread where the device selection extensions were discussed: https://www.riscosopen.org/forum/forums/3/topics/3727. On page 2 is a note that device IDs are “based on the GraphicsV device ID convention (which in turn I think I based off of ROL’s VideoV device ID convention).” The intention being that if/when the system was extended to support audio devices which aren’t implemented as HAL devices, we could have device IDs like “USBAudio#abcd_1234”.

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

They shouldn’t, if they feel happy with them. However, they should also understand that the world is moving forwards and it is they who are not.

An alternative way to look at this is that we have (potentially many more) users with new machines, why should they be held back by people who don’t want to progress beyond their friendly quarter-century-old hardware?

It can be quite a frustrating experience, looking at an API that does what you want nicely, and understanding that using it means that somebody somewhere is probably going to take it personally that their Mesolithic machine is no longer supported. An example I used just the other day is TaskManager_StartTask that is a simple way to queue a command until we’re back in the Desktop world. But, alas, anybody running an actual Acorn version of RISC OS will find that doesn’t work, as it was introduced with the 3.80 build. 3.71, for example, dates from February 1997.

I understand that when you’re writing commercial software, it’s a very peculiar set of circumstances where failure to support these ancient piles of tumbleweed can translate into potential lost sales, however when we’re talking about extensions and additions to the operating system and future heavyweight apps (such as modern browsers), then it’s a flat No. The minimum that anybody should consider then is the Beagleboard (I skip the Iyonix because it has no hardware FP).
To put this into context, I just ran a test program that I have here. Four million multiplications using FPE, two hundred and two centiseconds. Four million multiplications using VFP, three centiseconds. I rest my case.

There is mention of the USB drivers, there is already a bounty for this.

From my point of view updating netbsd drivers won’t achieve anything – outdated netbsd drivers has not been a limiting factor. The problem is the RISC OS USB api is not low level enough. If the RISC OS api was even a subset of the Net bsd api we could have had USB Audio years ago – and a better quality one – as it would not have been dependent on ROOL deciding to add features to its USB api or its implementation.

@Chris Hughes:
1. Sorry I will not try to joke around anymore and put some people off. (related to girlfriends and wives). Valid comment!

2. Yes if you want to keep RISC OS how it is now then there will not be 10 Million new RISC OS users. But if you want to use what you have now then you just use what exists now and can be happy the next 100 years with it. If you want improvement then there is no way around to change some stuff even it might not be compatible with hardware that is 30 years old.

3. I have nothing to do with the USB drivers (yet).

4. If someone has examples of software that will not work anymore with our approach then we can discuss how to solve it. That is why we dicuss it here. And there is 2 ways to solve it: a) chnage our solution or adopt the old software for the new requirement.

5. I cannot promote an outdated operating system with no full browser, no WIFI support, no USB 3 support, no NMVe support.

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

I am not disputting we need to move forward, but there are more RISC OS 4 users then 5 users out there.

I was objecting to Stefan comments about lets just forget the users on older machines with some older software they want to use with Sound. They could be potential investors in Cloverleaf, but might be put off by Stefan comments.

His 10 million RISC OS users is a dream. If he is going to do a kickstarter, then he need to be more realistic. I have yet to see anything that clarify what he is proposing apart from a seemingly Scatter gun approach to things.

From my point of view updating netbsd drivers won’t achieve anything – outdated netbsd drivers has not been a limiting factor. The problem is the RISC OS USB api is not low level enough. If the RISC OS api was even a subset of the Net bsd api we could have had USB Audio years ago – and a better quality one – as it would not have been dependent on ROOL deciding to add features to its USB api or its implementation.

Colin the ROOL bounty is for the NetBSD USb stack to be made part of the OS.
I quote:
Feed-back any modifications/deviations to the NetBSD team (for example, fixes to isochronous support in the host controller device drivers)
Integration of the latest revision of the NetBSD sources
If deemed sufficiently mature, this could include USB3 support
Finish off the CDC driver in EtherUSB so that any communications class devices will work

nothing is broken it just means you don’t get the benefit but you don’t lose anything you have now.

This is an important point – you won’t get all the goodies of what’s being created now, but that won’t make what you have magically cease working.
Old software will still keep going on an old machine. New software… perhaps won’t.

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

Which is not that onerous, really.

Some sort of Pi? About €35.
Decent USB power pack? About €15 for a multi-output one.
USB cable? €4 You’ll want a decent one.
Keyboard? €10. It’s RISC OS, you don’t want a fancy one.
Mouse? €5. Ditto.
Monitor? Not necessary, you can recycle what you have.
HDMI to VGA adaptor? About €10.
SD card? €5.
WiFi adaptor (Vonets) or ethernet lead? €15/€5

Total for a Pi setup with Vonets that will blow an old RiscPC out of the water? €99. Which is less than ArtWorks or OvtionPro, and infinitely less than the cost of ARM hardware “back in the day”. Hell, the extra memory card for my A3000 cost more than that! And we shaln’t talk about the price of harddiscs…

You can possibly shave off a fair few pounds here and there. USB lead? Recycle one from a mobile phone (I did). Keyboard and mouse? Pinch ‘em from an older computer that has USB hardware. My keyboard is a new part, brought over from the UK so it’s a proper British layout (with strict instructions to find the cheapest most basic keyboard available as complications can upset RISC OS). The mouse? Rescued from a bin at work (frayed/broken cable at the mouse end) and repaired and cleaned. You probably have a µSD card kicking around, especially if you have an Android phone and realise that your 8GiB card isn’t quite big enough… so you put in a 16/32 leaving the 8 for… well… RISC OS! :-) The video adaptor? Prices range from a fiver to fifty quid. So you can definitely pay less. You can also pay more. However given the current draw on these things, it’s best to either hack in a USB supply (as I did) or buy one with it’s own power lead. Don’t try to draw 200mA from the HDMI port, your hardware won’t thank you for it.
My 1280×1024 flat screen monitor? €10 from a boot sale. And the 1440×900 one used on the PC? It has a blemish on the front, so I got it for €3! Another €10 later, there’s a spare flat panel in the shed. The world has gone digital, so you can pick up VGA-only LCD screens for pocket change these days. And with the Pi and a VGA adaptor it’s a rock solid stable non-jittery picture running at 75Hz (Pi) or 60Hz (PC).

As to language then all I would say is

It may also be a cultural thing. My general impression is that Germans tend to like to be fairly direct, while a lot of English prefer to “beat around the bush” and use metaphors and other suggestions. Neither is good or bad (I’d much rather be directly be told “you suck” if the person saying it had a good reason to back it up), but put the two different approaches together, it could lead to misunderstandings.

But, yeah, the girlfriend comment is about thirty years late.

I cannot promote an outdated operating system with no full browser, no WIFI support, no USB 3 support, no NMVe support.

Iris is already on its way, Wi-Fi work is already part of a bounty and separately work for the ARMBook Wi-fi is on its way as well. USB 3 support comes from the USB bounty,- its reached its target but no takers to do the work it appears, and also will help with Audio plans. No interest in NVMe.

Far more important is multi-core support. A more modern UI and critical support for Samba v2 and v3. Improved security of the OS.

there are more RISC OS 4 users then 5 users out there.

Well if we keep playing to the same audience then at least we may have the pleasure of there still being more 4 than 5 users but when it is only three of us in total alive then thats not viable.

I suggest that current thinking has locked us in to an ever decreasing downward spiral of fewer users.

We have a chance to escape it and I am confident given some old and new faces coming in but we must move forwards and supporting 20 year hardware and 15 plus year old OS’s that are not being developed is not the way to increasing the base.

If someone is happy with their old system then fine but don’t stop development of newer solutions, just stay where you are and nothing breaks for you.

I guess they have already made that decision anyway by using old hardware etc.

we could have device IDs like “USBAudio#abcd_1234”.

At the moment I’m thinking that it would be better to use a hash as a device id. Then you could create the hash dependent on the information you have eg a usb device with a serial number could hash the serial number and device type eg “USB” with the device descriptors. Without a serial number you could hash the device location instead.

I think I’ve hijacked Jason’s worthy thread enough.

USB 3 support comes from the USB bounty,- its reached its target but no takers to do the work it appears,

As a contributor to a number of bounties I understand the risks in that you can have as much money there as you want but if you can’t get someone interested in doing the work then it doesn’t matter what your priorities are.

So if Jason is willing to improve the Audio set up then great that can be done now and the USB elements may wait until as long as the API spec is clear to start with and the road map elments clearly defined.

I get the sense this is turning in to another one camp verse the other for some so lets not go down that destructive route again and rejoice in that there are multiple parties wanting to develop RISC OS again.

there will not be 10 Million new RISC OS users.

There will not EVER be 10 million RISC OS users. Even in Acorn’s heyday, of the BBC Micro, 1.5 million were sold (Acorn anticipated 12,000 to be sold). And when you consider a lot of those were multiple units sold to schools…

As for the 32 bit range: https://www.riscosopen.org/forum/forums/11/topics/14754

Ten hundred would be good.
Ten thousand would be incredible.
Ten million is a fantasy right up there alongside Brexit.

and can be happy the next 100 years with it.

Unlikely. Either the hardware will eventually fail and cease working, or the owner will.

As to language then all I would say is I can’t put many sentances or words together in anything other than English

Oops, “sentences” :)

Reading with interest, one thought though:

RISC OS 5 still supports RiscPCs which lack 16 bit audio, so some consideration is needed for how to handle those. Perhaps just “make the IOMD ROM keep using the old audio system”

That reminds me that we have an emulated RPC instance to think about.
How much work is required on the RPCEmu side and how much on the OS sound support to enable use of the host system sound devices?

this is turning in to another one camp verse the other

That’s logical. This is a forum. On the Internet. Everybody has an opinion. ;-)

Ultimately, what it comes down to is what the person who is offering to do the actual coding is willing to do. There are some good ideas (like Jeffrey’s “don’t forget multi channel audio”) and there are dozens of suggestions and comments. But unless anybody wants to offer to join in with the development, they will remain just that – suggestions and comments that can either be considered, or not, by the person actually designing and implementing the new system.

Colin the ROOL bounty is for the NetBSD USb stack to be made part of the OS.

Chris. Always was, but the only access to its api is in USBDriver or the module backends. The latest version of the drivers has code which can’t be compiled with norcroft – unions without names for example. So I see little point in messing with the latest sources from NetBSD until we can compile those. But as I say I don’t see updating the NetBSD code we have no will do anything for us – well for me anyway.

Oops, “sentences” :)

Thus proving what I said about use /translation etc :-)

How much work is required on the RPCEmu side and how much on the OS sound support to enable use of the host system sound devices?

Just leave IOMD, be it real or emulated, where it is the same and no clouding of the issue then.

Iris is already on its way

And does that not exclude certain users with older machines so sort of makes makes the point.

Just a generic comment: don’t get bogged down in all the gory details of both backward compatibility and future-proofness. It would be the first time in history where the initial ideas and first implementation would be good for all possible target scenarios.

Take support for original Risc PC 8bit sound hardware as an example. I agree that it would be a good thing to have that base covered. But now count the number of people who have not upgraded their Risc PC with 16bit sound (I think it was a 30 pound upgrade back then), AND want to run RISC OS 5 in its latest incarnation on their hardware. More than 5 users? I’ll sponsor them their 16bit upgrade (I guess I should have at least 3 at home in old machines) and we’ve solved that problem neatly without investing any more precious time on that specific problem.

Take support for 24bit sound output as another example. While there might be a slight possibility for future applications running on RISC OS for advanced sound processing needing internal high resolution representations of intermediate samples, I fail to see the use case for the final output of more than 16bit sample width. With the possible exception of mixing together several audio streams of course…that’s not to say that bigger sample width should not be kept in mind when designing an API, but is it necessary to aim for a complete solution in the forseeable future?

Of course I don’t want to stop Jason from implementing the complete solution to all things in the next few days :-)

So if Jason is willing to improve the Audio set up then great that can be done now and the USB elements may wait until as long as the API spec is clear to start with and the road map elments clearly defined.

I totally agree with this way forward that is being suggested. That was not really my concern here.

I get the sense this is turning in to another one camp verse the other for some so lets not go down that destructive route again and rejoice in that there are multiple parties wanting to develop RISC OS again.

It has nothing to do with one camp verse the other. I am saying repeatedly that Stefan has posting pie in the sky statements in this and other threads. for instance 10 million RISC OS users – rubbish, it will never happen, regardless of some of the planned developments. Another instance is ignore those who have chosen not to upgrade for various reasons,fine if you don’t want potential customer to buy newer kit. Sorry but I know some will not upgrade because they find RISC OS 5 still dated compared with some of the things in 4.39 or 6. This is fact.

I am not saying and nevr have that we should not more forwards but we need to ensure the few remaining commercial suppliers can continue in business since they are also funding in some cases those developments.

Iris is already on its way

And does that not exclude certain users with older machines so sort of makes makes the point.

Yes it does, but they will hopefully still have !NetSurf, assuming it carries on being supporedt for RISC OS, which I hope it does.

But you skipped over the point, I was responding directly to Stefan comments about he cannot promote the OS without XYZ. Nothing else.

Sorry but I know some will not upgrade because they find RISC OS 5 still dated compared with some of the things in 4.39 or 6. This is fact.

Also a repeat, but need to have a list of what RO5 does not have that RO4.39/6 does to provide a list of targets for updates of RO5.

Perhaps someone could put together a table of features for both. Previously it just came down to list one post and then a different list in another.

Also a repeat, but need to have a list of what RO5 does not have that RO4.39/6 does to provide a list of targets for updates of RO5.

This has been done at least twice that I can remember and all the response we get is, round buttons who cares seemingly from the anti ROL brigade, so we still have an outdated UI in 5, and still fixing bugs in the OS that were fixed years ago in 4.39 and 6

To be honest if I was able to get RISC OS 6 on my current computer instead of some of the mostly small improvements in 5 I would use 6 in preference, simply because 5 keeps just keeps reinventing the wheel because of the wars and still has missing features – some more useful then others I agree.

Okay – I missed these (been working instead :))

@Jeffrey: Thanks for the corrections. I was learning a lot about the changes since I’d last done any work in the area, and I thought I’d got them all, but obviously not. I’ll uplift it.

@Anyone who wants to discuss how may users there are likely to be: Can we keep this elsewhere?

(btw, still not used to this forum formatting)

Regarding USB and devices with more than two channels – as I’ve mentioned, this isn’t something I’m going to delve in for the moment.

S/PDIF supports multiple channels by compressing the audio; I think this is how most systems would do it anyway. But the compressions should be done by SoundDMA/SharedSound (sound source providers really should not know about this). I would probably propose a plugin system for doing this, so modules can provide encodings for audio samples. I’m writing up my thoughts on the issues of SharedSound as a new document, and I think I’ll include them in there.

Note that you can have multiple I2S interfaces, and have each one going to a different DAC.

And regarding backwards compatibility – this requires a bit of a shift in the SoundDMA<>HAL interaction, so if the HAL for a particular piece of hardware is being maintained, then it should work with the necessary updates.

Otherwise – don’t load the new version? It should still load, but nothing will register any hardware, so will not be doing a huge amount…

but there are more RISC OS 4 users then 5

That’s a very valid reason not to break things.
But if it happens, RISC OS 4 users certainly have more developers than RISC OS 5 users, and so will help to fix the code :)

There will not EVER be 10 million RISC OS users.

Even with Pace STB? ;)

rubbish, it will never happen

Tell that to Linux developers 10 years before Android.

Nobody knows what will happen. Perhaps that the new DPBasicERP announced by Thomas will be incredibly popular in the German SOHO market. Perhaps that retrocomputing will become the game of the year. And perhaps RISC OS will just disappear tomorrow. Who cares?

about he cannot promote the OS without XYZ

In fact he can. But we can disagree and promote it another way.

I will probably buy the big computer of Cloverleaf. But that will not stop me using my superb A410. The same A410 where no modern software works. But fitted with a SSD… thanks to some modern dev. Anyway, I’m not shocked by the fact that ChatCube does not work on this computer :)

CSAAdvocacy

Sorry but I know some will not upgrade because they find RISC OS 5 still dated compared with some of the things in 4.39 or 6.

All academic as 4.39/6 are not being developed anymore and I agree some things are nicer but really a lot is now gloss over things that have not been updated for years.

The thing is we are where are and we need to get new users to the OS as we are a deminishing pool and with out new blood the end is sadly in sight , reminds me about the phrase “Whilst Rome burns”.

Yes try and keep older users if possible but many have made the decision to stay where they are and I am not entirely sure they would move even if you gave them everything they wanted as they now have the ability to run older software under emulation or via Aemulor, with a few exceptions, and still they stay with old hardware.

Lets move forward and embrace the future rather than looking back through rose tinted glasses that time often distorts.

After all if people didn’t move forward then we wouldn’t have the Internet/Zoom/Twitter/Instagram…

@Anyone who wants to discuss how may users there are likely to be: Can we keep this elsewhere?

Good idea and sorry for being one of those who caused the issue.