Bug 95411

From mailing list:

I've been able to reproduce this exact issue very easily on the
bluetooth Parrot Zik and Parrot Zik 2 models with my btusb receiver by
running out of range of the receiver.
When out of range, a popping sound can be heard while the sound cuts
for a few milliseconds, and the sound then resumes where it initially
left off, creating a latency buffer which keeps growing every time the
headset goes out of range again.
The buffer resets when the card profile is turned off and back on (eg.
pactl set-card-profile bluez_card.... off && pactl set-card-profile
bluez_card.... a2dp_sink).

Worth noting the issue does not happen on the Parrot Zik 3, which is
compatible with Bluetooth 4.x (unlike the versions 1 and 2).

PulseAudio doesn't do any significant buffering in the bluetooth sink. It seems likely to me that the buffering happens in the kernel. It would be great if we could somehow control, or at least monitor, the latency caused by buffering in the kernel, but I'm not sure if that's possible (someone should ask the kernel developers).

it depend on the role of the application, when it is out of range, music playback still continue but voice chat or video sync need pulseaudio server drop data to recover the time lost

(In reply to Raymond from comment #3)
> it depend on the role of the application, when it is out of range, music
> playback still continue but voice chat or video sync need pulseaudio server
> drop data to recover the time lost

As I said, the bluetooth sink doesn't do significant buffering. There's no data to drop in pulseaudio.

Hmm, I think I wrongly assumed in my previous message that the data should be dropped from some existing buffer in pulseaudio. Pulseaudio could also drop data by requesting data from the client and not writing it to the hardware. That's actually what the code does when it seems that the hardware consumes data too slowly. If the kernel accumulates data, however, then that does not help.

How do you observe the high latency? Audio getting out of sync with video? What happens when you change the volume of the bluetooth device in pavucontrol (or a similar application)? Is the volume change delayed a lot too? If volume changes are delayed, then that confirms that there's a big buffer in the kernel or in the hardware. If volume changes are quick, then the problem is in pulseaudio or in the application.

Volume changes are not delayed IIRC.

Jerome, how are you observing the large latency? If it's unsynchronized audio and video, what video player are you using?

If the problem isn't in the kernel, the latency reports from pulseaudio to the video player should be relatively accurate regardless of whether pulseaudio drops audio or not, which should allow the video player to do the synchronization correctly. Either there's some problem in pulseaudio's latency reporting, or the video player doesn't do the AV syncing properly.

(In reply to Tanu Kaskinen from comment #7)
> Jerome, how are you observing the large latency? If it's unsynchronized
> audio and video, what video player are you using?
> 
> If the problem isn't in the kernel, the latency reports from pulseaudio to
> the video player should be relatively accurate regardless of whether
> pulseaudio drops audio or not, which should allow the video player to do the
> synchronization correctly. Either there's some problem in pulseaudio's
> latency reporting, or the video player doesn't do the AV syncing properly.

It's desynced audio/video in all apps. Can be seen in games (playing on Wine), movies/music (playing with mpv or in the browser), etc. The latency is consistent across all apps.

(In reply to Jerome Leclanche from comment #8)
> It's desynced audio/video in all apps. Can be seen in games (playing on
> Wine), movies/music (playing with mpv or in the browser), etc. The latency
> is consistent across all apps.

You mention movies/music. How do you notice with music? If you run "mpv some_music_file.ogg", does it take unusually long to start or pause? Do you notice a long startup delay even with "paplay /usr/share/sounds/alsa/Front_Center.wav"? (Make sure the sink isn't suspended when testing, because the suspended -> running transition may take some time that is not interesting.) The original reporter mentioned latencies up to 2 seconds, do you experience equally excessive latencies?

If this really happens with *all* applications, then I request that you check the volume change delay again, because starting a new stream (e.g. the paplay test) should have similar delay as a volume change. If they are different, then that's really weird. Note that the volume change has to be done through pulseaudio. If you change the volume via a hardware button on the bluetooth speakers or headset, that's a different volume than what pulseaudio controls (when talking about a2dp).

@Jerome: Volume changes are delayed too.

@Tanu: Yes, everything is delayed. Even starting music. Or somebody walks in and wants to speak with me and it may take 2-3 seconds to mute/pause/stop music in some cases.

(In reply to Mr Bump from comment #10)
> @Jerome: Volume changes are delayed too.

Yeah maybe I'm misremembering, I would have to test it again. Note that with the parrot zik there's two possible sources of volume change: from pulse, and internal to the headset. I believe at least one of the two is immediate.

But yes, it definitely happens across the entire system. Pings from skype are delayed, pausing/resuming music is delayed, etc.

I've just found partial workaround. Latency could be instantly fixed by executing this command:

pasuspender true

Another strange thing is that when i listen to music or whatewer using BT speakers and i turn on BT mouse (cheap logitech) it automatically pairs and works perfectly as one would suppose it should. However when later i turn the mouse off it completely screws the sound. Like there are several hiccups/interrupts in sound until it dissapears completely leaving the video stuck. After few seconds it comes up again, however with very big latency identical to issues described on this page. So i have to fix it again using "pasuspender true" after disconnecting the mouse.

I am not sure, if this is directly caused by pulseaudio, however i think that pulseaudio should flush the output buffer and start again if something went wrong with BT layer.

I'm closing this bug as a duplicate of bug 58746.

*** This bug has been marked as a duplicate of bug 58746 ***