[vlc-devel] Re: CVS Commit (massiot)
massiot at via.ecp.fr
Sun May 11 13:28:07 CEST 2003
À (At) 10:38 +0200 11/05/03, Gildas Bazin écrivait (wrote) :
> > * src/audio_output/output.c: Thou shalt not drop buffers
>About the last change, are you sure it's the right thing to do ?
>The audio output plugins should be buffering a minimum of audio data so if
>p_buffer->start_date < mdate() that means the audio output plugin is very
>late and we should better drop the sample instead of trying to resample.
>The audio output plugin will have started playing blanks anyway so dropping
>should not worsen the audio quality.
No. You didn't quite understand the patch. Consider the situation :
first buffer in FIFO start date = mdate() + 1 ms
audio output start_date = mdate() + 10 ms
This is a legal situation because 9 < 40 ms so we don't resample. If,
for a reason or another (like the audio clock is very unstable on
macs), p_buffer->start_date becomes mdate() - 1 ms, this should be
legal too. There are no dropped packets and the sound is continuous,
it's just the clock that is screwed. Since we allow a 40 ms
differential with p_buffer->start_date, we should allow it everywhere.
And if we're very late, p_buffer->start_date < mdate() - 40 ms and we
drop the buffer. But in most cases, we will have started resampling
earlier because | p_buffer->start_date - start_date | > 40 ms.
Actually I see no situation where dropping the buffer would be
preferable than resampling.
This patch just applies everywhere the same tolerance we've applied
at one point.
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>
More information about the vlc-devel