Bug 58746 - bluetooth audio out of sync when connection temporarily drops
Summary: bluetooth audio out of sync when connection temporarily drops
Status: NEW
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: modules (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
: 95411 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-12-25 13:10 UTC by Daniel Schaal
Modified: 2017-09-22 17:33 UTC (History)
18 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Proof-of-concept patch (9.37 KB, patch)
2016-07-24 15:46 UTC, Dmitry Kalyanov
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Schaal 2012-12-25 13:10:22 UTC
I'm using a bluetooth headset with pulseaudio. Whenever the connection temporarily drops (e.g. by moving too far from the bt device), I get the message in the syslog:

[bluetooth] module-bluetooth-device.c: Skipping 24275 us (= 4280 bytes) in audio stream

and the audio lags behind after that. A workaround is to suspend and resume the sink using "pactl suspend-sink 1 && pactl suspend-sink 0", after which the audio is in sync again.

Using the same headset on Windows doesn't show the same behavior.
Comment 1 mike 2016-02-13 23:32:25 UTC
Bumping this due to the fact that this bug is still very much present in 5, 6, 7, 8 and renders the act of using a bluetooth headset on most linux operating systems using pulseaudio utterly useless. The slightest blip throws the whole audio out of sync with the video. I noticed this when trying to watch a movie from a 6ft distance away (sill in range) but occasionally the signal would blip and cause said problem. Evidence in the logs:

Three of many lines: 

    Feb 13 17:25:49 saturn.net.overtmind.com pulseaudio[30599]: [bluetooth] module-bluez5-device.c: Skipping 5124656 us (= 903988 bytes) in audio stream
    Feb 13 17:25:49 saturn.net.overtmind.com pulseaudio[30599]: [bluetooth] mod ule-bluez5-device.c: Skipping 220060 us (= 38816 bytes) in audio stream
    Feb 13 17:25:49 saturn.net.overtmind.com pulseaudio[30599]: [bluetooth] module-bluez5-device.c: Skipping 346147 us (= 61060 bytes) in audio stream

Packages tested in Fedora 23:

rawhide:

    bluez-5.37-2.fc24.x86_64
    pulseaudio-8.0-3.fc24.x86_64

and also tried initially with:

    bluez-5.36-1.fc23.x86_64
    pulseaudio-7.1-1.fc23.x86_64

The rest of my findings are here, where someone else has also mentioned seeing this on Gentoo with PA 5,6 - I have tested 7 and 8:

https://www.reddit.com/r/linuxquestions/comments/45n710/pulseaudio_bluetooth_degraded_signal_out_of_sync/
Comment 2 Raymond 2016-02-14 09:53:05 UTC
If you want audio sync with video after audio transmission is broken, you need the application to skip some audio and restart audio playback
Comment 3 mike 2016-02-14 10:21:54 UTC
Shouldn't the buffer reset after detecting a skip event?
Comment 4 S. 2016-05-04 01:37:04 UTC
(In reply to xenith from comment #3)
> Shouldn't the buffer reset after detecting a skip event?

This would seem to be the most logical thing. The way it is now, even stopping and re-starting the audio stream doesn't fix the latency issue if there has ever been a brief blip in the current Bluetooth connection. Quite a showstopper for watching video with bluetooth speakers/headphones.
Comment 5 Arun Raghavan 2016-05-08 15:46:53 UTC
I've tried to reproduce this behaviour in the past, but it doesn't always happen this way (but I have seen the delays turn up on drops at times). If someone has a patch that definitely works (or a way to repro that is 100% reliable), I can try to look at this.
Comment 6 S. 2016-05-10 15:58:47 UTC
(In reply to Arun Raghavan from comment #5)
> I've tried to reproduce this behaviour in the past, but it doesn't always
> happen this way (but I have seen the delays turn up on drops at times). If
> someone has a patch that definitely works (or a way to repro that is 100%
> reliable), I can try to look at this.

I have about 6 different cheap Chinese bluetooth speakers, and they all exhibit this behavior. They all use the A2DP protocol, are you possibly seeing different behavior with HSP/HFP?
Comment 7 Sam Morris 2016-06-22 23:13:10 UTC
I can reproduce this easily by running 'speaker-test -c2 -t wav' and then walking away from my computer with my headphones on until the signal strength drops sufficiently that the headphones go silent. Then, when I walk back to the computer, the audio is waaaay out of sync, and pulseaudio has issued the 'skipping' message many times.
Comment 8 Dmitry Kalyanov 2016-07-24 15:46:33 UTC
Created attachment 125291 [details] [review]
Proof-of-concept patch

I've solved this issue for myself - I've been using pulseaudio with my changes for several months now with no major problems.

I've noticed that every time signal degrades audio gets more out of sync - up to about 10-15 seconds (if I remember correctly).

I've debugged bluez5 pulseaudio module and suspect that the problem lies in buffering for bluetooth socket. Here's my analysis:

1) Pulseaudio detects BT signal drop when write() on bluetooth socket returns EAGAIN (i.e., when the buffer is full).
2) Bluetooth socket buffer is quite big (by default)
3) When pulseaudio stops sending audio packets to BT socket the buffer still contains a lot of packets
4) pulseaudio considers those packets as successfully sent - but they aren't
5) BT connection seems to never be able to "catch up" with the amount of buffered packets and audio becomes out-of-sync.

