[pulseaudio-discuss] [PATCH v1 0/3] bluetooth: Headset port availability

[David Henningsson]

On 02/06/2013 12:48 PM, Tanu Kaskinen wrote:
> On Tue, 2013-02-05 at 08:44 +0100, David Henningsson wrote:
>> On 02/04/2013 05:06 PM, Tanu Kaskinen wrote:
>>> If the phone uses PulseAudio path configuration files for the ALSA
>>> configuration, the Bluetooth port could be flagged with a property. If
>>> the phone uses UCM, I think the UCM configuration should provide the
>>> information, and the port flagged accordingly. If an ALSA port is
>>> flagged that way, I guess alsa-card should not create a routing endpoint
>>> in that case. The endpoint would be created by module-bluetooth-device.
>>
>> Routing endpoints aside, if it is a technical impossibility / major
>> inconvenience to have a single port for a single physical entity, one
>> could have a port property "master-port" which would link the ports
>> together.
>
> I don't think the Bluetooth module would implement ports for HSP in this
> case, so there would be no master port to link to.

Why not? I mean, is this just a matter of "fixing" (you've previously 
talked about always having ports for all sinks/sources), or is there a 
good reason not to?

>> But how is exclusivity handled here? I mean, how would you encode the
>> fact that A2DP should not be used at the same time as HSP, if they don't
>> belong to the same card?
>
> The headset endpoint could keep the HSP sink and source suspended while
> the Bluetooth card has an A2DP profile active.If there are no Bluetooth
> cards, maybe the ALSA card should keep the HSP sink and source suspended
> until a Bluetooth card appears and takes control. When the Bluetooth
> card has the HSP profile active, there's no problem with concurrent HSP
> and A2DP use: in that case there are no A2DP sinks or sources at all.

I'm not sure I get this. What prevents a person (using e g pavucontrol 
or gnome sound settings) from:
1) Selecting A2DP profile for the BlueZ card
2) Selecting HSP profile for the ALSA card
3) Route one stream to the BlueZ card
4) Route another stream to the ALSA card

>> I mean, one of the basic properties of two different cards is that they
>> are independent of each other, if this is not the case, should we
>> consider merging the bluetooth and ALSA cards instead? (That is just
>> brainstorming, not an actual proposal)
>
> I don't think merging the cards is necessary, nor desirable. The ALSA
> card can have also other functions than being a gateway to the Bluetooth
> adapter, and those functions should be available regardless of whether
> there are any Bluetooth devices connected or not.The HSP port can't be
> separated from the ALSA card either, because those other functions may
> be mutually exclusive with the HSP port, so the ALSA card must know when
> the HSP port is being used.

So if we assume that (internal) speaker and HSP cannot be used at the 
same time, and that HSP and A2DP cannot be used at the same time. What's 
the conceptual difference between those two connections?

There is one: the fact that HSP and A2DP are routes to the same physical 
device, but that would point towards merging HSP and A2DP into the same 
card rather than merging HSP with speaker. But my brainstorming idea was 
to merge all three of them into the same card.

Let's remember an important point here: our mission is to make things 
convenient for our clients/end users, not ourselves. Our volume control 
GUIs must not need to make if statements for whether we happen to be on 
a BlueZ card on an ALSA card, ideally they would just choose what end 
device they want their audio streamed to. If that means solving one more 
hard problem in PulseAudio, I prefer that to having 10 different 
workarounds in 10 different client applications.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic