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

[Mikel Astiz]

Hi Tanu,

On Wed, Feb 6, 2013 at 12:48 PM, Tanu Kaskinen <tanuk at iki.fi> 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.

I disagree. We could always represent the master "bluetooth-input" and
"bluetooth-output" ports in the Bluetooth module. Furthermore, despite
the PCM-based audio routing, both ports (master and
"secondary"/"slave" - we would need some terminology here) should
belong to the Bluetooth module in my opinion. This is the only way to
give some meaning to port availability, for example, since multiple
devices are represented in the alsa card (let's say multiple HSP/HFP
headsets are paired and connected).

This would also solve the UI issue, where the user could route a
stream to a port with some friendly name (associated to the name of
the Bluetooth device, instead of the alsa card).

>
>> 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.

As pointed out in my previous message, exclusivity could be handled in
the bluetooth card itself by means of the profile switch. This is
exactly the current approach does, also for PCM-based audio routing.

>> 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.
>
> --
> Tanu
>

Cheers,
Mikel