[pulseaudio-discuss] audio video out of sync

[Tanu Kaskinen]

On Tue, 2014-02-18 at 12:08 +0100, Thomas Martitz wrote:
> Am 18.02.2014 10:06, schrieb Tanu Kaskinen:
> > On Tue, 2014-02-18 at 11:04 +0200, Tanu Kaskinen wrote:
> >> On Tue, 2014-02-18 at 04:51 +0100, Malte Gell wrote:
> >>> Am 16.02.2014 12:24, schrieb Tanu Kaskinen:
> >>>
> >>>> On the topic of audio/video sync, synchronization requires accurate
> >>>> latency information. PulseAudio doesn't have that information. If the
> >>>> audio lags by a constant amount all the time, then you can work around
> >>>> the problem by configuring the latency offset with e.g. pavucontrol.
> >>> Thanks for the explanation.
> >>>
> >>> The audio lags do not occur all the time, they occur after some time,
> >>> often audio totally quits, when waiting a while audio comes back again.
> >>>
> >>> /var/log/messages gets flooded with these errors:
> >>>
> >>> [bluetooth] module-bluetooth-device.c: Skipping 412706 us (= 72800
> >>> bytes) in audio stream
> >>> [bluetooth] module-bluetooth-device.c: Skipping 465700 us (= 82148
> >>> bytes) in audio stream
> >>> [bluetooth] module-bluetooth-device.c: Skipping 154683 us (= 27284
> >>> bytes) in audio stream
> >>> [bluetooth] module-bluetooth-device.c: Skipping 126688 us (= 22344
> >>> bytes) in audio stream
> >>> [bluetooth] module-bluetooth-device.c: Skipping 70714 us (= 12472 bytes)
> >>> in audio stream
> >>>
> >>> Do these message give a hint where the problems come from?
> >> The messages indicate that the kernel is accepting audio from PulseAudio
> >> slower than what is required for smooth playback. I would guess that the
> >> problem is interference in the radio signal that prevents reliable
> >> communication.
> > I forgot to mention - these messages do not give any hints about why the
> > latency is increasing, that is, which buffer is getting bigger.
> >
> 
> 
> Doesn't this also appear for network streams, where each network-induced 
> skip adds to the stream latency without any kind of recovery. I.e. PA 
> never decreases the buffers again so that it can easily reach a couple 
> of seconds?

If you're talking about an application that uses libpulse to send audio
over the network, the answer is dependent on the application behaviour.
If the audio source is a file, this never happens on sensible
applications, because the application writes audio at a rate that
matches the rate that the sink consumes the audio. If the audio source
is a live stream, and the application blindly writes data to the
pulseaudio stream at the rate of the live stream, without monitoring how
much is being buffered in the stream, then yes, this can happen. If this
is not what the application wants, the application should drop audio
when the buffer level is too high in pulseaudio (if the application
doesn't do that, at some point pulseaudio will start dropping the audio,
but usually that happens only when the buffered amount is already very
large).

-- 
Tanu