bluez icon indicating copy to clipboard operation
bluez copied to clipboard

Support for multipoint

Open phemmer opened this issue 1 year ago • 7 comments

I have bluetooth headphones which support multipoint connectivity (connecting to multiple audio sources simultaneously). Multipoint works in that only one audio source is emitted at any given time, but can be switched at any time as well. For example you might have your phone and PC connected to the headphones. You might be playing music on the PC, and then take a call, where you would stop hearing the music. I'm sure you're familiar with all this, but I'm not a bluetooth expert, so I figure it's best to clarify so we're on the same page.

Anyway this currently does not work well with Linux & Bluez. I can connect my headphones to multiple Bluez PCs (or Bluez & phone, whatever). However switching the audio source does not work well. Currently in order to switch the audio source, I have to change the audio profile on whichever PC I want to take over. It doesn't matter what I change the audio profile to, just as long as I change it.

I'm assuming that multipoint is supposed to work by the device that wants to emit sound issuing some sort of "takeover" command, but that Bluez isn't doing this. I'm guessing switching the audio profile works as it implicitly performs this "takeover".

So the request is to add proper support for multipoint. However I don't know what exactly that means. I don't know the internals between Pipewire & Bluez. I'm sure there's lots of complications, like when the PC loses control of the connection, the audio source should probably receive a "pause" signal or whatever. Or what if you're on a phone call, and something emits a beep sound? We probably don't want to switch from the call just because of a beep (I don't know of the protocol has some sort of "priority"). So I'll just leave it as an general "add support for multipoint" request, and let you decide what that means.
(Plus I hope this is even the right place. I couldn't find much on the subject. So apologies if it is not.)

phemmer avatar Jan 15 '24 00:01 phemmer

Works OK for me with Sennheiser HD 250 & phone & BlueZ/PW, and with Sony Linkbuds, and with two BlueZ/PW PCs, without any configuration.

AFAIK from MPS spec "multipoint" doesn't require audio sources to be aware they are in multipoint setup, just that an audio source needs to stop playback to allow a different one can play. The Linkbuds appears to also have some additional (vendor-specific?) control channel since the phone shows notifications when other playback starts; but HD250 doesn't have those.

The actual problem may be that "stopping playback" on PC does not actually occur, as it's not uncommon that some desktop apps keep outputting silence when idle or keep the sound card otherwise busy all the time. This then prevents multipoint switching. Generally, if you're running Pipewire, you can use pw-top to see if there's something that keeps the Bluetooth device occupied.

pv avatar Jan 15 '24 19:01 pv

The actual problem may be that "stopping playback" on PC does not actually occur, as it's not uncommon that some desktop apps keep outputting silence when idle or keep the sound card otherwise busy all the time. This then prevents multipoint switching. Generally, if you're running Pipewire, you can use pw-top to see if there's something that keeps the Bluetooth device occupied.

Issue is present even when there is nothing at all emitting any sound. pw-top shows nothing.

Also I wouldn't expect stopping playback to be a necessity. I can have something playing sound, change the audio profile on the other host, and it'll take over, without the audio on the original host stopping.

phemmer avatar Jan 15 '24 20:01 phemmer

Also I wouldn't expect stopping playback to be a necessity. I can have something playing sound, change the audio profile on the other host, and it'll take over, without the audio on the original host stopping.

Profile change does not do anything on HD250 or Linkbuds. I think that behavior is device specific.

Multipoint with two Android phones with HD250 does switch to when playback starts. Linkbuds does not switch, unless playback on the other phone is stopped first. The behavior seems to be device dependent on Android.

HD250 appears to rely on AVRCP player for this. Setting bluez5.dummy-avrcp-player = true in Pipewire bluetooth config adds an AVRCP player that changes state based on system playback status, and it replicates the Android behavior. However, the dummy AVRCP player being present breaks button functionality on some devices, so can't really be enabled by default.

pv avatar Jan 15 '24 21:01 pv

So I'm testing with SoundPEATS Air4 and Amazon Echo Buds 2023.

Interestingly setting bluez5.dummy-avrcp-player = true makes it worse with the echo buds. With that set, changing the audio profile no longer causes it to switch. However it continues to work on the air4.

Edit: Oh, and it does not fix the behavior otherwise.

phemmer avatar Jan 15 '24 22:01 phemmer

@phemmer have you tried changing the following configuration: https://github.com/bluez/bluez/blob/master/src/main.conf#L63

Vudentz avatar Jan 16 '24 13:01 Vudentz

@phemmer have you tried changing the following configuration: https://github.com/bluez/bluez/blob/master/src/main.conf#L63

No change in behavior with any value.

phemmer avatar Jan 16 '24 16:01 phemmer

I've been having this same issue and was able to fix it with @pv's help above.

I was able to see in pw-top that programs were keeping the bluetooth device occupied even after they stopped playing audio.

I set bluez5.dummy-avrcp-player = true in monitor.bluez.properties and restarted wireplumber.

Now I can see that programs stop keeping the bluetooth device occupied in pw-top and I can start playing audio from another device within a few seconds of pausing audio on my laptop. Thank you very much @pv!

FWIW I'm using Pixel Buds Pro which have decent multipoint support but no ability to manually disconnect them from a device via app like many 3rd party headphones do (e.g. Bose).

ccdunder avatar Sep 02 '24 23:09 ccdunder