Re: [linux-audio-dev] TAP Scaling Limiter - how's it work?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] TAP Scaling Limiter - how's it work?
From: Tom Szilagyi (tszilagyi_AT_users.sourceforge.net)
Date: Wed Feb 18 2004 - 01:29:41 EET


Paul Winkler wrote:
> Hi folks, and Tom if you're listening,
>
> The description of the TAP Scaling Limiter is
> very interesting - http://tap-plugins.sourceforge.net/#limiter
> I'm just curious, having done no real DSP coding -
> it must do some internal buffering, right?

Right, i have to admit it does :)
That's why the plugin has to have latency.

> So how does it deal with half-cycles that fall on the edge of a
> buffer? It seems to me that you can't process the final
> half-cycle without refilling the buffer, but you can't refill the
> buffer until you've processed all its data - or can you?

Yes you can. No, you can't actually, but you can eliminate the problem
so you don't have to solve it. There is a ringbuffer, with a length
chosen so it is capable of containing a whole half-cycle even at low
frequencies (40 Hz is the limit in my implementation, which means
varying number of samples at varying samplerates). Incoming audio is
streamed into the ringbuffer (which actually works like a FIFO), and
the half-cycles are being scanned starting from the other end of the
buffer (that is, where output falls out).

Now let's say the buffer is just full of audio. The host calls run(),
and the plugin starts scanning backwards (from the oldest sample, that
is, the one just about to fall out of the FIFO, towards the newest one),
and marks zero-crosses and scales the marked individual zero-crosses. It
keeps track of the half-cycle boundaries, and when it reaches (or more
likely, overgoes) the N samples the plugin was asked to process in this
run() call, it pushes out the N samples, but that of course will be in
no relation with the half-cycle boundaries. Some piece of the last
half-cycle will remain, and at the next run(), the plugin will continue
the zero-cross scan from that point, not from the buffer boundary. But
it counts the N samples needed to be pushed out from the buffer
boundary, of course. I'm afraid i can't explain it very clearly, but i
hope you get the feeling.

Tom

ps. stay tuned, more plugins are about to arrive... expect them
in a week or two. :)


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Feb 18 2004 - 01:31:22 EET