Bug 99222 - ouput sound is not switched automatically to bluetooth headset
Summary: ouput sound is not switched automatically to bluetooth headset
Status: RESOLVED FIXED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: clients (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
: 99691 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-12-29 15:02 UTC by promeneur
Modified: 2017-04-19 09:56 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Change sink priorities (1.62 KB, patch)
2017-03-14 11:07 UTC, Christian Kellner
Details | Splinter Review

Description promeneur 2016-12-29 15:02:41 UTC
opensuse 42.2
pulseaudio 9.0
bluez 5.41
bluedevil 5.8.2

in kde multimedia settings headset is well listed and active

in pavucontrol headset is "default alternative" and port "headset(pluggeg in)"

when connecting headset via buetooth
then
sound is not automatically switched from loudspeaker to headset

in kde multimedia settings i must put in high priority headset according to get automatically sound switched to headset.
Comment 1 Christian Kellner 2017-03-02 17:43:03 UTC
The same is true for GNOME, connecting headphones does not automatically make them the default sink.
Comment 2 Christian Kellner 2017-03-03 14:54:37 UTC
Just to clarify the problem: Connecting wired headphones will automatically select these as default sink (source) for sound. Connecting bluetooth headphones will not. I see no reason why the latter should be treated differently then the former. Happy to help with this bug (info, debugging, coding).
Comment 3 Tanu Kaskinen 2017-03-03 16:11:27 UTC
(In reply to Christian Kellner from comment #2)
> Just to clarify the problem: Connecting wired headphones will automatically
> select these as default sink (source) for sound. Connecting bluetooth
> headphones will not. I see no reason why the latter should be treated
> differently then the former. Happy to help with this bug (info, debugging,
> coding).

Coding help would be welcome.

The problem is probably very simple: the bluetooth sink just has a lower priority than the analog output sink. The sink priorities are set in pa_device_init_priority(). That function seems to assign weird priorities (the form factor and bus attributes seem to get ranked in the exact opposite order than what I'd think would make sense), so you can probably fix the bug simply by adjusting the priorities to be more sane.

In the future the sink priorities will probably be replaced by port priorities, but I don't think you need to worry about that at this point. I've submitted a patch for that, but it's stuck in the review process. (I can't review my own patches, but if you submit a patch, I can review that.)
Comment 4 Christian Kellner 2017-03-09 16:41:36 UTC
Thanks Tanu for the feedback, I looked at pa_device_init_priority() and indeed it seems that the priorities listed there are almost inverted to what I would think makes sense (I am curious what the initial reasoning was for that). I did create a patch for it, tested it and it seems that this did indeed change the priorities for the internal sound device ("<alsa_card.pci-0000_00_1f.3>") but not for the bluetooth one ("bluez_card.04_52_C7_60_XX_XX>"). For the latter the port priority stayed at '20' [a2dp_sink: High Fidelity Playback (A2DP Sink) (priority 10, available: unknown)]. So after poking at the source for a while I think the priority is hardcoded at src/modules/bluetooth/module-bluez5-device.c:1808 (for A2DP source). For fun and testing I cranked that value up to 100k and it did indeed select the bluetooth headphones. It seems that the bluetooth module itself just sets the prio for its ports to a low value as 20?!
Comment 5 Tanu Kaskinen 2017-03-13 22:49:33 UTC
Sorry for the delayed reply.

> Thanks Tanu for the feedback, I looked at pa_device_init_priority() and
> indeed it seems that the priorities listed there are almost inverted to what
> I would think makes sense (I am curious what the initial reasoning was for
> that).

My guess would be that there was no good reason. The code has not been changed since it was first written, so the values aren't based on any long experience of tweaking the priorities to be just right.

> I did create a patch for it, tested it and it seems that this did
> indeed change the priorities for the internal sound device
> ("<alsa_card.pci-0000_00_1f.3>") but not for the bluetooth one
> ("bluez_card.04_52_C7_60_XX_XX>").

How did you check? The sink priority is only visible in "pacmd list-sinks" output.

> For the latter the port priority stayed
> at '20' [a2dp_sink: High Fidelity Playback (A2DP Sink) (priority 10,
> available: unknown)].

Was that '20' a typo? The priority for the a2dp_sink profile seems to be 10.

Note that there are three different priorities: sink priority, port priority and profile priority. Only the sink priority has effect on the default device selection.

I would expect the bluetooth port priorities to be 0, because I don't find any place in the bluetooth code that would configure the port priorities.

> So after poking at the source for a while I think the
> priority is hardcoded at src/modules/bluetooth/module-bluez5-device.c:1808
> (for A2DP source). For fun and testing I cranked that value up to 100k and
> it did indeed select the bluetooth headphones. It seems that the bluetooth
> module itself just sets the prio for its ports to a low value as 20?!

It sounds like you modified the profile priority. As far as I can tell, that shouldn't have effect on the sink priorities, and therefore it shouldn't have effect on the default sink selection either, so I'm very confused about what really happened.

When doing further tests, please comment out module-default-device-restore from /etc/pulse/default.pa. It can have surprising effects, and can make it look like your patch doesn't work. (The module is buggy, I'm working on fixing it.)
Comment 6 Tanu Kaskinen 2017-03-13 23:05:32 UTC
> When doing further tests, please comment out module-default-device-restore
> from /etc/pulse/default.pa.

Since you're running a self-compiled version, this is not necessarily right file path. Depending on the configure script parameters, the file might be in /usr/local/etc/pulse/default.pa. If configure is run without parameters, the prefix will be /usr/local, but if you let bootstrap.sh run the configure script, it will pass --sysconfdir=/etc, in which case /etc/pulse/default.pa is the right file.
Comment 7 Christian Kellner 2017-03-14 11:07:19 UTC
Created attachment 130212 [details] [review]
Change sink priorities

Tanu, no problem about the delay, I got plenty of things to work on :) - thanks for taking the time to look at this. Of course you were right about the 'module-default-device-restore' interfering. I thought I had worked around the default-device-restoring problem by removing my ~/.config/pulse directory but either I messed that up or with wasn't enough. Anyway, with the module commented out and the attached patch applied, the bluetooth headset gets selected as the default device on connect. The output of the pacmd list-sinks:

 sink(s) available.
    index: 0
	name: <alsa_output.pci-0000_00_1f.3.analog-stereo>
	driver: <module-alsa-card.c>
        [...]
	priority: 9439
        [...]
