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

[Mikel Astiz]

Hi David,

On Tue, Feb 5, 2013 at 8:44 AM, David Henningsson
<david.henningsson at canonical.com> wrote:
> On 02/04/2013 05:06 PM, Tanu Kaskinen wrote:
>>
>> On Mon, 2013-02-04 at 16:30 +0100, David Henningsson wrote:
>>>
>>> On 02/04/2013 04:07 PM, Tanu Kaskinen wrote:
>>>>
>>>> On Mon, 2013-02-04 at 15:50 +0100, David Henningsson wrote:
>>>>>
>>>>> If A2DP and HSP audio go through different sound cards, we have no
>>>>> possibility to merge them right now.
>>>>>
>>>>> Not that I have ever seen such a setup. Can it happen on desktop/laptop
>>>>> computers you buy in the store, or only on highly specialised embedded
>>>>> environments (which are likely to have their own UI anyway)?
>>>>
>>>>
>>>> I have no idea about desktop/laptop machines. I know that 100% of
>>>> smartphones that I've worked with (i.e. 3 Nokia models) have used ALSA
>>>> for HSP,
>>>
>>>
>>> ...and at the same time BlueZ for A2DP? Or everything through ALSA?
>>
>>
>> At the same time BlueZ for A2DP.
>>
>>>> but I expect there to be phones that use the "normal"
>>>> everything-through-BlueZ setup. I don't consider phone UIs any more
>>>> specialized than desktop UIs: in both cases, one UI codebase should work
>>>> with a wide variety of hardware. I don't think the Ubuntu Phone UI
>>>> developers, for example, want to care about the Bluetooth hardware
>>>> details.
>>>
>>>
>>> Okay, so how would PulseAudio autodetect that HSP and A2DP, even though
>>> belonging to different cards, actually are connections to the same
>>> physical headset?
>>
>>
>> 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.

Sounds good to me. So if I get this right, any port with such a
property would be considered a "secondary" port, and therefore the UI
would not show it, right?

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

This exclusivity can be represented with the profile switch in
module-bluetooth-device, as it's currently done. If HSP/HFP audio
(SCO) is implemented alsa-based (PCM routing), the module should have
a pointer to the SCO sink/sources. See module parameters "sco_sink"
and "sco_source".

With this "master-port" approach, I believe these parameters should be
replaced by something like "sco_input_port" and "sco_output_port".

>
> 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)
>
>
>>
>> module-bluetooth-device in turn knows whether to use the ALSA port for
>> its routing endpoint based on the Routing property of MediaTransport1.
>> If the routing is "PCM" (as opposed to the normal "HCI"), it should
>> search for an ALSA port with the magic property, and if found, associate
>> that port with the new routing endpoint.
>>

Cheers,
Mikel