On Tue, 2014-02-18 at 23:26 +0100, Thomas Martitz wrote: > 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? That makes no significant difference. The tunnel sink sends audio to the remote server at the same rate that the remote server asks for more audio. If there is bad network congestion or not enough bandwidth, the tunnel sink will slow down. Audio won't pile up at the tunnel sink. Again, if the application completely ignores the rate at which pulseaudio consumes the audio, excessive amount of buffering may happen, but that's a result of the application ignoring the buffer fill level, not a fault of pulseaudio. -- Tanu
