[pulseaudio-discuss] Setting Bluetooth headset connection to *both* A2DP _AND_ HSP at the same time?

[Colin Guthrie]

'Twas brillig, and Alexander Skwar at 14/09/11 14:59 did gyre and gimble:
> Hello,
> 
> On Wed, Sep 14, 2011 at 15:24, Colin Guthrie <gmane at colin.guthr.ie
> <mailto:gmane at colin.guthr.ie>> wrote:
> 
>     'Twas brillig, and Alexander Skwar at 14/09/11 11:25 did gyre and
>     gimble:
> 
>  
> 
>     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.
> 
> 
> Hm. I think it's also about how to setup the VoIP app to use
> an input device, which it doesn't see (in A2DP mode, there's
> no "mic on headset" device which could be selected).

Nah that's not actually that important. When the policy stuff is all in
place, the mic will appear automatically when you first receive a call,
and, if the policy is correctly written, it should automatically use
that device for the VoIP app. We already have some policy modules in PA
that will automatically use headset devices for voip apps, so this isn't
exactly a massive leap.

>     > This is with the Phonon backend of KDE 4.6.0 of openSUSE 11.4.
> 
>     NB The phonon backend itself is irrelevant.
> 
> 
> Is it? I don't know - in Phonon, I cannot select the headset as
> an input device, because it's just greyed out (as long as it is
> in A2DP mode). I don't know what's the cause of this limitation,
> Phonon, PulseAudio, Bluez…

Nothing is the "cause of this limitation", it's just how things work.
You obviously can't select a device that's not present. It's like trying
to use a USB device that isn't currently plugged in - it's the same
principle.

But the whole device list you see comes directly from PulseAudio (I
know, I wrote all that code!), so as I said, the Phonon backend itself
is irrelevant (of course you didn't actually say *what* phonon backend
you are using (typically GStreamer or VLC) but as I say it's irrelevant)

>     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. 
> 
> 
> I think that this is too late. In the VoIP app, I need to configure
> which device is to be used for getting the input ("where's the
> microphone", so to say).

No you don't. You can happily move streams around after the event. If
I'm using a bluetooth headset and the batteries run flat, it doesn't
disconnect the call, we just move the streams around to different devices.

In an ideal world the app wouldn't have any UI to select devices, you
should IMO just rely on your Desktop Environment (i.e. the preference
lists in Phonon) to select which devices you want to use.

> If BT is in A2DP mode, I cannot set it so, that the app uses the
> headset as the input device which is to be used.

Well the app is trying to be too clever. it shouldn't really try and use
a specific device. It should just let PA do the routing. As Michał said,
the routing is in PA's hands, the App shouldn't try and outsmart us -
doing so breaks policy and automatic/graceful handover to the right
device should it become available later.

>     And your
>     VOIP clients will automatically use the right mic and output device. So
> 
> 
> Will they? How? I mean, you'll have to specify which mic/output
> device to use, don't you?

No, you most certainly shouldn't have to pick specific devices to use.
You should really let PA handle which devices to use and you can of
course move things around using a PA mixer like pavucontrol where you
can see the Playback and Recording streams and move them to different
devices at any time, mid-call.

> In A2DP mode, the app doesn't have any input device at all (ie.
> it's using the one from the on-motherboard-chip). Now a call comes
> in. I fear that I'm not fast enough to
> 
> 1) Fire the script and
> 2) Reconfigure the app

Step 2 is unnecessary.

All you'd have to do is fire the script and by virtue of the mic
becoming available, it'll be automatically used. Provided the app isn't
doing something totally weird, all of this should just work happily.

I quite often accept e.g. Skype calls before I can find my BT Headset.
It starts off on my computer speakers+mic, but as soon as I flip open my
BT headset the streams just move across to it. I don't have to do
anything other than that! (my BT Headset is only in HSP mode, so that's
why you'd need this extra "profile flipper" script until we can handle
this in policy.


>     it's only one extra click until you get the policy module in place,
>     which I don't think is too much hassle.
> 
> 
> I think it's a two step process, where the 2nd step can take
> quite some time.

I think you're making a couple incorrect assumptions about how things
work! :p

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/]