Audio Recording API

I was just writing down my thoughts.

I think my thoughts are academic anyway.

An mp3 decoder couldn’t be done like that and multitask. Its inclusion would have to be at the application end of a long buffer capable of surviving the period between callbacks (os_callbacks) or wimp polls. I can’t see anything happening in an interrupt context other than the device emptying or filling a large buffer a chunk at a time. You can close couple a decoder to a mixer at the application end but the final stage to the output/input device will always be a long buffer.

paragraph not line.

OK. :-) Thanks.

then you need to do some measurements based on suitable waveforms.

Oh, I think waveforms are only really useful for making pretty charts to prove whatever point the author wishes to make in magazines/websites. ;-)

Musical performances pass through three immutable filters. The first is the microphone. There is no such thing as a perfect microphone that records exactly as the sound is. And even if such a thing was invented, putting microphones in the performance is not the same as sitting in the audience listening to the performance.

The second is the mixing/authoring employed. This was very prevalent during the loudness wars that ruined many a CD album, but then again it still has effect now. I mention in my review of the previous Nightwish album that the mixing seemed a little bass heavy.

And finally, the important one. Hearing as psychoacoustic. That means we don’t “hear” so much as “perceive sounds”. This is very important because I would rather imagine that if you and I both had a soundproof room, speakers, amplifiers, and the suitable waveforms, there’s a pretty good chance that we’d set things up differently.

So the best test isn’t waveforms, but rather the sorts of music that you actually intend to listen to. If that sounds good to you, then job done.

I doubt I’d use YouTube as a source for high fidelity reordings.

No, of course not. Better to get the CD and have raw uncompressed sound. ;-)

But YouTube suffices for the purpose of this example. Oh, and that’s why I picked that specific Gershwin performance; older ones of the 240p/360p era have poor quality audio.

paragraph not line.

OK. :-) Thanks.

Plus the above style, utilising HTML style markup of < blockquote > and of course the terminating version < / blockquote> so you can produce nested quotes.

Remove the spaces I put in to break the markup…

Oh, I think waveforms are only really useful for making pretty charts to prove whatever point the author wishes to make in magazines/websites. ;-)

…snipped assertions. :-)

So the best test isn’t waveforms, but rather the sorts of music that you actually intend to listen to. If that sounds good to you, then job done.

That’s fine if all you want to do is assemble a system for one person in one room for some specific types of music as they sit in one place, etc. It will also depend on your choice of specific items you played.

But it isn’t enough if you want something you could make, or explain to anyone else, or find was Ok when you changed any of the significant variables. And may then ‘condition’ your taste in music because from them on you prefer things that ‘suit’ your setup and miss things you’ve have enjoyed more if you’d got a more sorted system.

To know what’s going on, I’m afraid those pesky waveforms and analysis tend to come into it. Particularly for speakers and room interactions. Hence why the makers of kit do a lot of that as well as listen a lot – including to material that doesn’t ‘sound right’ to try and decide where the ‘blame’ may lay. :-)

So, what you wrote is fine in itself, but may not help when the result doesn’t sound right because you then have to find out what the actual problem may be. Retailers like your approach, though. It helps them infect people with ‘upgradeitis’. 8-]

Using blockquote markup does make more sense. The pity is that the only other web forum I use has a ‘reply’ facility that automates that. So it will setup the quote for you. (used square braces rather than angled though.) On this site even grabbing text with a mouse drag seems awkward at times. Is that just me?

Is that just me?

Well, your browser and/or OS, yes, I guess so. Never any bother here (Firefox on MacOS).

NetSurf 3.10 with JS off is what I tend to use on RO most of the time.
RO 5.23 (as per ARMX6)

NetSurf 3.10 with JS off is what I tend to use on RO most of the time.?RO 5.23 (as per ARMX6)

Just tried with a different bowser. Not so convenient but selecting for copy and paste seems easier, although the display is poorer so far as my eyes are concerned!

RO 5.23 (as per ARMX6)

Jim I take it you know that the ARMX6 is currently on 5.27 (30 Jun 2020), the download is available from the ARMX6 download site. Lots of fixes and improvement since 5.23

Sorry for interupting Audio discussion.

Maybe I am missing something, but the only ones like that I can see are labelled as ‘beta’.

Maybe I am missing something, but the only ones like that I can see are labelled as ‘beta’.

