Hello, i have issue with bluetooth speaker. it creates loud pop when it's (un)suspended by module-suspend-on-idle. so i proceeded to disable suspend-on-idle, but when i leave it on for few hours, the latency gets huge. Like 2 seconds or more. I suppose it has something to do with DAC clock (or samplerate) in bluetooth speakers being little bit slower than nominal. And the error adds up over time resulting in growing latency. When i manualy reconnect to speaker it gets fixed. Do you have any idea how to fix this? I think it needs something that will reset the stream when no audio is played, pretty much like suspend-on-idle does, but without powering the bt device off (which causes pop). it's really annoying. sometimes it scares the crap out of me, when speakers are on full volume and it pops when i eg. receive IM mesage. also it's probably not healthy for the speakers (i use conventional speakers with amp and bt receiver). I know the popping is mostly HW error. But it can be worked around by disabling suspend-on-idle, which then causes latency problems (also somehow HW related). And i think the latency problem can be somehow fixed in SW by restarting the stream or cleaning some buffer that causes the latency... BTW 2 seconds of latency are quite a lot... Is there even chance, that cheap BT device has 2 second buffer? Maybe it's pulse audio that has 2 second latency. And it would be easily fixed by not buffering silence. Or by deleting this buffer when idle. UPDATE: when i physically disconnect the bluetooth it stops playing imediatelly, so latency probably originates on laptop side. not in speaker/receiver. so probably PA's fault. Any ideas? See also: [pulseaudio-discuss] bluetooth latency gets gradually worse over time
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 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.