Audio Recording API

Further to my earlier post. Each Unit/Terminal has a control interface depending on its type, and a streaming interface that could be like this:

Unit streaming interface
------------------------------

This is the public interface to the unit/terminal streaming interface.

typedef struct
{
    _kernel_oserror* (*destroy)(output_context_t*));
    _kernel_oserror* (*bufferFilled)(output_context_t*, void* buffer, size_t numsamples);
    _kernel_oserror* (*setBuffer)(context, unsigned int format, size_t minimum_buffer_size);
}output_context_t;

_kernel_oserror *create_output_context(output_context_t* output_context, 
                                                  output_context_t** context_out);

output_context is the context of the output device the unit uses to call
the output unit interface


Output terminal streaming interface
-----------------------------------

The output terminal has the Unit streaming interface +

typedef _kernel_oserror *(*BufferFillFn)(output_context_t*, void * buffer,
                                                            size_t numsamples);

_kernel_oserror *registerFillFn(output_context* output_context, BufferFillFn fn, fn_context);

fn_context is the context used when the output terminal uses fn.

As this is a terminal output_context is NULL when creating


Input terminal streaming interface
-----------------------------------

_kernel_oserror *create(context_t** context);
void             destroy(context* context);
_kernel_oserror *getMinimumBufferSize(context, size_t* size);

the fill function can be either

_kernel_oserror *getFillFn(context*, BufferFillFn, output_context);

or

_kernel_oserror *fillBuffer(context, void *buffer, size_t numsamples);

The first allows the Input terminal to handle calling bufferFilled after you registered the returned function with the output terminal.

The second allows you to register a function with the output terminal yourself and you call fillBuffer to get the buffer filled and then call buffer filled on the first output context.

Rick, if you look the page of my own wrt bitfreezing, and the two other ‘MQA prompted’ ones it relates to, then you’ll see that I agree entirely that in general 24 bit is needless for playback. However:

A) This thread is about recording not just playback.

B) Some end-recordings may well have a noise floor, etc, below the 16th bit.
Although FWIW I think it makes more sense to use 96k/16 noise shaped here as it fits real recordings better in terms of avoiding the ‘noise sea’.

C) As per (B) the range humans hear tends to need a few more bits than 16. 18 to 20 tends to be nominally ideal with a flat NPSD for the noise /dither level.

As I pointed out, my ADC (cheap and basic in studio terms) has a range about 25dB better than 16bit even when operating wideband at 192k. Studio kit will be better.

So if I want to fully use my ADC I capture 24bit.

In practice it is also and wise to ‘under record’ because when capturing live sound you need to allow a lot of headroom to avoid an unexpectedly large peak clipping your recording. Also useful when you come to then mix.

So people record 24 bit with a lot of headroom. Then scale up after processing is done. The result then often fits into (properly noise shaped and dithered) 16bit. But not always.

And people do buy DACs for home use from Benchmark, etc, as well. (Ahem…)
:-)

So the reality is that people will want to use 24 bit. Even though they often don’t really need to. And that sometimes, they do need it.

BTW The page you referenced is a bit odd as dBs are always relative but it doesn’t make this clear. Nor that human hearing depends on the complex details. Not the old ‘single sinewave tone’ plots. Work on human hearing has moved on a bit.

Note also that the ‘background noise level’ in a room as quoted is the total power, spread across the range of frequencies. Human hearing can easily hear a tone of lower power than the wideband noise floor because the hearing can detect there being more power in that specific frequency ‘bin’.

BTW you may find archimago’s writings on high rez, etc, of interest as well.

BTW2: Sorry, I think my ‘Liz Dexia’ is getting worse as I’m spending more time that I used to playing ‘spot the typo’ in what I write! :-/

Everyone should note that for recording and playback “home” use might not be as loose a requirement as first assumed.

Beyond people like Jim, doing whatever he does, there are “home” recording people like Steve Hackett¹ although he isn’t a RO user AFAIK (I suppose I could get the wife to ask on the link she seems to have) but that’s a pretty “professional” level “home” use so the lines tend to blur a lot these days.

¹ If you don’t recognise the name then I suppose I could give a clue or two.

might not be as loose a requirement as first assumed.