* index: 1
	name: <bluez_sink.04_52_C7_60_D8_82.a2dp_sink>
	driver: <module-bluez5-device.c>
        [...]
	priority: 9950
        [...]

I seem to not have any device around that is of the "speaker" form-factor, so I am not sure where in the hierarchy they should belong. But I am fairly certain that headphones should always be selected, and bluetooth and usb (being attached actively by the user) should also be preferred. Opinions? I also pinged Allan Day, UX/design expert, about this bug, maybe he also has some valuable input about the order.
Comment 8 Tanu Kaskinen 2017-03-31 14:14:55 UTC
Thanks, the patch looks good! I applied it now.
Comment 9 promeneur 2017-03-31 14:55:29 UTC
what version of pa will include the fix?

thanks
Comment 10 Tanu Kaskinen 2017-03-31 15:50:03 UTC
11.0, to be released in May or June.
Comment 11 Christian Kellner 2017-04-04 19:29:51 UTC
Just for completeness: I found two devices that are of form factor "Speaker", a bluetooth speaker and my Yamaha amplifier. Based on that I think the patch is fairly accurate currently, as I would prefer those over the internal things, but still prefer a headphone.

Another bluetooth speaker showed as form factor "protable", which is not even listed currently. I will create a small patch for that and assign them the same priority as "speaker".
Comment 12 Tanu Kaskinen 2017-04-19 09:56:14 UTC
*** Bug 99691 has been marked as a duplicate of this bug. ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.