[LAD] Mixing audio: Noiseless volume changes

Charles Z Henry czhenry at gmail.com
Tue Mar 19 23:12:21 UTC 2013


On Tue, Mar 19, 2013 at 5:57 PM, Fons Adriaensen <fons at linuxaudio.org>wrote:

> On Tue, Mar 19, 2013 at 05:26:27PM -0500, Charles Z Henry wrote:
>
> > You guys are splitting hairs... kind of misses the forest for the trees.
> > Here's my nit to pick: two identical 1st-order lowpass filters in series
> > are only equivalent to a 2nd-order lowpass filter when the quality factor
> > is 0.5.  So that's not the same thing.
>
> The same thing as what ?
>

I was replying to Tim's comment on putting two filters in series--I guess
if you've settled on Q=0.5 then it's fine.  I thought you were discussing
this in general.


> In this case we don't want overshoot so Q must be <= 0.5.
>
> The form I posted actually has a little bit of feedback,
> so Q is jusst above 0.5. This makes it reach its target
> value in finite time, bit still with an overhsoot of less
> than 1/1000 dB. The same code can do any Q value you want,
> just use the righr value for the feedabck term (a).
>
>
> > The best way to avoid "zipper noise" is not to create it in the first
> > place.   Ramps not good enough for ya?  Why not?  Any "slow enough" ramp
> > will do.
>
> 'Slow enough' might be too slow. A fader should still 'feel' like
> it has no delay.
>
> > I think you should figure out a different shape of ramp that doesn't have
> > discontinuities in the first derivative
>
> That is precisely what a second order lowpass is doing.
>
> > 0.5-0.5*cos(pi*n/N)
>
> Raised cosine, indeed better than a linear ramp.
>
> Ideally you'd want the higher derivatives to be continuous
> as well. A raised hyperbolic tangent will do that, or at least
> come close to the ideal in finite time.
>
> The problem with all thoe programmed ramps is that they require
> extra logic to handle the case where the requested gain changes
> during the ramp. A linear filter solves that problem neatly with
> much less code. And in fact *any* system that handles that case
> well will be a low pass filter is some disguise.
>

Okay--I misunderstood the application.  The lowpass filter is definitely
better handling all the possible inputs.

If it was always a fixed time over which you need to fade in, I think you
could find a good analytical function to use, or make a table that always
has a predictable effect.

 Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20130319/5f2bcb8b/attachment.html>


More information about the Linux-audio-dev mailing list