Oh, I think we ought to aim for the best API possible (get it right first time, sort of thing), though when it comes to “professional” use, I would wonder if anybody would be using RISC OS for that? I mean, do we even have “home studio” type software? Something like https://www.avid.com/pro-tools/comparison

I mean, do we even have “home studio” type software?

Exactly how useful would it be to attempt any such software application with no suitable OS support?
Which I think brings us back to the driver for a new full featured API and OS support built to match.

Which I think brings us back to the driver for a new full featured API and OS support built to match.

Or, at least, an API which allows fully-featured OS support to be implemented in the future without having to change that API.

Or, at least, an API which allows fully-featured OS support to be implemented in the future without having to change that API.

A much clearer description of what I meant – well done on the distance mind reading. Distance undetermined, but it was a simple read :)

As context: FWIW my own ‘home recording’ is of two kinds.

1) Making digital transcrptions of old LPs, tapes, etc. This lets me clean up flaws and play the result more conveniently. i.e. what loads of people do. It seems common enough. Indeed, some of the inexpensive turntables people buy now have a USB output! Although I do captures at 96k/24 for reasons explained earlier. (Also makes ‘repairs’ of clicks, etc, work better.)

2) Use an ADC and a DAC to do test measurements. e.g. recently did measurements to develop a ‘wow and flutter’ program for people to use to check their turntables. Thus others can also check using this, given the ability to make a good ADC capture. Not something most people will do, but audio ‘enthusiasts’ are often paranoid about kit, and will find this sort of use handy as reassurance.(1)

The second would benefit from being able to operate a DAC and an ADC ‘symultaneously’ with locked timing. Makes for better ‘probe-response’ test measurements. But that isn’t essential for most things. And like (I guess) most people here, I do have, erm, more than one computer… 8-]

(1) I know of at least one maker, and one reviewer who uses this. But, alas, the Linux version. :-/ Given RO systems doing it, I could use it to raise awareness though.

Another point/question occurs to me to ask about here:

When the new system is in place am I correct in assuming it will work in ‘non multitasking’ mode as well as via the WIMP? I’ve assumed it will. Which might allow more use in places where people want a ‘test instrument’ or other single purpose ‘box’ not a ‘computer’.

I used to use my Iyonix as a test ‘box’ like this with a full screen scope/fft display. But alas with a crappy (in instrument terms) interface because of the hardware involved.

RiscPCs were also handy for this. That’s why someone came a long way to take mine. They got used underwater in the North Sea. 8-]

Being able to run 192k/24 DACs and ADCs can be used for more than audio.

This lets me clean up flaws

Yes, additions to help automate this are fairly common. One program (Nero Wave editor?) has tools that can spot the regular clicks of a scratch to remove them, plus a mask to learn what background noise (usually a low pitched rumble) sounds like, to subtract it from the recording.

turntables people buy now have a USB output!

Yes, either USB output or directly recording to MP3.
The thing that has stopped me from buying one is that I’m not interested in 128kbit encoding. I used to use that (one of my DVD players can rip CDs to USB stick) but these days it is 256kbit minimum. You can hear the difference in the liveliness of the recording – the lower the bitrate, the more it sounds like you’re listening to it with the speaker down in a well…

am I correct in assuming it will work in ‘non multitasking’ mode as well as via the WIMP?

Given the randomness of how the Wimp polls and the lack of guaranteed time slices, I would imagine that working in the Wimp will be the hard part, not the other way around. :-)

Given the randomness of how the Wimp polls and the lack of guaranteed time slices, I would imagine that working in the Wimp will be the hard part, not the other way around. :-)

Has anyone considered that this might be an instance of “let one of the other cores do the work” when more than one core is available?

Jeffrey following this by and able to comment on multi-core support for this kind of thing?

