Bug 99222

The same is true for GNOME, connecting headphones does not automatically make them the default sink.

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

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

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

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

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

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.

Thanks, the patch looks good! I applied it now.

what version of pa will include the fix?

thanks

11.0, to be released in May or June.

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

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