A2DP Bluetooth audio skips terribly ["Skipping NNN us (= MMM bytes) in audio stream"]

Bug #405294 reported by volkris on 2009-07-27
594
This bug affects 122 people
Affects Status Importance Assigned to Milestone
PulseAudio
Fix Released
Medium
pulseaudio (Ubuntu)
High
Alberto Milone
Nominated for Xenial by Daniel van Vugt
Bionic
High
Alberto Milone

Bug Description

SRU Request:

[Impact]
When the connection drops temporarily, using A2DP, a noticeable latency is introduced, and the audio goes out of sync.

[Test Case]
1) Enable the -proposed repository, and install the new pulseaudio

2) Restart your computer, connect it to a bluetooth device (e.g. a headset or a speaker), play one or more videos either locally or online, and see if you can still reproduce the problem.

[Regression Potential]
Low, as the changes are upstream, and, if anything, it should also fix a memory leak.

Furthermore, the changes only affect the bluez5-device module, in pulseaudio, and they make the buffer updating logic more conscious of how things can change when the connection drops. This is unlikely to affect anything else in pulseaudio.

____________________________________________________________________
As I upgraded to the Karmic alpha, bluetooth audio (via a2dp) stopped working properly. It was working fine in Jaunty.

My headphones are detected and configured by pulse, but the audio skips as if it's spending half of each second paused. Music is buffered so that after I click stop on rhythmbox (or whatever--it happens with whatever player I use) the audio continues until it's caught up.

syslog is full of the following lines:
Jul 27 08:55:45 carlin1 pulseaudio[3218]: alsa-source.c: Increasing minimal latency to 1.00 ms
Jul 27 08:55:46 carlin1 pulseaudio[3218]: module-bluetooth-device.c: Skipping 15128 us (= 2668 bytes) in audio stream
Jul 27 08:55:46 carlin1 pulseaudio[3218]: module-bluetooth-device.c: Skipping 36586 us (= 6452 bytes) in audio stream
Jul 27 08:55:46 carlin1 pulseaudio[3218]: module-bluetooth-device.c: Skipping 35593 us (= 6276 bytes) in audio stream
Jul 27 08:55:46 carlin1 pulseaudio[3218]: module-bluetooth-device.c: Skipping 36597 us (= 6452 bytes) in audio stream
Jul 27 08:55:46 carlin1 pulseaudio[3218]: module-bluetooth-device.c: Skipping 32601 us (= 5748 bytes) in audio stream
Jul 27 08:55:46 carlin1 pulseaudio[3218]: module-bluetooth-device.c: Skipping 32589 us (= 5748 bytes) in audio stream

This is with
bluez 4.45-0ubuntu4
pulseaudio 1:0.9.15-4ubuntu2 0

pulseaudio version 1:0.9.16~test2-0ubuntu1~ppa3 from ubuntu-audio-dev didn't help.

volkris (volkris) wrote :

Adding the work done in pulseaudio's bugtracker

Changed in pulseaudio:
importance: Undecided → Unknown
status: New → Unknown

On Wed, Aug 5, 2009 at 1:19 PM, Chris Carlin<email address hidden> wrote:
> Adding the work done in pulseaudio's bugtracker

See if 0.9.16-test4 alleviates the symptoms. Make sure you have rtkit
installed, too.

Changed in pulseaudio:
status: Unknown → New

Where can I find -test4? I've been following the ubuntu-audio-dev ppa and see only -test3

On Wed, Aug 5, 2009 at 2:07 PM, Chris Carlin<email address hidden> wrote:
> Where can I find -test4? I've been following the ubuntu-audio-dev ppa
> and see only -test3

pulseaudio 1:0.9.16~test4-0ubuntu1 and rtkit 0.4-0ubuntu1 are in karmic.

Luke Yelavich (themuso) wrote :

Note that rtkit is currently no use until the kernel side lands, which will likely require me to get the patches included in the Ubuntu kernel.

1:0.9.16~test4-0ubuntu1 didn't help.

Could this be related to the lack of rtkit?

On Thu, Aug 6, 2009 at 1:38 PM, Chris Carlin<email address hidden> wrote:
> 1:0.9.16~test4-0ubuntu1 didn't help.
>
> Could this be related to the lack of rtkit?

More effectively, the lack of the linux patch to which Luke refers. In
the meantime, you can try adding the audio group to have RT privileges
using /etc/security/limits.conf.

Updated to bluez 4.47-0ubuntu1 along with the distro. No difference.

On Sat, Aug 8, 2009 at 6:16 PM, Chris Carlin<email address hidden> wrote:
> Updated to bluez 4.47-0ubuntu1 along with the distro. No difference.

Have you made the recommended modifications to /etc/security/limits.conf?

Yes, I made the modifications and there was a difference: syslog started showing the "skipping..." messages more quickly :)

To be precise, they came at the same rate, but there used to be a larger pause before the first one appeared.

Marcin Szałowicz (lolek) wrote :

ok, i'll join to this bug... i can say that i have also problem with the a2dp profile in jaunty...
the first ghing is that i must connect to myh a2dp device manually (this is not a problkem for me).. but.. after that for about 1 horu of listening music... the next songs are played.. slowly... i mean.. the sound is like an old vinyl disc... (the black one).. you know what i mean?...
well it occurs more offen while lonhger i'm listening through the a2dp device.. if i reboot the ubuntu (reloading alsa doesn't help)... everything is fine for.. about an hour...

volkris (volkris) wrote :

Offhand, I'd say it sounds like a different bug. My problem is in karmic, which uses the native bluetooth, your is in Jaunty, which probably uses alsa; my problem is immediate, yours takes an hour; my problem is skips, yours is slowness.

Do you see messages in syslog about skipping bytes?

I'm using A2DP with Bluez through Pulseaudio like this:

I've got blueman from the daily-ppa for karmic, with the pulseaudio plugin activated and it works well!
Dunno whether it's because of my pulseaudio configurations but I just had to disable 2 of 3 profiles at pavucontrol - I think pa was connected to more than 1 profile on my headset, that why I had no sound before :)

give it a try - it works ( for me ;) )

volkris (volkris) wrote :

Interesting!

I was able to get the thing to work by doing something like connecting through PA's autodiscover, then disconnecting through blueman, then reconnecting through blueman's "Connect A2DP" command.

I'll have to repeat this process in the future to figure out exactly which steps make it work, but for the moment I'm not going to touch it.

Kzin (wmkzin) wrote :

Question; do you also have a bluetooth mouse/keyboard or any other bluetooth devices you use at the same time as the headset?

Kzin (wmkzin) wrote :

Chris Carlin;
Could you direct me to the software/command line arguments you used to do this?

volkris (volkris) wrote :

I used to use a bluetooth mouse; A2DP would skip the same regardless of whether I was using the mouse. As a previous commenter said, I believe it had something to do withbluez or pulseaudio getting confused when A2DP and headset profiles were both available.

blueman is available through the normal repository. sudo apt-get install blueman

Kzin (wmkzin) wrote :

Fantastic, thanks.
By PA's autodiscover, are you just referring to the system>preferences>sound?

I have been doing a lot of digging on this one and it would seem that there is some problem with PA and the kernel. These links all seem to be related to this issue;
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/406702
http://<email address hidden>/msg02783.html

What do you think?

If that's truly the issue, you can try adding the audio group with rt
privileges to /etc/security/limits.conf.

PA's autodiscover is a feature where when the computer's bluetooth connects to an audio device, PA will automatically connect to the device as well. Without autodiscover the user had to manually tell PA that the device was there. It's all behind the scenes stuff not related to preferences>sound

I suspect that bluetooth is reporting headphones that can do both A2DP and headset modes, and PA autodiscovery is trying to configure for both at once, leading to this issue. Through blueman we can connect only A2DP, so autodiscovery only sees A2DP and the confusion is bypassed. That's my theory, at least.

The realtime (rtkit) stuff may be a problem, but it's not causing this problem. In fact, the pulseaudio people I've talked to are baffled that these "skipping bytes" messages are showing up even with PA isn't supposed to be sending bytes in the first place.

Kzin (wmkzin) wrote :

Ok my issue may be different than yours I suppose.
Using blueman fixes it so/so, I can disable the headset profile and have A2DP running. And it smooths out if I don't use the mouse long enough for it to enter sleep mode. I note that the ul/dl counters on blueman are at 27.5 kb/s up and 428 b/s down while listening to A2DP audio. The moment I wiggle the mouse or click any buttons the upstream drops to 2 then raises to about 12 kb/s and downstream 1.4 b/s.
At this point I am willing to take the pulseaudio dev's suggestion that perhaps I have a crappy dongle... I am using the Logitech Bluetooth 2.0 EDR dongle that came with the MX5000 Keyboard/Mouse combo.
Still it is kind of odd that the bitrate drops like mad when I use the mouse.
I suppose I could test this theory by using the headset with this dongle & mouse combo in (ugh) Wintendos and see if I get the same behaviour.

Thanks for taking the time to reply, Chris.

Kzin (wmkzin) wrote :

Just an update,
Updated the firmware on my Dongle. That did not resolve the issue. If I turn off the mouse and wait for a while, works fine. Using USB wired mouse instead doesn't interrupt playback.
Will update you on how this works in Windtendos when I get a chance. I may just go for 2 separate dongles at once. Wonder if that can be done?

volkris (volkris) wrote :

My issue was really defined by looking at the logs and seeing those messages about skipping bytes. If you don't see those messages, then I think it is a different matter.

One last thing you might try is using blueman to disconnect all audio connections to your headphones before adding A2DP back. I believe one time it was not enough to simply disconnect the headset profile; it had to start with a blank slate. Pause for a few seconds before adding A2DP back to make sure PA autodetection has time to notice the change.

Anyway, message me separately from this bug and I can try to give you some pointers about getting the mouse and headphones working. I don't want to dilute this bug with issues not related to the actual bug.

Kzin (wmkzin) wrote :

>My issue was really defined by looking at the logs and seeing those messages about skipping
>bytes. If you don't see those messages, then I think it is a different matter.

Yes, I have these messages. Was just trying to collate everything I found that seemed to be related to the issue.

Kzin (wmkzin) wrote :

Update;
I noticed updates to pulseaudio and bluetooth packages, problem persists after update.

omriasta (omri) wrote :

Kzin, Have the same issue as you. Working with EEEPC 1002HA internal bluetooth, Microsoft 5000 mouse and Motorola S9-HD headset. A2DP works great if I don't use the mouse, the second I wiggle the mouse, audio starts skipping, get the same messages about skipping in the syslog. Have Dual Boot and the issue does not exist in Windows XP (it's not a bad BT dongle or hardware/distance related). Any suggestions?

Kzin (wmkzin) wrote :

I have 2 mice hooked up to my machine. One USB and one wireless bluetooth. When I am not listening to headphones or they are charging, I use the wireless mouse. When I use them I turn off the wireless BT mouse and use the wired one =/.
Not much of a workaround but it's all I can do. I have another dongle on order, hoping I can get them on 2 separate channels somehow.
I can also confirm that this issue does not affect Wintendoes.

Kzin (wmkzin) wrote :

Its like the bandwidth is going only as fast as the slowest device or something, note post #21

Kzin (wmkzin) wrote :

Ok,
So I have a separate bluetooth dongle now, as in 2 on the computer. Keep the keyboard and mouse on one, and the headphones on the other. This works smoothly.
Again, not a very elegant workaround, but in my scenario, once the devs sort out the issue I can use the new usb bluetooth dongle on another computer, so I don't really come out short in the end.

Neil Green (neil-r-green) wrote :

I am seeing this exact same problem with Karmic. I'm using a bluetooth mouse and an A2DP headset. If I turn the mouse off the audio works perfectly well. When I turn on the mouse, syslog fills up with lines like

Nov 6 13:43:00 lenny pulseaudio[2544]: module-bluetooth-device.c: Skipping 5364 us (= 944 bytes) in audio stream

and the audio is punctuated by long silences.

The mouse is a Microsoft Wireless Presenter 8000, the headset a Jabra BT620s and the bluetooth adapter is Dell Wireless 360 Bluetooth (builtin). It doesn't seem to be a hardware related issue as I use the same hardware in Vista without issue.

Luciano (luciano) wrote :

Just wanted to add my two cents worth ...

I spent most of the day trying to figure out why this was happening.

This is definitely not a PA problem. It also occurs using ALSA with the bluetooth plugin.

This is a problem at the bluetooth stack level.

As stated above, it appears that it has something to do with the fact both A2DP and hsc are enabled simultaneously. I also was able to work around it using blueman and connecting/disconnecting the different profiles. However, before that I changed some settings on the bluez daemon configuration. Otherwise the blueman trick doesn't work. I have the following settings in audio.conf:

#[General]
Enable=Source,Control,Sink
Disable=Headset,Gateway
AutoConnect=false

#[Headset]
HFP=true
MaxConnected=1

And the following link setup (from hciconfig -a) :From this should be able to work out what goes in hcid.conf
hci0: Type: USB
 BD Address: 00:90:CC:ED:35:10 ACL MTU: 310:10 SCO MTU: 64:8
 UP RUNNING PSCAN
 RX bytes:119527 acl:77 sco:0 events:16505 errors:0
 TX bytes:4916687 acl:15925 sco:0 commands:553 errors:0
 Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
 Link policy: RSWITCH HOLD SNIFF PARK
 Link mode: SLAVE ACCEPT
 Class: 0x5a010c
 Service Classes: Networking, Capturing, Object Transfer, Telephony
 Device Class: Computer, Laptop
 HCI Ver: 1.2 (0x2) HCI Rev: 0xc5c LMP Ver: 1.2 (0x2) LMP Subver: 0xc5c
 Manufacturer: Cambridge Silicon Radio (10)
hcid.conf:

lp rswitch,hold,sniff,park;
lm accept,master;

I'm running bluez 4.58 and pulseaudio 0.9.19 on a gentoo distro.
I know this should probably be raised as a bluez issue, but this is the only place I could find the exact same issue, so I thought I would post here. Sorry!

Finally, could you let me know what headset you were using? I have a pretty old HT820 motorola...

volkris (volkris) wrote :

I'm surprised that it happened for you using the alsa bluetooth module. It worked fine for me with the alsa module, but maybe that was the previous version various libraries shipped with the previous ubuntu.

I'm using Motorola headphones a swell, S620 or something like that.

Also check out the following bug: http://pulseaudio.org/ticket/612

I get this as well on a set of headphones from Sony, model DR-BT50. Used to work in Jaunty, now doesn't work in Karmic. Get the messages in the log and so forth.

I don't currently have any other BT devices connected so there is no interference as such, but I do guess that it gets recognized as both a headset and a a2dp device, as it is both.

I see that there are some workarounds involving setting configurations and then using extra programs - is there any way to simply set this once and for all, such as disabling the non-a2dp part?

xby (xby) wrote :

Hello,

I had the exact same problem and I found this in the bluez wiki :
You may get choppiness with a2dp. An hcid.conf with "lm accept,master;" and "lp hold,sniff,park;" will be more robust. For BlueZ 4.x, which has no hcid.conf, you will have to do something like 'hciconfig hci0 lm master; hciconfig hci0 lp hold,sniff,park' after bluetoothd starts up (or write a patch ;).

So I tried
sudo hciconfig hci0 lm master; sudo hciconfig hci0 lp hold,sniff,park

And it works well ! Does it work for you as well ?

The bad part is that you have to type it in everytime you restart your computer. Any idea how to do it automatically ? I was used to init.d but I can't figure out how upstart works.

Kzin (wmkzin) wrote :

Tried the hciconfig thing, now this happens

Dec 28 09:24:53 IT pulseaudio[4094]: module-bluetooth-device.c: Skipping 61160 us (= 10788 bytes) in audio stream
Dec 28 09:24:58 IT bluetoothd[1359]: Suspend request timed out
Dec 28 09:24:58 IT bluetoothd[1359]: suspend failed
Dec 28 09:24:58 IT pulseaudio[4094]: module-bluetooth-device.c: Received error condition: Input/output error
Dec 28 09:24:58 IT bluetoothd[1359]: Transaction label doesn't match
Dec 28 09:24:58 IT bluetoothd[1359]: SUSPEND request rejected: Bad State (49)

Kzin (wmkzin) wrote :

Amendment, if I may...
hci0 turned out to be the device I added in post #29. I just removed this device and did the same for hci1. This seems to have helped the issue greatly. I no longer get the syslog spam and the horrible skipping seems to have stopped.

Thank you, xby, you are on to something.

Kzin (wmkzin) wrote :

xby,
I wrote a startup script that handles this at boot time. There is not a lot of documentation that I can find on this, aside from man. So yea I warn you this is not likely the way to run an action at boot time, more like a service. But it works for me.
I put the attached file in my /etc/init.d/ folder and gave it the +x permission.
I then ran "sudo inssrv -nf /etc/initd/bluetooth-a2dphack".
It all looked ok so then I ran without the -n "sudo inssrv -f /etc/initd/bluetooth-a2dphack"

Nothing is configurable or dynamic, hardcoded, bad bad bad. I know, but it worked for me. If someone wants to fix this properly, or tell me how, I'll listen =). Provided without warranty etc etc.

A warning, while researching on how to use insserv, some people reported that it messed up their runlevels to the point that certain services like cups wouldn't start. Not sure that this will be the case for you, but you can look into it yourself. Worked fine for me.

hth

Kzin (wmkzin) wrote :

Bah, post was full of mistakes,
inssrv should be insserv
initd should be init.d

Luciano (luciano) wrote :

Another update on my previous post about bluez configuration. It turns out that the key thing here are the settings in hcid.conf:

lp rswitch,hold,sniff,park;
lm accept,master;

and audio.conf:

AutoConnect=false;

this one to prevent both a2dp and headset profiles connecting at the same time, when you turn it on.

Note that what I had previously set in audio.conf:
#Enable=Source,Control,Sink
#Disable=Headset,Gateway

is not a good idea. The 'Disable=Headset' removes the headset profile form the available services on the headphones altogether. i.e. you can't connect to 'headset' anymore. only a2dp.

Finally, if you want to have the headset profile work with pulseaudio (for e.g. skype), you need to use blueman, and make sure the bluetooth applet is enabled (in about -> plugins). The a2dp doesn't seem to need this, but the headset profile does.

Hope that made sense ...

volkris (volkris) wrote :

I'm terribly sorry to say none of the above workarounds seems to solve this for me.

AutoConnect=false seems to do nothing at all

Disable=Headset,Gateway at least keeps the HSP from connecting, but then A2DP doesn't connect automatically either. I can connect it manually through blueman, and at least I don't have to worry about disconnecting both A2DP and HSP before reconnecting A2DP, but then I have to enable A2DP in pulse as well.

Ah well...

Daniel T Chen (crimsun) on 2010-03-06
Changed in pulseaudio (Ubuntu):
status: New → Invalid
volkris (volkris) on 2010-03-24
Changed in pulseaudio (Ubuntu):
status: Invalid → New
Daniel T Chen (crimsun) on 2010-03-24
Changed in pulseaudio (Ubuntu):
status: New → Invalid
Daniel T Chen (crimsun) on 2010-03-24
Changed in pulseaudio (Ubuntu):
status: Invalid → Incomplete
papukaija (papukaija) on 2010-08-10
summary: - a2dp skips terribly in Karmic
+ a2dp skips terribly
tags: added: karmic lucid
loko (arph) on 2011-02-19
Changed in pulseaudio (Ubuntu):
status: Incomplete → Confirmed
status: Confirmed → Incomplete
Changed in bluez (Ubuntu):
status: New → Confirmed
amias (amias) on 2011-10-31
tags: added: maverick natty oneiric
isden (isden) on 2012-04-15
tags: added: precise
141 comments hidden view all 221 comments

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.

dino99 (9d9) on 2013-05-04
tags: removed: karmic lucid maverick natty oneiric
Lorant Nemeth (loci) on 2013-05-10
Changed in pulseaudio (Ubuntu):
status: Incomplete → New
status: New → Confirmed
tags: added: raring
Changed in pulseaudio:
status: New → Unknown
Changed in pulseaudio:
importance: Unknown → Medium
status: Unknown → Confirmed

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/

If you want audio sync with video after audio transmission is broken, you need the application to skip some audio and restart audio playback

Shouldn't the buffer reset after detecting a skip event?

(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.

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.

(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?

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.

Created attachment 125291
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.

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.

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.

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.

*** Bug 95411 has been marked as a duplicate of this bug. ***

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

(In reply to Dmitry Kalyanov from comment #8)
> 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.

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.

Changed in bluez (Ubuntu):
importance: Undecided → High
Changed in pulseaudio (Ubuntu):
importance: Undecided → High
tags: added: xenial zesty
summary: - a2dp skips terribly
+ A2DP Bluetooth audio skips terribly
tags: added: yakkety
summary: - A2DP Bluetooth audio skips terribly
+ A2DP Bluetooth audio skips terribly ["Skipping NNN us (= MMM bytes) in
+ audio stream"]
tags: added: a2dp
Changed in pulseaudio (Ubuntu):
assignee: nobody → Daniel van Vugt (vanvugt)
assignee: Daniel van Vugt (vanvugt) → nobody

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.

*** Bug 102989 has been marked as a duplicate of this bug. ***

Changed in linux (Ubuntu):
status: New → Confirmed

This bug is extremely annoying during calls, when resetting the audio profile (as suggested as workaround by several people) can disrupt the call / cause feedback. How has this been open for over 5 years?

Any guidance what we could do to help get the patch merged or an alternative fix developed ? Would testing the patch be enough or needs more research ?

Or can the maintainers not reproduce the issue yet ?

Let us know :-)

(In reply to Vincent Petry from comment #18)
> Any guidance what we could do to help get the patch merged or an alternative
> fix developed ? Would testing the patch be enough or needs more research ?

See comment #10, I think the comment answers all your questions. If you can't improve the patch yourself or find someone else to do it, I don't think there's anything you can do.

> Or can the maintainers not reproduce the issue yet ?

Speaking only for myself here: bluetooth works so badly on my machine that testing anything is a huge pain, if possible at all. For that reason I don't work much on bluetooth issues (and there's no shortage of other work).

So are you saying that getting you a new machine (or a working setup) is also a possible approach ? :-D

(In reply to Vincent Petry from comment #20)
> So are you saying that getting you a new machine (or a working setup) is
> also a possible approach ? :-D

I suppose so :) Now that I think about it, I have another machine that I could and should try first, so don't send me stuff yet!

I have more urgent things to work on first, though, so I don't expect progress on this in the near future.

Created attachment 137440
patch: rewrite of thread function

Could you try if the attached patch fixes your issues?

Created attachment 137477
patch: rewrite of thread function

Sorry, I had other patches in my tree, so the posted patch would not apply cleanly to current master. Here an updated version.

Changed in bluez (Ubuntu):
status: Confirmed → Incomplete
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Changed in pulseaudio (Ubuntu):
status: Confirmed → Incomplete
Changed in bluez (Ubuntu):
status: Incomplete → Invalid
Changed in linux (Ubuntu):
status: Incomplete → Invalid
Changed in pulseaudio (Ubuntu):
status: Incomplete → Invalid
tags: added: a2dp-skip

Nobody willing to test?

(In reply to Georg Chini from comment #24)
> Nobody willing to test?

I have tested the patch with a pair of Mackie CR4BT bluetooth speakers that suffers from the lag issues after they reconnect. That patch was applied 7f09164e and built as part of the [pulseaudio-git] AUR package.

When the computer initiate connection with the speakers (i.e. `echo connect MAC | bluetoothctl`) everything works fine, but every few seconds the logs are flooded with 1000s of these messages:

  [bluetooth] module-bluez5-device.c: Broken kernel: we got EAGAIN on write() after POLLOUT!

When the speakers initiate the connection they disconnect after about a second (even before they start making sound), and when the speakers disconnects (either a second after they connected or if I turn them off after computer initiated the connection) pulseaudio aborts with:

  [bluetooth] module-bluez5-device.c: Skipping 2176 us (= 384 bytes) in audio stream
  [bluetooth] module-bluez5-device.c: Assertion 'u->write_memchunk.length == u->write_block_size' failed at modules/bluetooth/module-bluez5-device.c:437, function a2dp_process_render(). Aborting.

I only observe the out-of-sync audio problems when the connection is initiated by the audio device (e.g. power on, pushing their connect buttons, after signal loss). I am happy to test further patches, but I do not see any means to reproduce the problem as long as pulseaudio aborts whenever any of my devices tries to reconnect.

I also have a Bose QC35 and a RHA MA 650 Wireless headset to test with, but they usually take longer to suffer from audio sync problems than the Mackie CR4BT speakers. I tested the patch with the headsets to, and they observed the same crashing behavior as when I tested it with the speakers.

BTW, as a workaround until the problem is fixed I have a script I use whenever I notice audio sync problems that disconnect then reconnects the device, so that it is the computer that initiated the connection. This seems to work consistently and avoids the problem until there are intermittent connection problem (e.g. I walk too far away from the computer with a headset) or I turn off and on the audio devices.

[pulseaudio-git] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pulseaudio-git

Thanks for testing. I can not reproduce your problems here with both of my headsets using current master. Can you please send a full log from the moment you press the connect button on your BT device, so that I can see what happens?

Created attachment 137779
patch: rewrite of thread function

I think I figured out what went wrong. Could you give the updated patch a try? If it still causes problems, please send a log as requested earlier.

(In reply to Georg Chini from comment #27)
> Could you give the updated patch a try?

I tried the new patch. With it I do not get any aborts. Additionally I am getting way fewer of these messages:

  [bluetooth][modules/bluetooth/module-bluez5-device.c:1464 write_block()] Broken kernel: we got EAGAIN on write() after POLLOUT! (libpulsecommon-11.0.so(+0x414e7) [0x7f6f7492b4e7]<<libpulsecommon-11.0.so(pa_log_levelv_meta+0x4af) [0x7f6f7492beb9])

And most importantly, I cannot reproduce the audio sync issues. I have tried to have my Mackie CR4BT speakers autoconnect when they power on, which caused audio sync problems for me almost immediately before. Along with moving so far away from the computer with my headsets that the sound crackles and disappears, and then moving back before the device disconnects.

Thanks again for testing. Sounds good. Regarding those broken kernel messages, do you only get them once in a while or still annoyingly often? It is just a warning message, so if it's annoying I could drop it completely.

(In reply to Georg Chini from comment #29)
> Thanks again for testing. Sounds good.

You are welcome. Thanks for making bluetooth audio usable in linux.

> Regarding those broken kernel messages, do you only get them once in a while or still annoyingly often?

I seem to only get them when there are intermittent signal problems, so it is not annoyingly often.

Changed in pulseaudio:
importance: Medium → Unknown
status: Confirmed → Unknown
Changed in pulseaudio (Ubuntu):
status: Invalid → Triaged
no longer affects: bluez (Ubuntu)
no longer affects: linux (Ubuntu)
Changed in pulseaudio:
importance: Unknown → Medium
status: Unknown → Confirmed

Created attachment 138573
patch: rewrite of thread function

Could you test this updated patch? There have been a few changes due to review and I want to make sure that it still works.

(In reply to Georg Chini from comment #31)
> Could you test this updated patch?

Sure, I have applied the new patch to b1d74c86, and it seems to work as well as the previous patch. Also, I have yet to see any warning messages in the system log.

I had the previous patch running since the start of march and I did not notice any new problems. I will be running with the new patch from now on, and I will report if I notice any further problems.

Perfect. Thanks a lot for your tests.

(In reply to Georg Chini from comment #31)
> Created attachment 138573 [details]
> patch: rewrite of thread function
>
> Could you test this updated patch? There have been a few changes due to
> review and I want to make sure that it still works.

I have tried this patch (applied against pulseaudio 11.1 in Debian unstable, it applies with fuzz but works) and I saw a great improvement! My bluetooth chip is very susceptible to interferences, it was common for me to have a few seconds of delays. With this patch, the delay stays small at all times. The fact that it drops samples more aggressively was not noticeable for me because on drop out the speaker just stops anyway. I did not get any warning in the log, just debug messages about skipping.

Thank you for your work, I hope it will make it to mainline.

(In reply to Georg Chini from comment #31)
> Created attachment 138573 [details]
> patch: rewrite of thread function
>
> Could you test this updated patch? There have been a few changes due to
> review and I want to make sure that it still works.

Thank you very much for the patch!

I also was having loss of audio sync. This patch solved the problem.

Occasionaly will still delay the audio, but before the delay was something like 3-4 seconds, now the worst case that I have seen so far is a couple tens of milliseconds (very small and ok for music and films).

Tested on Arch linux, patch applied to the latest version of Pulseaudio on github (last commit Apr 19, 2018), zero problems applying the patch.

Thank you all for testing. The patch is in master now and will be part of the 12.0 release. I will (finally, after five and a half years) close this bug.

Changed in pulseaudio:
status: Confirmed → Fix Released
Changed in pulseaudio (Ubuntu):
assignee: nobody → Alberto Milone (albertomilone)
status: Triaged → In Progress
Changed in pulseaudio (Ubuntu Bionic):
status: New → Triaged
importance: Undecided → High
assignee: nobody → Alberto Milone (albertomilone)
Changed in pulseaudio (Ubuntu Bionic):
status: Triaged → In Progress
description: updated
Changed in pulseaudio (Ubuntu):
status: In Progress → Fix Committed
Changed in pulseaudio (Ubuntu):
status: Fix Committed → Fix Released
description: updated
Changed in pulseaudio (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-bionic
tags: added: verification-done-bionic
removed: verification-needed-bionic
tags: removed: verification-needed
Changed in pulseaudio (Ubuntu Bionic):
status: Fix Committed → Fix Released

OMG. You are my favorite people ever.

I can confirm that this path fixes _all_ of my out of sync issues. I run a 2015 MBP on which the bluetooth and Wifi share the same antenna. When running on a 2.4Ghz network I have little blips when there's interference but the audio doesn't get out of sync.

Also, my connection issues are gone. Previously I'd need to re-pair the headset nearly every time otherwise the connection would close almost immediately.

Furthermore- HFP/HSP _finally_ works!! I can actually use my mic now! This is just the best day.

Justin Jia (abscii) wrote :

I still have this problem, Anybody running the latest pulseaudio on Raspberry Pi or CM3? I'm using pulseaudio 12.2 with bluez 5.50.

After I connected to a Bluetooth speaker. When play something, it's really choppy and skipping a lot. The debug message shows:

D: [bluetooth] module-bluez5-device.c: Skipping 43083 us (= 7600 bytes) in audio stream

Daniel van Vugt (vanvugt) wrote :

This bug is closed. Please log a new bug by running:

  ubuntu-bug pulseaudio

Displaying first 40 and last 40 comments. View all 221 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.