One of the big advantages for me through a series of machines from the ‘B’ → ‘master` → RPC on was the ability to write and run data/control programs than ran ’non WIMP’ so you got essentially the machine’s attention all the time. (1) Most dramatic example was a RPC that ran for about 3-4 weeks at a time for over a year, logging data from an instrument. I was able to write a relatively simple program for this as it didn’t need the WIMP or multitasking. People are so used to a desktop and multitasking that it is easy to overlook that for some purposes this ‘all the machine, all the time’ mode can be very handy!

(1) The breaks were to swap over a HD in a caddy because the disks would fill up. I’d then process the data from one HD as the next one was being filled. If we’d had bigger HDs at the time I’d have run it for longer between changeovers. The limiting factor was the discs, not the RPC.

so you got essentially the machine’s attention all the time.

Yes, one of the nice things about RISC OS is that one can say to most of the rest of the system “sod off, I’m busy”.

If you’re prepared to deal with banging hardware manually (which probably precludes the use of USB devices), you can even turn off interrupts to effectively have all of the attention of the processor.

logging data from an instrument. I was able to write a relatively simple program for this as it didn’t need the WIMP or multitasking.

Unless speed is essential or large amounts of data with exact timings, it’s not that big a deal to wrap a logger in some multitasking code, primarily so you can use the machine at the same time…

If you go to heyrick.ddns.net (base URL), you’ll see my current weather. It’s hot. That is a fairly simple BASIC program that talks (via serial port and WEIRD protocol) to a weather station. Every five minutes it retrieves the weather, records it, and builds the web page that you can see. It’s all multitasking so it can just run in the background. The hourglass has just popped up and counted to 100 (it multitasks in between stages, so it barely loads the system at all), so I know that the 19h25 update has just taken place. While I was writing this, and without requiring me to stop or wait.

The code is pretty rubbish. I keep meaning to rewrite it to be better, but what’s there has worked for over four years, so why prod it unnecessarily? ;-)

“let one of the other cores do the work”

I think the standard behaviour (from back when there was only one core) is to put stuff in a module that can run in the background async from whatever the Wimp is doing.
I’m guessing the recording API wouldbe similar, offering some sort of event or calling mechanism in order that something like a module can be called periodically to remove data from whatever buffer is used for the recording…

Being able to run 192k/24 DACs and ADCs can be used for more than audio.

It would be good if I could test speakers the way they do in the books.
A recent article (Feb PE) on building LS3/5A alikes is very specific with components but suggests using ’10cc’s song, I’m Not in Love, is a good test for tweeter level.
If the strummed tizzy miced-up electric guitar can be heard clearly on the left and the vocal isn’t too sibilant and spitty, the resistor value is correct.’
But getting back to testing gear, what would be the minimum quality microphone you would use for this type of test? A fine ADC would not be much use if the mic isn’t capable.

When I’m trying out new headphones, my go-to track is the guitar/instrumental version of Bana’s “Shell”. It only takes about ten seconds to know if the headphones will do justice to the sort of things I listen to…
https://www.youtube.com/watch?v=BHvffxKPBbs

An alternative, a rather nice rendition of a Pink Floyd song…
https://www.youtube.com/watch?v=fl8dbodGYUQ

For a more rounded test, and useful also for speakers, is Gershwin’s “Rhapsody in Blue”. Expect the tweeters to get a workout, and see if your speakers can cope with the sudden changes between subtle nuances of individual instruments followed a second later by the entire orchestra going for it. It’s also kind of fun…
https://www.youtube.com/watch?v=7-MJZJjJs4A

Sorry – been on a business trip, so just trying to pick through the list…

The ATX power supply spec specifies a maximum ripple of 50mV for the 5V supply (which will likely be what is present on the USB socket).
The AMS1117 voltage regulator, if dropping to 3.3V, has a regulation (5V input) of between 3 and 12mV.

Those values would only occur without any additional filtering afterwards. Stick in a few pi-filters and they’d be significanly less. Tune them for the frequencies that are occurring, and they’d be well below what you’re expecting.

Each Unit/Terminal has a control interface depending on its type, and a streaming interface that could be like this:

Understood – mostly. Not sure why you’ve got sometimes a pointer to a context, a context by itself, or an array of pointers to contexts. I’m hoping it’s just thrown together code, rather than there’s something I’m missing :)

It is pretty much the model I was looking at doing (I didn’t want to go down to this level yet until the fundamentals had been agreed).

The only thing I would say is that the way it’s structured (passing in num_samples as the size to fill), it sort of makes it harder to support compressed audio formats, since num_samples may not be the size of the data that can go into the buffer (especially if you have VBR formatted data).

I would opt to have the buffer size (in bytes), which is the maximum amount of data that can be put into the buffer. For LPCM, the number of samples would be trivial. For MPEG, this could be a few frames of data (and, when filled, the fill code says how much data it’s put into the buffer – or the end of the data pointer may be easier, as this falls out from LPCM automatically).

An alternative, a rather nice rendition of a Pink Floyd song…

Background white noise rather ruins that as a test.
Pleasant enough, but proves that it really does need to be guitar rather than keyboard.
“Saucer full of Secrets”¹ makes a good dynamic range test on speakers.

¹ The track, although Nick Mason’s band do tour² with a good rendition.

I’m hoping it’s just thrown together code,

Yes I was just writing down my thoughts.

The only thing I would say is that the way it’s structured (passing in num_samples as the size to fill), it sort of makes it harder to support compressed audio formats,

I now think it should be clusters not samples this is my current idea which illustrates how an mp3 decoder could work not totally convinced by the system but its my best to far. I have it in my head that the biggest problem is tying input to output which will only be possible with certain combinations of devices but I can’t explain the nag yet. Would be handy to try it out but can’t get at the usb packet level interface without doing it in USBDriver.

Various comments (apologies, I’ve forgotten how to quote!)

Audacity makes fixing clicks easy. I tend to use ‘sox’ to generate a highpass filtered copy and show that alongside the original. The filtering makes the clicks obvious and ‘signposts’ where the may otherwise be hiding from view. However I’m currently working on an ‘RIAA’ program that undoes RIAA correction. Pros may tend to make such ‘flat’ recordings as it makes declicking easier. Stops the click being ‘time smeared’. so you get a better repair.

You don’t need symultaneous ADC/DAC operations as you can use tricks like the one I wrote up for ‘Archive’ years ago and webpaged here

http://www.audiomisc.co.uk/ArchiveMagazine/22/Testing.html

Just think of replacing the ‘recorder’ or stereo ‘source’ with a machine + an ADC or DAC as appropriate. One stereo channel is used as a ‘reference’ so the capture has both ‘probe’ and ‘response’ to compare. This was a stepped sine. But you can use noise, impulses, whatever.

The stepped sine approach gives phase info as well as amplitude. But takes ages to run.

However, yes, having a machine that can use an ADC and DAC at the same time makes this a lot easier and simpler.

TBH I wouldn’t worry too much about ‘measurement grade’ for the mic when doing in-room measurements. The room scuds up the sound in a very location dependent way. And mics have very directionally varying behaviour. Plus most of the maker’s so-called plots are crap. So only expect to be able to find what alters when you alter the system being tested. Not absolute acuracy.

But yes, given symultaneous ADC and DAC, doing full analysis of items on a ‘pushbutton’ basis gets a lot easier. So is something I’d love to be able to do with a RO system. Indeed, I suspect I’d personally find that easier than when using ALSA/Linux!

Would it be worth looking at enhancing StudioSound to fit in with the new record and other sound improvements planned as the sources are available once sound improvements are implemented the we would have something that used it.

Various comments (apologies, I’ve forgotten how to quote!)

Start a line with bq. and a space, then the quoted line. Each new line in the quote needs another bq.

Gershwin’s “Rhapsody in Blue”. Expect the tweeters to get a workout, and see if your speakers can cope with the sudden changes between subtle nuances of individual instruments followed a second later by the entire orchestra going for it.

That certainly tested my hearing aids. Especially the right one, in the better ear, which distorts on the peaks.

Wow! No wonder I forgot about how to quote if it has to add the same thing at the start of every line!

Testing by listening to some ‘favourite music’ is useful as a step. But if you really want to check then you need to do some measurements based on suitable waveforms. A problem with listening is your ears vary with time, and what reaches them varies if you move your head even a small bit. Memory is also fallible and your hearing alters because you hear something.

TBH I doubt I’d use YouTube as a source for high fidelity reordings. You’d be better off using R3 concerts grabbed using get-iplayer. I’d suggest reference recordings but they use (spit) HDCD. Look on the web for the ‘2L’ label website. They have a lot of test files – some of which are remarkable recordings. (Avoid MQA, though, its a bad idea!)

http://www.2l.no/hires/

same thing at the start of every line!

paragraph not line.