So here's my patch. The main change is to decrease the buffer size as much as possible. I've experimented and found out that settings buffer size to 2x-5x of packet size works best for me. This ensures that audio lag won't accumulate after BT signal degradation while preventing audio skipping due to buffer underruns. Audio still may skip (sometimes several times in a row) - but without the lag after BT signal restores.

Unfortunately with this patch bluetooth microphone (headset profile) won't work - since I don't use one and couldn't test it. I hope that someone would be able to pick it up and make into a form that would be possible to merge in master branch.

The changes are contained in attached path on github: https://github.com/dmitryvk/pulseaudio/commit/12b13c75d3a9b377e0f7de7c86116e3af41ce5ee. Patch was developed against Pulseaudio-8.0 but it works with Pulseaudio-9.0.
Comment 9 teppot 2016-09-11 08:23:51 UTC
Could someone please look at the attached patch. This bug is super annoying and essentially makes it impossible to use a Bluetooth headset to watch movies.
Comment 10 Tanu Kaskinen 2016-09-11 09:22:04 UTC
I have taken a look, but as the submitter himself says, it's not ready for merging. Someone needs to improve the patch so that it doesn't break stuff. I'm not volunteering to do that myself (at least any time soon). The general idea of reducing the socket buffer size seems good.
Comment 11 Dmitry Kalyanov 2016-10-13 09:30:53 UTC
I've recently found out that there exists SIOCOUTQ ioctl which supposedly should work on bluetooth sockets (I haven't verified this).
ioctl(.., SIOCOUTQ, ..) returns amount of bytes in send buffer.
Using it should be more reliable way than simply reducing buffer size.
Comment 12 Tanu Kaskinen 2016-10-29 17:31:05 UTC
*** Bug 95411 has been marked as a duplicate of this bug. ***
Comment 13 Sam Tyler 2017-01-07 15:59:01 UTC
Tried a patch from comment #8. 
The issue still persists but it happens less frequently with the patch. And instead of bluetooth disconnecting, I get messages like the following every second until I reconnect the bluetooth device manually.

module-bluez5-device.c: Skipping 32025 us (= 5648 bytes) in audio stream
Comment 14 paco3346 2017-01-16 16:02:49 UTC
(In reply to Dmitry Kalyanov from comment #8)
> Created attachment 125291 [details] [review] [review]
> Proof-of-concept patch
> 
> I've solved this issue for myself - I've been using pulseaudio with my
> changes for several months now with no major problems.
> 
> I've noticed that every time signal degrades audio gets more out of sync -
> up to about 10-15 seconds (if I remember correctly).
> 
> I've debugged bluez5 pulseaudio module and suspect that the problem lies in
> buffering for bluetooth socket. Here's my analysis:
> 
> 1) Pulseaudio detects BT signal drop when write() on bluetooth socket
> returns EAGAIN (i.e., when the buffer is full).
> 2) Bluetooth socket buffer is quite big (by default)
> 3) When pulseaudio stops sending audio packets to BT socket the buffer still
> contains a lot of packets
> 4) pulseaudio considers those packets as successfully sent - but they aren't
> 5) BT connection seems to never be able to "catch up" with the amount of
> buffered packets and audio becomes out-of-sync.
> 
> So here's my patch. The main change is to decrease the buffer size as much
> as possible. I've experimented and found out that settings buffer size to
> 2x-5x of packet size works best for me. This ensures that audio lag won't
> accumulate after BT signal degradation while preventing audio skipping due
> to buffer underruns. Audio still may skip (sometimes several times in a row)
> - but without the lag after BT signal restores.
> 
> Unfortunately with this patch bluetooth microphone (headset profile) won't
> work - since I don't use one and couldn't test it. I hope that someone would
> be able to pick it up and make into a form that would be possible to merge
> in master branch.
> 
> The changes are contained in attached path on github:
> https://github.com/dmitryvk/pulseaudio/commit/
> 12b13c75d3a9b377e0f7de7c86116e3af41ce5ee. Patch was developed against
> Pulseaudio-8.0 but it works with Pulseaudio-9.0.

Genius! I understand the problems with this patch but for now it's music to my ears (pun intended). Using on Arch with Pulseaudio 9.
Comment 15 Andrew McClure 2017-07-02 17:42:36 UTC
I have used a version of a workaround -- though not adopting the code below, instead having an auto resetting of the headset mode which is a work around. 

For the Pulseaudio developers -- I think the code that is causing this issue are around or between lines 1421 and 1503 of the below github code page for: module-bluez4-device.c

pulseaudio/src/modules/bluetooth/module-bluez5-device.c

https://github.com/pulseaudio/pulseaudio/blob/2417305ae755cbb3a92ca43a058f550809069cd9/src/modules/bluetooth/module-bluez5-device.c


The work around in the code seems to be about using a timer a to sync everything back up when a disruption occurs -- but either the timer is not working as intended, or the thresholds for the re-syncing process need to be considered. 



This is what I can gather but am interpreting as best I can. 

This is a common topic in troubleshooting boards for Bluetooth on linux distros.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.