Audio Compressor/AGC in C or C++

CASTalk.com
Discussion of DSP, FPGA, storage and embedded system.

FAQ

Memberlist

Profile

Audio Compressor/AGC in C or C++ Goto page 1, 2, 3 Next

CASTalk.com Forum Index -> DSP

Author

Message

__GG
Guest

Posted: Fri Dec 09, 2005 5:16 pm Post subject: Audio Compressor/AGC in C or C++

I'd like to find source for audio compression classes or functions in C or C++. It would be nice if it had lookahead (slight delay is OK).

mlimber
Guest

Posted: Fri Dec 09, 2005 5:16 pm Post subject: Re: Audio Compressor/AGC in C or C++

__GG wrote:

Quote:

I'd like to find source for audio compression classes or functions
in C or C++. It would be nice if it had lookahead (slight delay is
OK).

Try http://google.com. I found, for instance, this site:

http://datacompression.info/NonCommercialLibs.shtml

Cheers! --M

Richard Dobson
Guest

Posted: Sat Dec 10, 2005 1:16 am Post subject: Re: Audio Compressor/AGC in C or C++

__GG wrote:

Quote:

I'd like to find source for audio compression classes or functions
in C or C++. It would be nice if it had lookahead (slight delay is
OK).

There's a few in the musicdsp archive. One has just been added using C++:

http://www.musicdsp.org/archive.php?classid=4#204

Richard Dobson

Erik de Castro Lopo
Guest

Posted: Sat Dec 10, 2005 1:16 am Post subject: Re: Audio Compressor/AGC in C or C++

mlimber wrote:

Quote:

__GG wrote:
I'd like to find source for audio compression classes or functions
in C or C++. It would be nice if it had lookahead (slight delay is
OK).

Try http://google.com. I found, for instance, this site:

http://datacompression.info/NonCommercialLibs.shtml

Those a data compressors. The OP was asking about dynamic
range compressors which are very different.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"We can build a better product than Linux" -- Microsoft
Corp.'s Windows operating-system chief, Jim Allchin.
One has to wonder why, with their huge resources, they haven't.

Mark
Guest

Posted: Sat Dec 10, 2005 1:16 am Post subject: Re: Audio Compressor/AGC in C or C++

I think the op is asking about dynamic range compressor i.e. AGC, i.e automatic loudness adj... not data reduction type of compression... Mark

__GG
Guest

Posted: Sat Dec 10, 2005 7:43 am Post subject: Re: Audio Compressor/AGC in C or C++

On Sat, 10 Dec 2005 08:46:20 +1100, Erik de Castro Lopo
<nospam@mega-nerd.com> wrote:

Quote:

mlimber wrote:

__GG wrote:
I'd like to find source for audio compression classes or functions
in C or C++. It would be nice if it had lookahead (slight delay is
OK).

Try http://google.com. I found, for instance, this site:

http://datacompression.info/NonCommercialLibs.shtml

Those a data compressors. The OP was asking about dynamic
range compressors which are very different.

Erik

Correct. Unfortunate that the term 'compressor' is overloaded.
That's why I said 'AGC' in the title.

Huge number of hits on Google, of course, and many are data
compressors. Of the others, I have no idea how well they work.
I was hoping that those on this group would have tried various
algorithms.

In particular, I'm wondering about fast envelope/peak detection
and signal averaging. That seems to be one of the keys, esp as
regards CPU cycles.

In this particular app, it's important that the initial attack does
not spike (as it would if gain were up and the env detector did not
react instantly). Something analogous (no pun intended) to the
traditional diode/cap peak detector still has a finite ramp-up time,
so buffer 'look ahead' is desirable. On the other hand, I don't
want to delay any longer than necessary. So the lookahead
interval should be roughly sync'd (or greater than) the attack
response of the envelope filter.

All this might be wishful thinking. Commercial apps probably do this,
but I'm not hopeful about finding C++ code that's optimized in this
respect.

