On Sat, 2016-08-20 at 21:03 +0300, Tanu Kaskinen wrote: > On Sat, 2016-08-20 at 10:28 -0700, James Bottomley wrote: > > I actually ran into a problem with the approach. It's not really a > > pulseaudio problem per-se, it's a bluetooth/bluez one: bluez can't > > talk simultaneously to both HFP and HSP; once you connect to one > > "headset" profile at once and the connection to the other will > > fail. Right at the moment pulseaudio connects to each available > > profile so the audio switching can be fast. The problem is that > > the first connected profile for devices which support dual HFP/HSP > > will always be HFP (dictated by the ordering of the defaults array > > in bluez:src/profile.c) and the HSP connection will subsequently > > fail, so every dual HSP/HFP device would become HFP only with this > > patch (i.e. you won't be able to switch to HSP even if you want > > to). > > > > There are a couple of ways of fixing this: > > > > 1. Accept the limitation and disable HSP if the device supports > > both. > > The drawback would be any device that badly implements HFP > > but > > works currently with HSP (not sure if such devices exist). > > If it > > becomes a problem, HFP could be disabled with an option. > > 2. Don't register with bluez until the device is selected. This > > means > > all the negotiation and setup has to occur after the PA > > profile is > > selected which would lead to a noticeable slowdown in audio > > switching. > > > > Is there any preference (1. is certainly easier for me)? > > To clarify, is the problem that bluez has some arbitrary limitation > that it's not possible to connect both HFP and HSP? AFAIK bluetooth > doesn't allow two simultaneous audio streams, but I guess that's not > the problem here? No, the problem is establishing the rfcomm link. I *think* it's actually an intrinsic limitation of the device. > Would it be possible to fix this in bluez? (I'm not asking you to > fix it, I'm just trying to understand the situation - my old > understanding was that bluez would support connecting both > profiles.) I get a connection refused error directly from the device when I try to establish a HSP rfcomm link after establishing a HFP one, so I don't think bluez can work around this (except by managing the switching, I suppose, which would be complex). > I'm not sure how bluez advertises the supported profiles to other > devices, but if bluez doesn't advertise e.g. HSP support unless > pulseaudio has first registered the profile, then I don't think > option 2 is viable. Discovery gives us all the supported uuids and we then decide which ones to register profiles for, so we know as soon as the device is plugged in all the uuids for the profiles it supports. > Also, pulseaudio doesn't manage when profiles are connected or > disconnected, and starting to do that (and potentially stomping on > other components' toes) doesn't sound like a good idea. Yes, that's more my worry. > An option for disabling HFP seems much more feasible. OK, I'll code up option 1. James
