[pulseaudio-discuss] audio video out of sync

[Thomas Martitz]

Am 18.02.2014 13:38, schrieb 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).
>

What about applications that just use the default sink transparently, 
whether that is a network tunnel or not?

Best regards.