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