Odd numbered versions of the OS are “beta” (at best). 5.27 is “beta”. So is 5.23. If you want “non-beta”, you need 5.24, 5.26 or the not-yet-released 5.28.

I’m not certain we are talking about the same things. The files on the ‘R-Comp’ site aren’t named according to these 5.xx numbers. Are you talking about these?

Although I used to routinely try out betas in order to help development, in recent years I have tended to let others be ‘first into the field’ if they system I have is working OK. However I do try ‘betas’ if there is a reason. e.g. IIRC when support for USB Audio was added I tried that early on to check and give any feedback.

Otherwise I wait until it is clear that the ‘beta’ lable has been removed or a new release is not an ‘alpha’ or ‘beta’ but the recommended version for all users. And as per the above, so far as I can see, the files on Andrew’s site later than mine are all explicitly labelled as ‘beta’.

FWIW I’ve asked about this on the relevant email list as well, so hope for some clarification.

I’m not certain we are talking about the same things. The files on the ‘R-Comp’ site aren’t named according to these 5.xx numbers. Are you talking about these?

yes, the current one is OS16beta – 5.27 (30 Jun 2020)

You do realise that the installer provide with each update allows you to roll-back to your previous OS version easily? I suspect you will find a large number of ARMX6/Mini-M users will have updated to the latest OS16beta.

But as Steve Fryatt has pointed out odd number versions are all beta including your 5.23, the next stable version is intended to 5.28 (even number versions). But you will find that due to a couple of features ROOL have decided not to include in the default builds, we might not get a 5.28 version for the ARMX6. I am using OS16Beta and have been since it came out without issue.

But you will find that due to a couple of features ROOL have decided not to include in the default builds, we might not get a 5.28 version for the ARMX6.

If you look at the Downloads there is a traffic light system of marking which shows the state of compliance of each port with respect to specific elements of OS, drivers and documentation. The specific status of the various ports is covered on the Stable Release Status page.

Essentially, if Andrew has time¹ to update the specified failing elements then full stable status will be given. How much the lack of a designated stable status affects users is probably debatable.
From various user comments, the answer is probably “very little”

¹ So many things to do, so few people – maybe that’s the RO motto?

If you look at the Downloads there is a traffic light system of marking which shows the state of compliance of each port with respect to specific elements of OS, drivers and documentation.

Yes. It shows a ‘red LED’ for the iMX6. And when I look at the R-Comp files for their OS downloads the files for 2020 are all marked ‘beta’.

But I’m being told this doesn’t matter. Which leave me with the puzzle I’ve just pointed out on the ARMX6 list.

They are all called ‘beta’ but told they are fine.

There is a risk that ROOL things may be muddled with Andrew’s releases here. But for me the basic puzzle is the apparent situation where all the recent OS versions on offer are either ‘red LED’ here or ‘beta’ from Andrew. Yet apparently we can ignore this and treat them as fine.

So I’m confused by all the versions being beta but Ok, regardless of time and events since their release. What is the point of all versions having a ‘permanent beta’ label. Is not the point of ‘alpha’ and ‘beta’ labels to indicate some level of caution because something is ‘pre release’ in terms of being the standard stable version, or to be tried with some caution?

I appreciate the ‘things to do’ point well enough, so apologies if this looks like a moan or attack. That’s not my intent! But I am trying to explain that perhaps I have been confused because this is confusing!

Hi Jim,

You are conflating two things , one being the ROOL builds and the second the RComp supported builds for their product.

So we have ROOL release and beta versions of the OS for various systems including the iMX6 board and RComp take snap shots of those and build in their elements and provide a their own Beta and Release versions for their ARMX6 product.

The ARMX6 is a RComp turnkey provided system so you should, unless you want to install non RComp supported OS versions, just concentrate on the RComp builds as supplied by them.

RComp supply Beta snap shots of their OS build and OS releases with OS12 being the last one.

The current RComp Beta is as Chris has pointed out ARMX6_OS16beta which everntually will either be superceeded by another Beta or move in to the Release phase.

To you as the end user of a Rcomp machine all that is important is what versions RComp support.

If you either do build your own ROM , from the ROOL sources, or install a ROOL ROM on a RComp supplied machine then that is your choice but it then is not a RComp supported option.

So if you want to update from your last RComp supported ROM version then install ARMX6_OS12.

