[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: Sudden death of bluetooth headphone connectivity

On 08/03, Mark Fletcher wrote:
On Thu, Aug 03, 2017 at 02:03:36PM +0100, stuart watt wrote:
On 08/03, Mark Fletcher wrote:
> Hello the list!
> Suddenly, earlier this week, my bluetooth headphones stopped working
> with Stretch.
> I update weekly, usually on Sundays, and I am not sure because I wasn't
> paying attention whether I had successfully used my headphones before
> the last update I did last Sunday.
> They definitely were working properly one week before that, when I used
> them with the computer just before going off on a week-long business
> trip.
> Anyway, I use Gnome. When I want to connect the headphones I turn them
> on, click on the network-like icon in the top right of the screen, click
> on "Not in Use" beside the Bluetooth icon, and then click on "Bluetooth
> Settings". (Is there a more efficient, involving fewer clicks, way to
> connect, by the way?)
> In Bluetooth Settings I can see my headphones as "BeoPlay H8". If I
> click on them it brings up the window with the slider switch to connect
> them. Normally, what would have happened is that clicking that switch
> would have connected the headphones. WHat happens now is the switch goes
> very briefly to the ON position, and then goes straight back to the OFF
> position. Removing / forgetting the device and re-pairing leads to the
> same result -- pairing is successful, but cannot connect.
> With journalctl -f running in a terminal while trying to connect I see
> the following at the moment of clicking the slider switch to connect the
> headphones: a2dp-sink profile connect failed for AA:BB:CC:DD:EE:FF:
> Protocol not available
> <bluetooth address elided, it is actually a sensible-looking bluetooth address>
> Now, call me a super-sleuth, but I suspect that Protocol Not Available
> error could be something to do with the problem ;)
> To re-iterate, this was working until recently, and all I've done is
> install regular updates using apt update / apt upgrade.
> Where should I start looking?
> [Full disclosure -- I previously had a different problem on upgrading to
> Stretch from Jessie -- see this link for that problem and a link to its
> solution --> https://lists.debian.org/debian-user/2017/06/msg01196.html
> I have never been particularly happy with the solution I linked to in
> that thread, precisely because I was worried it would be damaged by
> updates, but it seems to be intact at this point, so I don't think that
> is what the problem is here]
> Thanks in advance if anyone can help me diagnose the sudden loss of the
> a2dp-sink protocol. The headphones work fine with my iPhone, so the
> problem seems to be with the computer, with which they were working fine
> until a bit over a week ago.
> Mark

Pulseaudio? If so what does pavucontrol say

Did Bluez updates come through? maybe pulseaudio-bluetooth module?


Of course, pavucontrol says nothing, because the headphones have not
been able to connect yet. As soon as they connect, the adp_sink error
disconnects them again, as I described in my original post.

The problem, I've got to think, is upstream of pulseaudio, no?

I don't know if bluez updates came through. There is no
pulseaudio-bluetooth package in Stretch -- there is a

>pulseaudio-module-bluetooth package, which is installed.

Just to check, I've just done another apt update and then apt list
--upgradeable to have a look at what would get installed now -- most of
it is to do with the freerdp security update from earlier this week,
nothing relating to pulse or bluetooth.

Thanks again



What BT chipset are you using, have you acccidently disabled it in BIOS? Nothing shows up in google about protocol not available but there was a bug in gnome 3.24 and pulseaudio 10 with gnome/GDM where GDM starts its own pulseaudio instance. https://wiki.archlinux.org/index.php/Bluetooth_headset#Gnome_with_GDM

I don't run gnome on debian but i do on arch, i didn't find the gnome BT stack particularily stable so i used blueman-applet as a backup in the cases gnome BT wouldn't work with my FSL360. see blueman & bluez-utils packages in stretch.

Blueman-applet allows you see if the device is trusted & paired and to perform those functions if you wish. It also identifies the BT adapter in use which should appear in lsusb.

If that's no further help look up the Arch wiki section on bluetoothctl [from bluez-utils]. 99% of the time the issues i had were BT getting confused about adapters.

Attachment: signature.asc
Description: PGP signature

Reply to: