Re: [Audacity-devel] Automatic Volume Feature

[Richard A. <ri...@au...>]

On Sat, 2009-07-25 at 18:43 +0100, André Pinto wrote:
> Brief description of current behavior:
> - Initialization of varibles is done when the Record starts.
> - Portaudio callback function calls AVProccess. 
> Each time:
> -- we update the max peak volume during the current analysis using
> mInputMeter->GetMaxPeak();
> -- if audio is clipping we set our mAVClipped to true.
> When the current analysis time ends:
> -- if audio has clipped or if maxpeak is above the acceptable range we
> set the new volume to actual_volume+desired_max_peak-current_max_peak
> (I've tried to find a better function I had no success)
> -- if the max_peak is below the acceptable range we set the new volume
> to actual_volume+desired_max_peak-current_max_peak (notice that
> desired - current is now positive, the same expression is used but the
> condition is still needed as you may see checking the code)
> -- if the max_peak is within the acceptable range we stop monitoring.

> As I said before, this is just the initial implementation. Suggestions
> are welcome.
Don't do anything in the portaudio callback context if you can avoid it
(to my mind, it's on the large side already). From your description (I
haven't read the code) I would suggest that you are doing unnecessary
work in the portaudio thread context. In fact, I think you can do all
you need to do based on the information passed to the record meter via
the message queue implemented within src/widgets/Meter.cpp (you might
want to do some re-factoring so that automatic volume adjust doesn't
depend on meters, but the pieces are all there).

In my mind, you can probably do the record level adjusts in the wx GUI
thread context, possibly in the meter refreshes (which would be what a
human operator has to do!) or in equivalent event handlers driven by a
timer (if you want to decouple more, or get different call intervals).

I think the decision algorithm will need more work (this is a
closed-loop controller, and we need to be reasonably sure it won't
oscillate under a range of conditions), but that can come later, I need
to do some more thinking about it.
> 
> I've also fixed a bug (at least I think it is a bug) with clipping
> (mBar[j].clipping was always true after first clipping),
That was intentional, and you've now broken it. The idea was that the
red lump beyond end of the meter bar would turn red if the signal
clipped, and stay on until the stream is stopped or the user clears the
clip indicator. This was designed as a clear flag to the user that the
signal has clipped, which they have to acknowledge.

That's now a bit broken, because the clip light now clears on the next
meter frame, so much quicker than the peak hold on the meters dropping.
I'm fairly certain this needs to be changed back, and if necessary
another flag added for your system to use.

> but I've noticed some strange behaviour with clipping. sometimes
> despite the fact that the volume meters were totally fulfilled no
> clipping was detected (probably a pre-clipped protection was already
> limiting the input? :s).

I can't reproduce this here - if I turn the sound card gain up until the
input is clipped, then the recording clip meters duly come on when the
data is clipped.

Richard