If you want to try the latest RComp Beta then try ARMX6_OS16beta

The Service Packs are the hard disc updates with ARMX6_12a.zip bveing the latest release of that.

Hope that helps.

Updated: Forgot to add lets not take this thread in another direction and if you wish to further debate it then I suggest a new thread or continue on the RComp group.

So if you want to update from your last RComp supported ROM version then install ARMX6_OS12.

If you want to try the latest RComp Beta then try ARMX6_OS16beta

The Service Packs are the hard disc updates with ARMX6_12a.zip bveing the latest release of that.

Thanks, Doug. That cuts though the confusion of the 5.xx comments, etc, and establishes the expected difference between a beta and a stable release. :-)

I started off on the basis of assuming the RComp and ROOL versions were different, but the replies then made the confusion worse. I’ll take any more on this elsewhere so people can get back to audio. :-)

@Jason Tribbeck

Did you manage to get everything you need to finalize what you hopefully still intend to develop for the RISC OS Community? Or are you waiting on more feedback or comments on specific aspects of your design document?

@Stefan Fröhling

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

Having been away for a long time, I just found this thread today, and I think this is absolutely and totally awesome, both the development of a new sound system, as well as the release of the RDSP.

Besides software development and RISC OS, I have a fondness of synthesisers.

I’m very much a beginner when it comes to playing music, but I’m fascinated by synthesisers and how they work, and have been studying in particular different synthesis engines.

Thus, I’m extremely delighted by these recent developments in RISC OS, enabling me to combine two of my highest interests, computers and music.

Speaking of that, does anyone have any experience with using MIDI on RISC OS these days, i.e. on modern hardware, and are there any applications supporting MIDI?

I’m not sure if Jason Tribbeck follows this thread, anymore, but if someone is in contact with him, please give my regards and a big thank you for his ongoing work, and of course to the author of RDSP, which I understand is Anthony Vaughan Bartram, as well as to Stefan for getting the ball rolling and keeping it rolling.

Hi Terje! You may have missed the video of Jason’s audio talk at ROUGOL – https://youtu.be/F-PhWFiKitk

Hi Terje! You may have missed the video of Jason’s audio talk at ROUGOL – https://youtu.be/F-PhWFiKitk

Nope, I just watched it today. It was part of my inspiration for my post, but thanks for the link in any case. :)

With regard to MIDI support, I found a couple of threads which I’ve read:

https://www.riscosopen.org/forum/forums/3/topics/13918
https://www.riscosopen.org/forum/forums/11/topics/1651

Does anyone know of any MIDI sequencer application working on RISC OS 5, such as Anthem or MeliDI?

I guess they might need rewriting due to changed or new MIDI modules.

In case it helps anyone interested in recording who has missed this elsewhere:

The Focusrite 2i2 (all three versions) work fine for audio capture with a RO system that includes the USB Audio support. Indeed, despite the makers insisting otherwise it works at all sample rates up to 192k/24bit. And gives excellent results.

I suspect their devices with more inputs and output may also work. But I don’t have one to try. So if anyone has, and can check, please see the thread I’ve started elsewhere or let me know here!

I have a Focusrite 6i6 and have some problems using
the latest IsocUSB modules. Being multichannel, the
6i6 appears to send a 6-channel USB signal to the
Beagleboard XM. I have written a program to select
two of these channels, thus creating a normal stereo wave file from the 6-channel wave file created by IsocRecorder. However, at random intervals, the stereo image jumps from ch1-2 to ch3-4 to ch5-6 then back again to ch1-2. I have analysed the IsocUSB wave file and the problem seems to be in the IsocRecorder or IsocUSB software, as though samples are being lost due to some other interrupt occupying the processor.
I can supply further information and files, if it will help.

You can send me what you have – address on my ftpc site and I’ll see what I can do.

Presumably you modified the basic usbrecorder to record 6 channel audio instead of stereo. I think the most likely problem is the speed of the beagleboard. 6 channel 4byte per channel audio 96k+ is a lot of data and riscos doesn’t have the fastest filing systems and it may be that you are not saving fast enough which would cause buffer overrun and data loss.

I don’t think it is related but the focusrite multichannel devices have some vendor specific descriptors so setting the samplerate may not work – I can’t remember how I did it is the sample isocrecorder program.