I can confirm that; with module-rtp-recv, I've seen latencies of tens of seconds. Laurentiu Nicola On Tue, Feb 18, 2014, at 13:08, 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? > > Best regards > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
