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

[David Henningsson]

On 02/04/2013 04:07 PM, Tanu Kaskinen wrote:
> On Mon, 2013-02-04 at 15:50 +0100, David Henningsson wrote:
>> On 02/04/2013 03:44 PM, Tanu Kaskinen wrote:
>>>>> I don't think merging ports with sinks/sources is the most relevant
>>>>> question here. The question is how to simultaneously present a Bluetooth
>>>>> headset as a single routing endpoint to the user and have means to
>>>>> sufficiently distinguish between A2DP and HSP inside PulseAudio.
>>>>
>>>> I haven't fully understood the problem with having merged ports for A2DP
>>>> and HSP - there are still different sources and sinks, so one could just
>>>> look at the current active sink if that's what you need to know.
>>>>
>>>> I do understand that if something was modelled in one way, and then we
>>>> had to do an emergency fix because the model caused regressions in the
>>>> UI, the fixups become ugly as a result. What I don't know yet is why
>>>> multiple ports for A2DP and HSP would be a better model inside
>>>> PulseAudio from start?
>>>>
>>>>> I have proposed that we use the routing nodes of the policy work done by
>>>>> Janos and Jaska to represent the headset as a single routing endpoint,
>>>>> and associate multiple ports (A2DP and HSP) with that routing endpoint.
>>>>> I would like to reach a consensus about this proposal. Is it ok for
>>>>> everybody? David? Janos? Jaska? Please comment.
>>>>
>>>> It is difficult to have an opinion without knowing more about the
>>>> routing framework and what a routing endpoint really is. But even if
>>>> this proposal gets implemented, still somebody needs to rewrite the UI
>>>> to use routing endpoints instead of ports - which should be an argument
>>>> against this proposal in the first place.
>>>
>>> Mikel knows the details of the problem that he's working on right now,
>>> I'll repeat an argument that I have stated earlier: sometimes the
>>> Bluetooth setup is such that the HSP audio is routed through ALSA and
>>> the A2DP audio is routed through BlueZ. Having a single port for the
>>> headset is problematic in this scenario. I'd rather have a separate
>>> "routing endpoint" concept for representing the headset. Do you prefer
>>> merging ports even in this case?
>>
>> 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?

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


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