Bluetooth audio problem

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Bluetooth audio problem

Mark Fletcher-2
Hello

Since upgrading to Stretch shortly after it became stable, I have had to
execute the following after a reboot before being able to connect to
bluetooth devices using the Gnome bluetooth applet:

$ sudo pactl load-module module-bluetooth-discover

Without that command, needed once only after each reboot, the Gnome
applet is unable to connect to any bluetooth audio devices, eg my
headphones to be used as an audio sink, or my iPhone to be used as an
audio source. Once that command has been issued once, everything works
as it should, and continues to do so until the next reboot.

I've been away for a couple of weeks and so hadn't installed updates to
my stretch installation for something like 3 weeks, until Saturday this
week when I installed updates. Unfortunately I didn't pay enough
attention to exactly what was upgraded but I _believe_ I saw udev in the
list of things getting upgraded.

Now, when I run the above command it is erroring out with:

xcb_connection_has_error() returned true
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

Googling for this has only turned up old information which does not seem
to relate to the problem I am facing. In most cases the context is audio
not working; in my case audio output through speakers plugged into the
sound card is working fine, USB mic connected by a wire is working
fine, the only problem is anything bluetooth.

Bluetooth on this machine is provided by a USB bluetooth dongle which I
have been using for ages.

Can anyone suggest steps to diagnose?

TIA

Mark

Reply | Threaded
Open this post in threaded view
|

Re: Bluetooth audio problem

deloptes-2
Mark Fletcher wrote:

> Hello
>
> Since upgrading to Stretch shortly after it became stable, I have had to
> execute the following after a reboot before being able to connect to
> bluetooth devices using the Gnome bluetooth applet:
>
> $ sudo pactl load-module module-bluetooth-discover
>
> Without that command, needed once only after each reboot, the Gnome
> applet is unable to connect to any bluetooth audio devices, eg my
> headphones to be used as an audio sink, or my iPhone to be used as an
> audio source. Once that command has been issued once, everything works
> as it should, and continues to do so until the next reboot.
>
> I've been away for a couple of weeks and so hadn't installed updates to
> my stretch installation for something like 3 weeks, until Saturday this
> week when I installed updates. Unfortunately I didn't pay enough
> attention to exactly what was upgraded but I _believe_ I saw udev in the
> list of things getting upgraded.
>
> Now, when I run the above command it is erroring out with:
>
> xcb_connection_has_error() returned true
> Connection failure: Connection refused
> pa_context_connect() failed: Connection refused
>
> Googling for this has only turned up old information which does not seem
> to relate to the problem I am facing. In most cases the context is audio
> not working; in my case audio output through speakers plugged into the
> sound card is working fine, USB mic connected by a wire is working
> fine, the only problem is anything bluetooth.
>
> Bluetooth on this machine is provided by a USB bluetooth dongle which I
> have been using for ages.
>
> Can anyone suggest steps to diagnose?
>


When I want to debug pulse I do

echo "autospawn = no" > ~/.pulse/client.conf

kill PA and run it from command line with -v option you can also
use --log-level (man pulseaudio)

perhaps you can see what is the problem there. If not it might be dbus issue
with permissions - check the dbus settings

Also some times it helps to remove the ~/.pulse directory and restart
pulseaudio.

regards

Reply | Threaded
Open this post in threaded view
|

Re: Bluetooth audio problem

Mark Fletcher-2
On Sun, Mar 03, 2019 at 06:04:05PM +0100, deloptes wrote:

> Mark Fletcher wrote:
>
> > Hello
> >
> > Since upgrading to Stretch shortly after it became stable, I have had to
> > execute the following after a reboot before being able to connect to
> > bluetooth devices using the Gnome bluetooth applet:
> >
> > $ sudo pactl load-module module-bluetooth-discover
> >

<self-snip (ouch!)>

> > Now, when I run the above command it is erroring out with:
> >
> > xcb_connection_has_error() returned true
> > Connection failure: Connection refused
> > pa_context_connect() failed: Connection refused
> >
>
>
> When I want to debug pulse I do
>
> echo "autospawn = no" > ~/.pulse/client.conf
>
> kill PA and run it from command line with -v option you can also
> use --log-level (man pulseaudio)
>
> perhaps you can see what is the problem there. If not it might be dbus issue
> with permissions - check the dbus settings
>
> Also some times it helps to remove the ~/.pulse directory and restart
> pulseaudio.
>

So this turned out to be a weirdie -- if I dropped the "sudo" my
original command worked.

So now, suddenly from that update that started this thread, if I run the
pactl command as an unprivileged user, it works fine. I have no idea why
it changed but I'm just happy I have it working again.

Mark

Reply | Threaded
Open this post in threaded view
|

Re: Bluetooth audio problem

deloptes-2
Mark Fletcher wrote:

> So this turned out to be a weirdie -- if I dropped the "sudo" my
> original command worked.
>
> So now, suddenly from that update that started this thread, if I run the
> pactl command as an unprivileged user, it works fine. I have no idea why
> it changed but I'm just happy I have it working again.

you can mark also as solved, if solved

Reply | Threaded
Open this post in threaded view
|

Re: Bluetooth audio problem

Mark Fletcher-2
On Fri, Mar 22, 2019 at 08:44:46PM +0100, deloptes wrote:

> Mark Fletcher wrote:
>
> > So this turned out to be a weirdie -- if I dropped the "sudo" my
> > original command worked.
> >
> > So now, suddenly from that update that started this thread, if I run the
> > pactl command as an unprivileged user, it works fine. I have no idea why
> > it changed but I'm just happy I have it working again.
>
> you can mark also as solved, if solved
>

True, I could have. But I don't think it will kill interested people who
follow after to read a 3-mail thread to see the resolution.

Reply | Threaded
Open this post in threaded view
|

Re: Bluetooth audio problem

Nicholas Geovanis-2
In reply to this post by Mark Fletcher-2
On Fri, Mar 22, 2019 at 9:29 AM Mark Fletcher <[hidden email]> wrote:

So this turned out to be a weirdie -- if I dropped the "sudo" my
original command worked.
So now, suddenly from that update that started this thread, if I run the
pactl command as an unprivileged user, it works fine.

Is it possible that you had previously started pulseaudio as root, and could no longer communicate with it as an unprivileged user? 
I ask this having been a pulseaudio victim myself sometimes.
 
Mark

Reply | Threaded
Open this post in threaded view
|

Re: Bluetooth audio problem

Mark Fletcher-2
On Sat, Mar 23, 2019 at 08:24:30AM -0500, Nicholas Geovanis wrote:

> On Fri, Mar 22, 2019 at 9:29 AM Mark Fletcher <[hidden email]> wrote:
>
> >
> > So this turned out to be a weirdie -- if I dropped the "sudo" my
> > original command worked.
> > So now, suddenly from that update that started this thread, if I run the
> > pactl command as an unprivileged user, it works fine.
>
>
> Is it possible that you had previously started pulseaudio as root, and
> could no longer communicate with it as an unprivileged user?
> I ask this having been a pulseaudio victim myself sometimes.
>
>

Hmm, interesting idea, but the situation I was previously in pertained
over a period since Stretch became Stable until shortly before my
original mail in this thread (sometime in February if I recall
correctly). Over, naturally, multiple reboots.

For that period, I had to use sudo when issuing the pactl command (in
Jessie and previously, the pactl command wasn't necessary at all).

So I guess I could have had some sort of configuration which repeatedly
put me in that situation on every reboot, and the update that "created
the problem" actually fixed whatever *that* problem was... otherwise, no
I don't think so.

Thanks for the suggestion though

Mark