[vlc-devel] Re: re : audio clicks in 0.6.2

Gildas Bazin gbazin at netcourrier.com
Fri Aug 15 01:42:01 CEST 2003

On Thursday 14 August 2003 22:58, Stephan Assmus wrote:
> Could you elaborate on the reasons why the audio synchronization is 
> planned only as an option (mode)?

It is not planned as an option, it is planned as the default synchronisation 
mode _when_ we  have control over the reading pace of the incoming stream.

> Even as a network player, it makes 
> perfect sense (to me) to synchronize to an audio clock.

Audio clock is the clock of your soundcard which is going to drift from the 
clock the server is using to send the data. This is why you synchronise on 
the server clock and not on the audio clock (In MPEG TS the server sends 
Program Clock References embedded in the stream so you can synchronise with 
its clock).

> I don't mean to 
> synchronize to the audio from the packets (which might come at an 
> unpredictable rate, or might not come at all), but to a virtual audio 
> framerate, depending on what the framerate (sometimes called 
> samplerate) of the received audio buffers is.

This is already what is done when streams don't have PCRs/PTSs (Presentation 
Time Stamps) information embedded in them.

> The received packets can 
> then be applied to the virtual stream of audio depending on their 
> timestamps. In the ideal case, this setup would work perfect, in less 
> ideal cases, it cannot work worse than the current implementation. 
> However, the current implementation seems to work less than perfect in 
> the ideal case.

No it won't work for network streams. You absolutely need to read the 
incoming stream at the pace the server is sending it (in other words 
synchronise to the server clock) otherwise you will sooner or later get 
underruns or overruns of your internal buffers.
It may not matter for short duration programs considering that you can first 
cache a big enough amount of data to ensure you that your buffers will not 
underrun/overrun if your playing speed is slightly different from the speed 
the server is sending the data.
But think about DVB channels that are broadcasted 24h a day.


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 mailing list