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.
