Windowed Buffer Example

#1

Are there any examples of plugins (custom on factory) that use a windowed buffer of a live audio input?

a|x

#2

Depends on what you define as a windowed buffer. Every delay is practically a windowed buffer, isn't it?

#3

Maybe Library-> Factory-> Tutorials -> 22-overlap-add-shifter?

#4

I was thinking more of an object that fills a buffer, FIFO-style, but then takes a snapshot of the buffer at regular intervals, and analyses the snapshot, in a similar way to how an FFT analysis process might.

a|x

#5

I'll look at that one, thanks for the tip.

a|x

#6

The problem with processing this in the k-rate/s-rate domain is that it creates a large load every N samples. Ideally you'd have to spawn a separate thread that does the processing while the audio thread fills the buffer. That is not trivial to do.

Can you give some details on the use you have in mind? Maybe there is a simple solution.

#7

I was thinking I'd have to use a thread.

The idea is to try and implement LPC10 encoding of live input.

LPC10, as defined my Texas Instruments in the late 1970s works in 20ms frames. Off the top of my head that's roughly 60 K-Rate cycles to analyse a 20ms buffer filled during the previous 20ms period.

I have no real idea if this is possible on the Axoloti's MCU.

Looking at some example LPC encoding code, to my very much untutored eye, it looks relatively simple, but there's a lot of looping involved, so what looks like a few lines of code could potentially take up a large number of processor cycles.

I've been looking at


Which is a non-realtime OS X desktop application to convert audio to LPC10 pitch, energy and lattice filter coefficients.

a|x

#8

I'd also need to downsample to 8kHz as the encoder assumes that sample-rate.

I guess I'd record every 6th sample at S-Rate to a 160-element array, then trigger the encoding thread when the buffer is full (every 960 S-Rate cycles).

a|x

#9

That's obviously a very naive approach to sample-rate reduction.

Maybe it would be better to record the average of the last 6 samples..?

I'm in no way aiming for hi-fidelity sound here, so maybe naive is good :slight_smile:

a|x

#10

spectral/rfft is a good example for windowed buffers and separate threads.
Averaging 6 samples is quite odd, isn't it better to do the average on 8 (or 4) samples? In such case you would only have to bitshift instead of dividing, which is much more cost effective

#11

Good point. I don't know whether averaging like this is a better approach that just discarding 5 out of 6 samples, though.
What do you think?

a|x

#12

If you are after a lofi sound anyway, I'd start with the simple discard 5/6 samples approach and see what it sounds like. Its going to have a ton of aliasing, but hey, maybe that fits the style you're after. You can always replace that "algorithm" with something more advanced (windowed sinc, etc.).

#13

Discarding samples without band limiting will introduce aliasing if the signal contains frequencies over fs/2. An averaging filter will slightly attenuate the effect, and since it's so cheap to implement it in fixed point with bitshifts that you might consider adapting to another sample rate

#14

Hi @Sputnki I think it has to end up at 8kHz for the analysis part to work correctly. I could just add one of the existing filter objects before the analysis object to attenuate frequencies over the Nyquist limit for 8kHz (4kHz, presumably), then do a simple discard.

Or do the Factory objects not have a steep enough slope?

a|x

#15

You could try filter/fir and generate the coefficients from here: http://t-filter.engineerjs.com/