a bug in Meters and Audio I/O

I'm trying to track down an intermittent bug (reported for OS X as well
as Linux) where the VU meters (specifically, the playback VU meters)
indicate clipping at the start of playback before working normally. This
is a pain, because it latches the clipping indicators on, and prevents
you seeing what is actually clipped in the track.

After various debugging, I've concluded that the problem is in the data
that is passed to Meter::UpdateDisplay(), because the values are
definitely wrong when they come out of there to be used to update the
meter.

Looking at the calling code in audacityAudioCallback() (in AudioIO.cpp),
I'm confused as to how this works at all. The first thing that function
does is to update the VU meters. Now that's fair enough for the record
VU meters, because we have the record audio data ready to use. However
it seems pretty off the mark for the playback meters, because it's only
much later on that we consider actually collecting the audio we want to
play and putting it in the portaudio output buffer. So what we are
updating the VU meter with is certainly not the section of audio that is
about to be played. It might (if portaudio uses persistent buffers) be
the section of audio that has just been played, but there are no
guarantees of that.

In practise it seems that when portaudio calls audacityAudioCallback()
it does in fact use the same buffer for playback each time, so we
largely get away with this, and the meters are just one callback behind
(which isn't important or noticeable). The first time round, however,
the buffer can (and does) contain any values, hence why sometimes the
first meter update is off the scale on one or both channels.

I haven't yet changed anything, because this is a very complex piece of
code, but I'm fairly sure that what we ought to be doing is updating the
playback meters as the last thing in the callback, after we have zeroed
the portaudio playback buffer and re-filled it with the next block of
audio to be played. This does break up the structure a bit, but the
meters will behave properly.

Richard

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/