18 Mar
2013
18 Mar
'13
10:50 p.m.
Hi again. Looking for any advice, tips, tricks, anecdotes etc.
I want to eliminate or reduce 'zipper' noise on volume changes.
So I'm looking at two techniques:
Zero-crossing / zero-value signal detection, and slew-rate limiting.
Code is almost done, almost ready to start testing each technique.
Each technique has some advantages and disadvantages.
If I use a slew-rate limiter, I figure for a sudden volume factor change
from 0.0 to 1.0, if I limit the slew rate to say 0.01 per sample then after
100 samples the ramp will be done.
But even with a fine ramp, this still might introduce artifacts in the audio.
If I use a zero-crossing/zero-value detector and apply volume changes
only at these safe points, that's a much more desirable 'perfect' system.
But I stuck a time limit on waiting for a zero-cross because it's possible
the signal might have a high DC offset, or contain VLF < 20Hz.
(One cannot simply wait for the current data value to be 'zero' because
for example with a perfect square wave signal the 'current' value will never
approach zero, hence the zero-crossing detection requirement.)
At some point waiting for a zero-cross, a ramp would have already finished
and it may have been better to use that ramp instead.
Conversely, a zero-cross might happen sooner than a ramp could finish,
and we definitely want to use that zero-cross here instead of the ramp.
So it means I either have to give the user a choice of the two techniques,
or try to automatically switch between them - which ever one occurs first,
the ramp finishing or the zero-cross, use it.
But it means I have to keep two audio buffers - one for applying the ramp
as the samples are processed, and one for waiting until zero-cross happens -
and which ever one "finishes the race" first, that buffer "gets the
nod".
The zero-crossing technique has some interesting implications.
For a stereo signal each channel's zero-cross will happen at different times.
So I'm trying to imagine what that's going to sound like where the volume
changes happen at slightly different times, if it will be noticeable, even
though that is far better than 'zipper' noise.
Also I'm trying to imagine how track cross-fading support would deal
with zero-crossing - if it is better to use ramps in that case.
What do you think?
Thanks.
Tim.
18 Mar
18 Mar
11:47 p.m.
On Mon, Mar 18, 2013 at 5:50 PM, Tim E. Real <termtech(a)rogers.com> wrote:
Hi again. Looking for any advice, tips, tricks,
anecdotes etc.
I want to eliminate or reduce 'zipper' noise on volume changes.
So I'm looking at two techniques:
Zero-crossing / zero-value signal detection, and slew-rate limiting.
Code is almost done, almost ready to start testing each technique.
Each technique has some advantages and disadvantages.
If I use a slew-rate limiter, I figure for a sudden volume factor change
from 0.0 to 1.0, if I limit the slew rate to say 0.01 per sample then
after
100 samples the ramp will be done.
But even with a fine ramp, this still might introduce artifacts in the
audio.
You cannot avoid artifacts in the audio. The only question is what is the
nature of the artifacts.
If I use a zero-crossing/zero-value detector and apply
volume changes
Zero crossing stuff is a completely bogus idea that needs to be eliminated
from the lexicon of audio software. You will not be accomplishing anything
trying to use such a technique, other than introduce even more artifacts
(and rather horrendous ones at that). Even zero-valued samples are not
particularly useful - keep in mind that what defines transducer (read:
speaker) behaviour is power, not instantaneous volume.
Just use sensibly short ramped changes. For the record, Ardour uses 64 or a
JACK period size, whichever is, hmm, larger or smaller, can't recall.
--p
19 Mar
19 Mar
12:05 a.m.
On March 18, 2013 06:47:16 PM you wrote:
On Mon, Mar 18, 2013 at 5:50 PM, Tim E. Real <termtech(a)rogers.com> wrote:
Hi again. Looking for any advice, tips, tricks, anecdotes etc.
I want to eliminate or reduce 'zipper' noise on volume changes.
So I'm looking at two techniques:
Zero-crossing / zero-value signal detection, and slew-rate limiting.
Code is almost done, almost ready to start testing each technique.
Each technique has some advantages and disadvantages.
If I use a slew-rate limiter, I figure for a sudden volume factor change
from 0.0 to 1.0, if I limit the slew rate to say 0.01 per sample then after
100 samples the ramp will be done.
But even with a fine ramp, this still might introduce artifacts in the audio.
You cannot avoid artifacts in the audio. The only question is what is the
nature of the artifacts.
If I use a zero-crossing/zero-value detector and apply volume changes
Zero crossing stuff is a completely bogus idea that needs to be eliminated from
the lexicon of audio software. You will not be accomplishing anything trying
to use such a technique, other than introduce even more artifacts (and rather
horrendous ones at that). Even zero-valued samples are not particularly useful
- keep in mind that what defines transducer (read: speaker) behaviour is power,
not instantaneous volume.
Just use sensibly short ramped changes. For the record, Ardour uses 64 or a
JACK period size, whichever is, hmm, larger or smaller, can't recall.
--p
Wow, surprising answer.
Can you elaborate a wee bit on the bogus point? What worse artifacts?
Popping noise will be heard if sudden volume change is applied while
the signal data value is currently non-zero.
Is it not better to apply (register) the changes during zero or near-zero
signal data values?
After all, some electronic systems employ it:
http://en.wikipedia.org/wiki/Zero_crossing
http://electronicdesign.com/analog/digital-volume-control-eliminates-zipper-
noise
Thanks.
Tim.
12:28 a.m.
On 18/03/13 "Tim E. Real" <termtech(a)rogers.com> wrote:
On March 18, 2013 06:47:16 PM you wrote:
On Mon, Mar 18, 2013 at 5:50 PM, Tim E. Real <termtech(a)rogers.com>
wrote:
Hi again. Looking for any advice, tips, tricks, anecdotes etc.
I want to eliminate or reduce 'zipper' noise on volume changes.
So I'm looking at two techniques:
Zero-crossing / zero-value signal detection, and slew-rate limiting.
Code is almost done, almost ready to start testing each technique.
Each technique has some advantages and disadvantages.
If I use a slew-rate limiter, I figure for a sudden volume factor
change
from 0.0 to 1.0, if I limit the slew rate to say 0.01 per sample then
after 100 samples the ramp will be done.
But even with a fine ramp, this still might introduce artifacts in the
audio.
You cannot avoid artifacts in the audio. The only question is what is
the nature of the artifacts.
If I use a zero-crossing/zero-value detector and apply volume changes
Zero crossing stuff is a completely bogus idea that needs to be
eliminated from the lexicon of audio software. You will not be
accomplishing anything trying to use such a technique, other than
introduce even more artifacts (and rather horrendous ones at that).
Even zero-valued samples are not particularly useful
- keep in mind that what defines transducer (read: speaker) behaviour
is power, not instantaneous volume.
Just use sensibly short ramped changes. For the record, Ardour uses 64
or a JACK period size, whichever is, hmm, larger or smaller, can't
recall.
--p
Wow, surprising answer.
Can you elaborate a wee bit on the bogus point? What worse artifacts?
Popping noise will be heard if sudden volume change is applied while
the signal data value is currently non-zero.
Is it not better to apply (register) the changes during zero or
near-zero
signal data values?
After all, some electronic systems employ it:
http://en.wikipedia.org/wiki/Zero_crossing
http://electronicdesign.com/analog/digital-volume-control-eliminates-zipper-
noise
Thanks.
Tim.
Not that my opinion should hold any weight...
For Wav Composer Not Toilet's sampler module, I created a zero-crossing
"detector" which would look N samples either side of loop points etc
for the nearest sample to zero. It never really worked as well as I
expected, always always needed x-fades as well...
then there was bi-directional looping which you could specify N samples
to jump hopefully to prefent than phase mirroring which is even worse.
I think the only time zero-crossings are any good is in hand-crafted
cutting of (very) simple waveforms.
12:45 a.m.
On Mon, Mar 18, 2013 at 11:28:24PM +0000, James Morris wrote:
I think the only time zero-crossings are any good is
in hand-crafted
cutting of (very) simple waveforms.
The only case where switching on zero-crossings makes sense is when
the gain control element can't perform a continuous change and switching
is the only option. That is the case with many 'electronic volume control'
chips that have e.g steps of 1 dB (or worse).
Using floating point, there is no reason to ever have sudden gain changes,
just smooth the gain value itself (at the sample rate). A critically damped
second order lowpass with a rise time of 30 ms or so will eliminate all
audible artefacts. It's very low on CPU and you only need to run it while
the gain is changing.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
3:09 a.m.
On Mon, Mar 18, 2013 at 11:45 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
A critically damped
second order lowpass with a rise time of 30 ms or so will eliminate all
audible artefacts. It's very low on CPU and you only need to run it while
the gain is changing.
Although I understand the words & their meaning, I have no idea how to
start implementing such a filter.
I've found a 1st order algorithm on musicdsp:
http://www.musicdsp.org/showone.php?id=257
Since its second order I understand it needs the previous 2 outputs.
Critically dampened implies that the "factor" of influence of the previous
samples is very close to 1 ( 'a' in the algorithm linked )
How is the "rise time" determined here?
Noobie questions :) -Harry
4:17 a.m.
[Harry van Haaren]
On Mon, Mar 18, 2013 at 11:45 PM, Fons Adriaensen
<fons(a)linuxaudio.org>wrote;wrote:
[...]
A 2nd-order IIR filter is often called a "biquad"; at musicdsp, look
for that instead. There should also be plenty of formulae for
computing 2nd-order lowpass filter coefficients. Those following
tradition (like RBJ's lovely cookbook at musicdsp) will ask for filter
Q, which is 0.5 for critical damping.
A critically damped
second order lowpass with a rise time of 30 ms or so will eliminate all
audible artefacts. It's very low on CPU and you only need to run it while
the gain is changing.
Although I understand the words & their meaning, I have no idea how to
start implementing such a filter.
I've found a 1st order algorithm on musicdsp: How is the "rise time" determined here?
As a function of the filter's damping (zeta = 2*Q) and frequency:
http://en.wikipedia.org/wiki/Rise_time
4:22 a.m.
[Tim Goetze]
[Harry van Haaren]
Sorry, zeta = 1 / (2*Q).
How is the "rise time" determined here?
As a function of the filter's damping (zeta = 2*Q) and frequency:
http://en.wikipedia.org/wiki/Rise_time
2:02 p.m.
On Tue, Mar 19, 2013 at 04:26:21AM +0100, Tim Goetze wrote:
A 2nd-order IIR filter is often called a
"biquad"; at musicdsp, look
for that instead.
Not really. A biquad is one way to implement a 2nd order IIR, and
in many cases related to audio DSP, not really the best way.
Anyway, using a biquad for something so simple is giant overkill.
The code below will do the trick. The filter is
very slightly underdamped so it will reach its
target value faster.
// Init time calculation of constants:
constant float T = 0.05f; // 50 milliseconds
float w, a, b;
w = 10.0f / (FS * t); // FS = sample rate
a = 0.07f; // Controls damping
b = 1.0f / (1.0f - a);
// For each gain control:
float gt; // gain set by user, i.e. in steps.
float g1, g2; // filter state
gt = g1 = g2 = 0;
// You need some counter + logic to check how
// long ago the value gt was last changed.
// No high precision is required, just counting
// periods will do. The only purpose is to skip
// the filter calculation when it is not really
// required - when the output is close enough to
// its target value. With the values above, T
// seconds after the last input change the gain
// will be within 1/1000 dB of the requested
// value.
// If gt has not changed for at least the time T,
// just use gt:
for (i = 0; i < nframes; i++)
{
out [i] = gt * in [i];
}
// Else run the filter:
for (i = 0; i < nframes; i++)
{
g1 += w * (gt - g1 - a * g2);
g2 += w * (b * g1 - g2);
out [i] = g2 * in [i];
}
// You could also run the filter all the time, in
// that case you may need denormal protection:
g1 += w * (gt - g1 - a * g2 - 1e-20f);
g2 += w * (b * g1 - g2 + 1e-20f);
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
2:53 p.m.
[Fons Adriaensen]
On Tue, Mar 19, 2013 at 04:26:21AM +0100, Tim Goetze
wrote:
[...]
A 2nd-order IIR filter is often called a
"biquad"; at musicdsp, look
for that instead.
Not really. A biquad is one way to implement a 2nd order IIR, and
in many cases related to audio DSP, not really the best way.
Anyway, using a biquad for something so simple is giant overkill. // Else run the filter:
for (i = 0; i < nframes; i++)
{
g1 += w * (gt - g1 - a * g2);
g2 += w * (b * g1 - g2);
out [i] = g2 * in [i];
}
Surely you realise this version executes exactly as many additions and
multiplications per sample as a biquad?
4:08 p.m.
On Tue, Mar 19, 2013 at 03:02:19PM +0100, Tim Goetze wrote:
Yes. In this case it's possible to remove one multiplication:
a = 0.07f;
b = 1 + a;
// ...
gm = b * gt;
for (i = 0; i < nframes; i++)
{
g1 += w * (gm - g1 - a * g2);
g2 += w * (g1 - g2);
out [i] = g2 * in [i];
}
But CPU usage is not the point. For a biquad the result
can depend on small differences between the coefficients,
with consequent loss of precision. It's a problem mainly
with LF filters. Try a 10 Hz highpass at 96 kHz.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
for (i = 0; i
< nframes; i++)
{
g1 += w * (gt - g1 - a * g2);
g2 += w * (b * g1 - g2);
out [i] = g2 * in [i];
}
Surely you realise this version executes exactly as many additions and
multiplications per sample as a biquad?
4:37 p.m.
[Fons Adriaensen]
On Tue, Mar 19, 2013 at 03:02:19PM +0100, Tim Goetze
wrote:
Very nice work, it's lighter on state and setup, and now also on
execution.
Since this is not a highpass, let's just skip any claims of increased
stability.
However, I still take issue with the rather exaggerated claim that
using a biquad to smoothen gain changes would be "giant overkill". It
may be slightly less efficient than your now optimised version, but
certainly not enough to substantiate this claim.
In fact, I think this is a rather grandiloquent choice of words that
is entirely uncalled for.
BTW, at the cost of that one extra multiplication, the biquad is more
versatile if you run the gain filter permanently: you can simply feed
it the current knob value and it will automatically produce a nice,
smooth curve, without needing to be set up again for every gain
change.
Surely you realise this version executes exactly
as many additions and
multiplications per sample as a biquad?
Yes. In this case it's possible to remove one multiplication:
a = 0.07f;
b = 1 + a;
// ...
gm = b * gt;
for (i = 0; i < nframes; i++)
{
g1 += w * (gm - g1 - a * g2);
g2 += w * (g1 - g2);
out [i] = g2 * in [i];
}
5:31 p.m.
On Tue, Mar 19, 2013 at 04:46:10PM +0100, Tim Goetze wrote:
However, I still take issue with the rather
exaggerated claim that
using a biquad to smoothen gain changes would be "giant overkill". It
may be slightly less efficient than your now optimised version, but
certainly not enough to substantiate this claim.
A biquad is overkill because it has 5 free parameters, while the
filter that is required only has 3: frequency, damping, and gain
(and those map almost 1 to 1 to w, a, b). Also, unless the user
computes the filter by hand and discovers it can be simplified,
he/she would probably use a library routine, i.e. a function call
for each sample.
BTW, at the cost of that one extra multiplication, the
biquad is more
versatile if you run the gain filter permanently: you can simply feed
it the current knob value and it will automatically produce a nice,
smooth curve, without needing to be set up again for every gain
change.
Exactly the same with the form I proposed, w, a, b need to be computed
just once, not for every gain change. In fact only w depends on the
sample rate, a and b are fixed constants. So actually you would code
it as:
gm = 1.07 * gt;
for (i = 0; i < nframes; i++)
{
g1 += w * (gm - g1 - 0.07f * g2);
g2 += w * (g2 - g1);
out [i] = g2 * in [i];
}
Without the '-0.07f * g2' it would just be two
first order LP filters in series.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
8:06 p.m.
[Fons Adriaensen]
Exactly the same with the form I proposed, w, a, b need
to be computed
just once, not for every gain change. In fact only w depends on the
sample rate, a and b are fixed constants.
Ah yes, sorry, I see that now.
If that extra operation comes around to bite hard enough, I'll be sure
to chain two 1st-order lowpass filters.
11:26 p.m.
On Tue, Mar 19, 2013 at 08:15:41PM +0100, Tim Goetze wrote:
[Fons Adriaensen]
There is a much more important (in some use cases) feature of
this form: you can change 'w' (cutoff frequency c.q. settling
time) instantly without introducing transients into the signal.
Doing this with a biquad would generate a step in the output.
So it's the ideal form for a 'voltage controlled' filter.
In fact the famous 'Moog ladder' is just the same but using
four first order sections instead of two.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Exactly the same with the form I proposed, w, a, b
need to be computed
just once, not for every gain change. In fact only w depends on the
sample rate, a and b are fixed constants.
Ah yes, sorry, I see that now.
If that extra operation comes around to bite hard enough, I'll be sure
to chain two 1st-order lowpass filters. 
11:26 p.m.
On Tue, Mar 19, 2013 at 2:15 PM, Tim Goetze <tim(a)quitte.de> wrote:
[Fons Adriaensen]
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 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. Your problem might be that you're trying to ramp the volume too
fast. Adding a filter just slows down the response anyway.
I think you should figure out a different shape of ramp that doesn't have
discontinuities in the first derivative, such as:
0.5-0.5*cos(pi*n/N)
where N is the number of samples in the ramp
If simple guesses like that are not good enough, you'll have to figure out
how to make a bandlimited step function that cuts out the problematic
frequencies.
Chuck
Exactly the same with the form I proposed, w, a, b
need to be computed
just once, not for every gain change. In fact only w depends on the
sample rate, a and b are fixed constants.
Ah yes, sorry, I see that now.
If that extra operation comes around to bite hard enough, I'll be sure
to chain two 1st-order lowpass filters.
11:57 p.m.
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 ?
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.
If simple guesses like that are not good enough,
you'll have to figure out
how to make a bandlimited step function that cuts out the problematic
frequencies.
Again that is exactly what a lowpass filter does.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
20 Mar
20 Mar
12:12 a.m.
On Tue, Mar 19, 2013 at 5:57 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
On Tue, Mar 19, 2013 at 05:26:27PM -0500, Charles Z
Henry wrote:
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.
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 ?
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).
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
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.
12:29 a.m.
On Tue, Mar 19, 2013 at 06:12:21PM -0500, Charles Z Henry wrote:
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.
Raised cosine is a good solution, but you don't need
sines and cosines. Try e.g.
x * x * (3 - 2 * x)
with x in [0...1].
This can even be generated using only additions.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
19 Mar
19 Mar
12:43 a.m.
On March 18, 2013 07:04:52 PM Tim E. Real wrote:
On March 18, 2013 06:47:16 PM you wrote:
On Mon, Mar 18, 2013 at 5:50 PM, Tim E. Real <termtech(a)rogers.com> wrote:
Hi again. Looking for any advice, tips, tricks, anecdotes etc.
I want to eliminate or reduce 'zipper' noise on volume changes.
So I'm looking at two techniques:
Zero-crossing / zero-value signal detection, and slew-rate limiting.
Code is almost done, almost ready to start testing each technique.
Each technique has some advantages and disadvantages.
If I use a slew-rate limiter, I figure for a sudden volume factor change
from 0.0 to 1.0, if I limit the slew rate to say 0.01 per sample then after
100 samples the ramp will be done.
But even with a fine ramp, this still might introduce artifacts in the audio.
You cannot avoid artifacts in the audio. The only question is what is the
nature of the artifacts.
If I use a zero-crossing/zero-value detector and apply volume changes
Zero crossing stuff is a completely bogus idea that needs to be eliminated from
the lexicon of audio software. You will not be accomplishing anything trying
to use such a technique, other than introduce even more artifacts (and rather
horrendous ones at that). Even zero-valued samples are not particularly useful
- keep in mind that what defines transducer (read: speaker) behaviour is power,
not instantaneous volume.
Just use sensibly short ramped changes. For the record, Ardour uses 64 or a
JACK period size, whichever is, hmm, larger or smaller, can't recall.
--p
Wow, surprising answer.
Can you elaborate a wee bit on the bogus point? What worse artifacts?
Popping noise will be heard if sudden volume change is applied while
the signal data value is currently non-zero.
Is it not better to apply (register) the changes during zero or near-zero
signal data values?
After all, some electronic systems employ it:
http://en.wikipedia.org/wiki/Zero_crossing
http://electronicdesign.com/analog/digital-volume-control-eliminates-zipper-
noise
Thanks.
Tim.
Ah, I may have answered my own question when I said:
"(One cannot simply wait for the current data value to be 'zero' because
for example with a perfect square wave signal the 'current' value will never
approach zero, hence the zero-crossing detection requirement.)"
Yeah, I was worried about that bit:
That's not just an exception. With all kinds of waves not just square, many
times the current value may not approach zero even if it did 'cross' over.
So having no choice but to apply the volume at this cross point the popping
noise might still be heard. I guess that's what Fons meant by 'reduced'...
and what Paul meant by... bogus. Right?
Thanks.
Tim.
12:58 a.m.
On Mon, Mar 18, 2013 at 07:43:32PM -0400, Tim E. Real wrote:
Ah, I may have answered my own question when I said:
"(One cannot simply wait for the current data value to be 'zero' because
for example with a perfect square wave signal the 'current' value will never
approach zero, hence the zero-crossing detection requirement.)"
The analog waveform always 'approaches' zero - it's bandlimited and hence
continuous - it just may not happen at a sample point. In fact the chance
that it happens exactly at a sample point is zero.
So having no choice but to apply the volume at this
cross point the popping
noise might still be heard. I guess that's what Fons meant by 'reduced'...
and what Paul meant by... bogus. Right?
Imagine a signal slowly passing through zero, e.g. a low frequency
sine wave. If you switch gain at an arbitatry point there will be
a 'step', having a 1/F spectrum (just like a square wave). If you
switch at a zero crossing there will be 'sharp corner', and this
has a 1/(F^2) spectrum (like a triangular wave). So instead of a
sharp click there will be something more like a 'thump'. The only
real solution is to never switch the gain, but change it smoothly.
Caio,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
1:31 a.m.
On March 18, 2013 11:58:48 PM Fons Adriaensen wrote:
On Mon, Mar 18, 2013 at 07:43:32PM -0400, Tim E. Real
wrote:
Cool. Got it. And the response to James. Thanks very much.
It is here at the mixing stage that I want to limit control motions.
All our controller graphs are sample-accurate and it's possible to
deliberately draw sudden changes, also it's possible to suddenly
change a GUI slider or knob's position.
Tim.
Ah, I may have answered my own question when I
said:
"(One cannot simply wait for the current data value to be 'zero' because
for example with a perfect square wave signal the 'current' value will
never approach zero, hence the zero-crossing detection requirement.)"
The analog waveform always 'approaches' zero - it's bandlimited and hence
continuous - it just may not happen at a sample point. In fact the chance
that it happens exactly at a sample point is zero.
So having no choice but to apply the volume at
this cross point the
popping
noise might still be heard. I guess that's what Fons meant by
'reduced'...
and what Paul meant by... bogus. Right?
Imagine a signal slowly passing through zero, e.g. a low frequency
sine wave. If you switch gain at an arbitatry point there will be
a 'step', having a 1/F spectrum (just like a square wave). If you
switch at a zero crossing there will be 'sharp corner', and this
has a 1/(F^2) spectrum (like a triangular wave). So instead of a
sharp click there will be something more like a 'thump'. The only
real solution is to never switch the gain, but change it smoothly.
Caio,
12:05 a.m.
On Mon, Mar 18, 2013 at 05:50:39PM -0400, Tim E. Real wrote:
If I use a zero-crossing/zero-value detector and apply
volume changes
only at these safe points, that's a much more desirable 'perfect' system.
Zero crossings are not 'safe'. You avoid a discontinuity in the signal
but there will still be one in the derivative of the signal. The spectrum
will be different, and noise will be reduced a bit, but it's by no means
'perfect'.
The approach I use it to make a quick fade. There are two variations.
In both cases you select a 'period size', this could be Jack's period,
or a multiple of it close to some predetermined time, or it could be
entirely independent of the outer context.
In the simplest case, just make linear fade between the current and the
new gain. If the fade time is long enough this will do for non-critical
things such as a volume control in a player, but it's still not good enough
for e.g. a high quality mixer.
In the more complex version, you also limit the amount of gain change
per period. So the gain change may take several periods (which can be
shorter in this case). It requires a bit of logic and state machinery,
but nothing esoteric.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
4063
days inactive
4064
days old
linux-audio-dev@lists.linuxaudio.org
24 comments
7 participants
participants (7)
-
Charles Z Henry -
Fons Adriaensen -
Harry van Haaren -
James Morris -
Paul Davis -
Tim E. Real -
Tim Goetze