Back to the envelope detector: How is this usually done? I think
peak is the way to go in general (don't want to waste cycles on RMS
if it's not going to help). I seem to remember some algorithms that
simply added each new sample into a running tally of absolute values.
There was a 'magic number' multiplier in the picture, 0.999, I
believe. Anyone know about that?

I've seen

Vladimir Vassilevsky
Guest

Posted: Sat Dec 10, 2005 8:04 am Post subject: Re: Audio Compressor/AGC in C or C++

Look through the datasheets of TAS3103, AD1954. The operation of the
lookahead compressor is explained there very clearly.
The C implementation is pretty obvious and straightforward, it is just
5-10 lines of code.
The main point about the compressors is there is no universal rule about
the parameters; it all depends on the desired effect and the audio content.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Quote:

In particular, I'm wondering about fast envelope/peak detection
and signal averaging. That seems to be one of the keys, esp as
regards CPU cycles.

In this particular app, it's important that the initial attack does
not spike (as it would if gain were up and the env detector did not
react instantly). Something analogous (no pun intended) to the
traditional diode/cap peak detector still has a finite ramp-up time,
so buffer 'look ahead' is desirable. On the other hand, I don't
want to delay any longer than necessary. So the lookahead
interval should be roughly sync'd (or greater than) the attack
response of the envelope filter.

All this might be wishful thinking. Commercial apps probably do this,
but I'm not hopeful about finding C++ code that's optimized in this
respect.

Back to the envelope detector: How is this usually done? I think
peak is the way to go in general (don't want to waste cycles on RMS
if it's not going to help). I seem to remember some algorithms that
simply added each new sample into a running tally of absolute values.
There was a 'magic number' multiplier in the picture, 0.999, I
believe. Anyone know about that?

robert bristow-johnson
Guest

Posted: Sat Dec 10, 2005 8:16 am Post subject: Re: Audio Compressor/AGC in C or C++

in article e1ckp11umqqr60cls9tu8j07spvn30nmss@4ax.com, __GG at
__GG@nomail.com wrote on 12/09/2005 20:43:

Quote:

"sample", and "modulation" are other terms that often means something
different to the audio/music folks.

Quote:

... I'm wondering about fast envelope/peak detection
and signal averaging. That seems to be one of the keys, esp as
regards CPU cycles.

what does the speed and smoothing (averaging) of your envelope/peak
detection have anything to do with CPU cycles?

Quote:

In this particular app, it's important that the initial attack does
not spike (as it would if gain were up and the env detector did not
react instantly). Something analogous (no pun intended)

it's *not* a pun! that is precisely why we call it "analog" electronics or
"analog" processing.

Quote:

sounds to me that you understand the issues quite well. so why is it that
you need help? you should be telling us how to do it! :-)

Quote:

All this might be wishful thinking. Commercial apps probably do this,
but I'm not hopeful about finding C++ code that's optimized in this
respect.

pretty easy to write. 50 lines of code or less.

Quote:

Back to the envelope detector: How is this usually done?

how about an analog to the diode/capacitor/load peak detector? or how about
squaring, LPFing, and square root (last step usually not necessary) for an
RMS envelope?

Quote:

I think
peak is the way to go in general (don't want to waste cycles on RMS
if it's not going to help).

it depends on what you're trying to do? are you trying to maintain a
certain perceptual loudness characteristic (then you need to do
"A-weighting" or "C-weighting" or even "E-weighting" (if you have the CPU
cycles) and RMS envelope detection. if you're trying to limit peak
excursions into the forbidden saturation region, then it's
diode/capacitor/resistor peak detection.

Quote:

I seem to remember some algorithms that
simply added each new sample into a running tally of absolute values.
There was a 'magic number' multiplier in the picture, 0.999, I
believe. Anyone know about that?

never seen it. why is 999/1000 so "magic"?

--

r b-j rbj@audioimagination.com

"Imagination is more important than knowledge."

Jerry Avins
Guest

Posted: Sat Dec 10, 2005 9:15 am Post subject: Re: Audio Compressor/AGC in C or C++

__GG wrote:

Quote:

On Sat, 10 Dec 2005 08:46:20 +1100, Erik de Castro Lopo
nospam@mega-nerd.com> wrote:

mlimber wrote:

__GG wrote:

I'd like to find source for audio compression classes or functions
in C or C++. It would be nice if it had lookahead (slight delay is
OK).

Try http://google.com. I found, for instance, this site:

http://datacompression.info/NonCommercialLibs.shtml

Those a data compressors. The OP was asking about dynamic
range compressors which are very different.

Erik

Correct. Unfortunate that the term 'compressor' is overloaded.
That's why I said 'AGC' in the title.

Huge number of hits on Google, of course, and many are data
compressors. Of the others, I have no idea how well they work.
I was hoping that those on this group would have tried various
algorithms.

In particular, I'm wondering about fast envelope/peak detection
and signal averaging. That seems to be one of the keys, esp as
regards CPU cycles.

In this particular app, it's important that the initial attack does
not spike (as it would if gain were up and the env detector did not
react instantly). Something analogous (no pun intended) to the
traditional diode/cap peak detector still has a finite ramp-up time,
so buffer 'look ahead' is desirable. On the other hand, I don't
want to delay any longer than necessary. So the lookahead
interval should be roughly sync'd (or greater than) the attack
response of the envelope filter.

All this might be wishful thinking. Commercial apps probably do this,
but I'm not hopeful about finding C++ code that's optimized in this
respect.

Back to the envelope detector: How is this usually done? I think
peak is the way to go in general (don't want to waste cycles on RMS
if it's not going to help). I seem to remember some algorithms that
simply added each new sample into a running tally of absolute values.
There was a 'magic number' multiplier in the picture, 0.999, I
believe. Anyone know about that?

I've seen

There's no assurance that a any sample in a modest number rill be near a
peak unless the oversampling ratio is high. That's why envelope
detection is often done with a Hilbert transform and computing I^2 +
Q^2. Even without bothering to take the square root, that's not cheap.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

__GG
Guest

Posted: Sat Dec 10, 2005 9:15 am Post subject: Re: Audio Compressor/AGC in C or C++

On Fri, 09 Dec 2005 21:52:25 GMT, Richard Dobson
<richarddobson@blueyonder.co.uk> wrote:

Quote:

__GG wrote:

I'd like to find source for audio compression classes or functions
in C or C++. It would be nice if it had lookahead (slight delay is
OK).

There's a few in the musicdsp archive. One has just been added using C++:

http://www.musicdsp.org/archive.php?classid=4#204

Richard Dobson

Thanks, Richard.

The 'Chunkware' code (your link) looks well written, but I was
actually expecting something more complex. If that works well,
all the better.

I also found this:

http://www.music.helsinki.fi/research/spkit

It looks interesting. Rather involved set of classes, though.
Also, the 'SonicFlow' compressor on SourceForge.net.

I'd still like to get pro opinions on those implementations if
any of you have reviewed the code or run them.

__GG
Guest

Posted: Sat Dec 10, 2005 9:16 am Post subject: Re: Audio Compressor/AGC in C or C++

On Fri, 09 Dec 2005 21:16:34 -0500, robert bristow-johnson
<rbj@audioimagination.com> wrote:

Quote:

in article e1ckp11umqqr60cls9tu8j07spvn30nmss@4ax.com, __GG at
__GG@nomail.com wrote on 12/09/2005 20:43:

... I'm wondering about fast envelope/peak detection
and signal averaging. That seems to be one of the keys, esp as
regards CPU cycles.

what does the speed and smoothing (averaging) of your envelope/peak
detection have anything to do with CPU cycles?

More sophisticated detection probably requires conversion to float.
RMS requires square and square root, which would be computationally
expensive. I'm thinking that there may be much faster algorithms that
stay in int domain and still work well.

By the way, I'm just trying to get max energy from the input channel
for a speech-rec app. I want to avoid spikes and other harmonic-rich
artifacts, hence the desired lookahead buffer.

Quote:

to the traditional diode/cap peak detector still has a finite ramp-up time,
so buffer 'look ahead' is desirable. On the other hand, I don't
want to delay any longer than necessary. So the lookahead
interval should be roughly sync'd (or greater than) the attack
response of the envelope filter.

sounds to me that you understand the issues quite well. so why is it that
you need help? you should be telling us how to do it! :-)

Yeah, right! <g> I've seen some of the tech posts on this group.
Besides, there is a big difference between knowing how it works and
having good intuition for algorithms. You guys live there.

Quote:

pretty easy to write. 50 lines of code or less.

I was hoping that's the case. Surprising that there isn't more code
floating around then.

Quote:

Back to the envelope detector: How is this usually done?

how about an analog to the diode/capacitor/load peak detector? or how about
squaring, LPFing, and square root (last step usually not necessary) for an
RMS envelope?

Still talking 50 lines of code? I do like this stuff, but
unfortunately I can't schedule play time. Otherwise I'd try to write
each of those building blocks and play with configurations. That
would take a while.

The comp is a small block in a large non-DSP app. That's the reason
I'm trying to minimize cycles, and why I'm looking for a starting
point for the code.

Quote:

I think
peak is the way to go in general (don't want to waste cycles on RMS
if it's not going to help).

it depends on what you're trying to do? are you trying to maintain a
certain perceptual loudness characteristic (then you need to do
"A-weighting" or "C-weighting" or even "E-weighting" (if you have the CPU
cycles) and RMS envelope detection. if you're trying to limit peak
excursions into the forbidden saturation region, then it's
diode/capacitor/resistor peak detection.

All this depends on a very temperamental speech-rec module. I have no
idea what will make it barf, but I'm pretty sure it won't like
artifacts from spikes or clipping. I bet some breathing or other
normal compressor side-effects won't bother it.

Quote:

No idea. I've seen it in a couple different programs, but maybe it's
coincidence. I guess they both chose to average 1000 samples. That
averaging window would have direct bearing on the attack response, so
I would have expected it to be a variable rather than a #define.

I'll have to find that code again and take a closer look, but I
thought that attack and release settings would directly affect the
length of that averaged buffer.

__GG
Guest

Posted: Sat Dec 10, 2005 9:16 am Post subject: Re: Audio Compressor/AGC in C or C++

On Fri, 09 Dec 2005 23:02:38 -0500, Jerry Avins <jya@ieee.org> wrote:

Quote:

Not sure about the CPU expense of a Hilbert transform, but that's why
I thought RMS may not work (and may be overkill anyway). Given that I
(probably) don't need to maintain perceived loudness, can you think of
a faster approach for the detector?

If memory serves, you worked on compressors for NASA, right? Maybe
analog, but the same general approach should work here: just deliver
loud intelligible energy without clipping.

The envelope detector has to be the most complicated component, so
it's worth some thought. In simplistic form, it seems like you'd want
to average X number of samples for the attack (depending on designated
attack time) and Y number of samples for release. X and Y could be
derived by dividing designated attack and release times (resp) by
1/sample rate.

Now that I think about this, it seems that it could still be prone to
clipping unless there was another mechanism akin to a non-slew-limited
diode/cap. That limiter would have to be integral to the compressor's
control path so it could override the gain structure.

Jerry Avins
Guest

Posted: Sat Dec 10, 2005 9:16 am Post subject: Re: Audio Compressor/AGC in C or C++

__GG wrote:

...

Quote:

No square root is needed, If you know the target root, you know the
target square.

...

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Jerry Avins
Guest

Posted: Sat Dec 10, 2005 9:16 am Post subject: Re: Audio Compressor/AGC in C or C++

__GG wrote:

Quote:

On Fri, 09 Dec 2005 23:02:38 -0500, Jerry Avins <jya@ieee.org> wrote:

There's no assurance that a any sample in a modest number rill be near a
peak unless the oversampling ratio is high. That's why envelope
detection is often done with a Hilbert transform and computing I^2 +
Q^2. Even without bothering to take the square root, that's not cheap.

Jerry

Not sure about the CPU expense of a Hilbert transform, but that's why
I thought RMS may not work (and may be overkill anyway). Given that I
(probably) don't need to maintain perceived loudness, can you think of
a faster approach for the detector?

If memory serves, you worked on compressors for NASA, right? Maybe
analog, but the same general approach should work here: just deliver
loud intelligible energy without clipping.

You have a long memory, and that was a long time ago. Mercury orbital
flights. The compressor used only diodes, resistors and capacitors. The
design wasn't mine, but I built plenty of them.

I don't know that good RMS (MS is enough) is easy either, but I think
that Parcival's Theorem might say it is. There's the same energy in
sin(xt) + sin(3xt) as there is in sin(xt) - sin(3xt), but the peaks are
very different. If you want to control the peaks, you have to sense
peaks, not power.

Quote:

The envelope detector has to be the most complicated component, so
it's worth some thought. In simplistic form, it seems like you'd want
to average X number of samples for the attack (depending on designated
attack time) and Y number of samples for release. X and Y could be
derived by dividing designated attack and release times (resp) by
1/sample rate.

Now that I think about this, it seems that it could still be prone to
clipping unless there was another mechanism akin to a non-slew-limited
diode/cap. That limiter would have to be integral to the compressor's
control path so it could override the gain structure.

Analog Devices makes at least one analog audio compressor. I can dig out
the number if you need it. A look at the data sheet will give you some
good ideas about what's worth doing. What to do is at least as important
as the implementation method.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

__GG
Guest

Posted: Sat Dec 10, 2005 5:15 pm Post subject: Re: Audio Compressor/AGC in C or C++

On Fri, 09 Dec 2005 21:52:25 GMT, Richard Dobson
<richarddobson@blueyonder.co.uk> wrote:

Quote:

Here's another thought: If I were to use instantaneous peak detection
instead of RMS or other slower envelope, then lookahead would not be
necessary. The attack would track instantly.

ref: http://www.musicdsp.org/archive.php?classid=0#19

That should use very few cycles.

Questions:

What is the flaw here? If I don't need musical-sounding output, just
maximized clean signal, is there any drawback to simply
feed-forwarding the peak-detected, slower-decay envelope to a virtual
VCA?

What is the best way to control decay/release? Given that the release
does not have to be micro-second accurate, I could add groups of, say,
100 sample abs values, then feed each into a fifo. Accumulate the
total in the FIFO by adding each new value, subtracting each old value
as it gets bumped. The groups of 100 would eliminate the need for a
long buffer. Possible stepping noise due to time granularity from
grouping?

This may also help with noise gating. I'd have x milliseconds of
amplitudes in the fifo. If the total is below the noise threshold,
turn off output.

?

	CASTalk.com Forum Index -> DSP	All times are GMT Goto page 1, 2, 3 Next
Page 1 of 3

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum