It might very well be somewhere other than Pulseaudio that this bug surfaces.  But there's sure to be many experts on A2DP and the Linux stack for that here.

Well, I'm still experiencing this bug on ArchLinux with stock kernel 4.13. If you check link that Bogdan attached, you'll find a lot of affected users. Can I somehow help with debugging?

In my experience the problem is usually that the radio communication is being interfered by something. Wifi is often the cause, so you can try to unload the wifi kernel module and check if A2DP streaming gets any less skippy.

I won't close this bug, because I can't prove that this is not a PulseAudio bug, but I'm not going to debug this if there's no clear indication that PulseAudio is doing something wrong (with the currently available information I wouldn't know how to debug this anyway).

Created attachment 135020 [details]
attachment-5046-0.html

The problem is that on same laptop with same hardware and environment, but
using windows, there are no such issue. So the problem is related to
pulseaudio or kernel drivers or both

24 окт. 2017 г. 16:30 пользователь <bugzilla-daemon@freedesktop.org>
написал:

> *Comment # 3 <https://bugs.freedesktop.org/show_bug.cgi?id=88827#c3> on
> bug 88827 <https://bugs.freedesktop.org/show_bug.cgi?id=88827> from Tanu
> Kaskinen <tanuk@iki.fi> *
>
> In my experience the problem is usually that the radio communication is being
> interfered by something. Wifi is often the cause, so you can try to unload the
> wifi kernel module and check if A2DP streaming gets any less skippy.
>
> I won't close this bug, because I can't prove that this is not a PulseAudio
> bug, but I'm not going to debug this if there's no clear indication that
> PulseAudio is doing something wrong (with the currently available information I
> wouldn't know how to debug this anyway).
>
> ------------------------------
> You are receiving this mail because:
>
>    - You reported the bug.
>
>

(In reply to Tanu Kaskinen from comment #3)
> In my experience the problem is usually that the radio communication is
> being interfered by something. Wifi is often the cause, so you can try to
> unload the wifi kernel module and check if A2DP streaming gets any less
> skippy.
> 
> I won't close this bug, because I can't prove that this is not a PulseAudio
> bug, but I'm not going to debug this if there's no clear indication that
> PulseAudio is doing something wrong (with the currently available
> information I wouldn't know how to debug this anyway).

Sorry but this is irritating.
You're basically saying "prove me wrong" or I will not into the hottest and longest standing bug currently attributed to Pulseaudio.
You may be right, it might be a kernel or a driver bug, but at the very least you should look into it.
It seems that there is no shortage of people/system/goodwill to help you track it.

Regards,

Interesting. I installed 17.10 and initially Bluetooth worked so much better than it had with 16.04 (I had basically given up using it).

Then I re-installed to eliminate any of my changes as a contributor to a different issue and now Bluetooth stutters again. I would say it is worse than before.

I turned off wireless and it did not help. I did not unload the wifi kernel module - Bluetooth simply  needs to work with wifi enabled.

What needs to be done to continue troubleshooting the issue?

(In reply to R Schultz from comment #6)
> What needs to be done to continue troubleshooting the issue?

I think it would be good to gather detailed timestamped data about the various events that are related to bluetooth streaming. The "Skipping NNN us (= MMM bytes) in audio stream" log message that is mentioned in the Ubuntu bug title suggests that the buffer behind the bluetooth socket stays full for prolonged periods, so PulseAudio is simply unable to write any data. It would be good to verify this with hard data.

Someone could try changing the A2DP writing logic so that PulseAudio would always write immediately when the socket becomes writable. That would eliminate the possibility that PulseAudio doesn't write fast enough. module-sine could be used for testing, because that module should be able to provide data no matter how weird the sink timing is (I'm worried that regular applications might have trouble keeping their buffers filled if the bluetooth writes happen in big bursts).

If it turns out that there are drop-outs no matter how quickly PulseAudio writes data, then the next step would be to investigate at the kernel side.

(In reply to Tanu Kaskinen from comment #7)
> I think it would be good to gather detailed timestamped data about the
> various events that are related to bluetooth streaming.

I forgot to elaborate on what I mean by this. The interesting events are when the bluetooth socket becomes writable and when PulseAudio writes to the socket (the amount that is written each time should be logged too). It should be possible to generate some kind of a graph from the data that will show irregularities (like if PulseAudio is writing less data than expected).

i'm using ubuntu 17.10 (single boot) on a macbookpro early 2015 (12,1 model).
i have the apple airpods. they work fantastic with my android phone.

on linux though, it's another story. "it works" but the result is awful. useless.
first, there's lot of time it is not able to connect. it fails. then i retry 5, 6 times and then it connects. when it works: audio is skipping, making long pauses, choppy sound most of the time. and i must stay close to the laptop or signal is lost.

- using bluetooth headset on osx and android (both unixes) is a really good experience. they both perform really well.

- using bluetooth headset on linux with pulseaudio is a terrible experience.

What we are finding in Ubuntu is that this problem seems to be specific to certain wifi kernel modules that are not yet adequately careful to avoid clobbering their own bluetooth signals...

ath9k:
Workaround available and fix on the way.
https://bugs.launchpad.net/bugs/1746164

wl (bcmwl/bcmwl-kernel-source and probably broadcom-sta):
No fix is known.
https://bugs.launchpad.net/bugs/1518408

iwlwifi:
No problems reported(?). The Intel wifi driver already handles it properly.

It's possible the buffering or error checking could be done better in userland, but I don't know any of the internals of PulseAudio/BlueZ. Nor can I reproduce the problem myself.

P.S. I *think* Macbooks generally use Broadcom chips so are likely to fall into the 'wl' category. You can check by running 'lspci -k'.

Fixed in bug 58746 ...?

Maybe this is now a duplicate.

Did you test? I am unsure if the rewrite fixed your issue.

It's not my issue and I have never experienced it.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/77.