[pulseaudio-discuss] Setting Bluetooth headset connection to *both* A2DP _AND_ HSP at the same time?
Colin Guthrie
gmane at colin.guthr.ie
Wed Sep 14 06:24:21 PDT 2011
'Twas brillig, and Alexander Skwar at 14/09/11 11:25 did gyre and gimble:
>> Most headset cannot handle streaming simultaneously in both a2dp +
>> hfp, but it seems you only need one or the other and for that you can
>> use the card profile to switch.
>
> Well, this basically means, that it's not going to work at all, doesn't
> it? Reason:
>
> If headset/connection is in a2dp mode, I cannot select the headset as an
> input device. It's not offered. Thus I cannot configure my VoIP client
> to use the headset as an input device. If I were to configure my VoIP
> client, then the headset has to be in hsp/hfp profile. But that means
> crummy music. As soon as I'd switch to "music mode" (ie. a2dp), the VoIP
> client would lose the configured input device, wouldn't it?
>
> I base my assumption on the observation, that the input device "goes
> away", as soon as I switch to a2dp and comes back, when I go to hsp.
No, it does not mean it will not work at all. It just means that the
policy modules are not yet written to deal with this scenario gracefully.
What should happen is something like:
1. Bluetooth headset is the highest available device for the Music
category. In A2DP mode.
2. A new phone call stream is added (actually two streams one for
recording, one for playback).
3. A policy module noticed the new phone recording stream is present.
It knows that in your priory list for the Communications category, the
currently unavailable BT mic is the highest priority. The policy module
knows that this device can become available if the profile of the card
is changed to HSP mode, so it does that.
4. The music stream is likely rerouted to some other device (although
it might be paused/muted by some other policy module that does that kind
of stuff when you are on a phone call).
5. The actual voip streams can be wired up nicely.
So really this is not about using A2DP and HSP at the same time, it's
about graceful hand over from one mode to the other.
I didn't realise this was what you were asking initially otherwise I
would have commented on this before. I guess I was thrown off track by
the subject which was asking about a specific technical solution rather
than describing the the problem and asking what the technical solution
could be.
> This is with the Phonon backend of KDE 4.6.0 of openSUSE 11.4.
NB The phonon backend itself is irrelevant.
>> Yes, but iirc there is no audio policy to do this automatically for
>> you, so you gonna have to manually select the profile you want to use
>> e.g. for VoIP switch to hfp and for media player switch to a2dp.
>
> This "Yes" is a strong "No". I'd like to start _BOTH_ the music
> app (eg. Amarok) *AND* the VoIP client (eg. Ekiga) in the morning
> at the same time. Both apps are running all day long (in the case
> of Ekiga/VoIP, that's actually a must, because else I would not be
> reachable via VoIP).
Of course, and there is nothing in the above that is not solved by an
appropriate policy module that simply changes the profile when appropriate.
It's really not all that difficult. In fact you could easily wire up a
small script to your panel just now that flipped the profile for the
bluetooth device between A2DP and HSP so that when you answer a call,
you just click the "flip" launcher and the profile will change. And your
VOIP clients will automatically use the right mic and output device. So
it's only one extra click until you get the policy module in place,
which I don't think is too much hassle.
Of course there are some bugs in the phonon side of things that requires
a new release to fix up some recording device priority issues.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss
mailing list