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

[David Henningsson]

On 02/04/2013 03:44 PM, Tanu Kaskinen wrote:
> On Mon, 2013-02-04 at 15:05 +0100, David Henningsson wrote:
>> On 02/04/2013 02:46 PM, Tanu Kaskinen wrote:
>>> On Mon, 2013-02-04 at 10:43 +0100, David Henningsson wrote:
>>>> So; if port are merged with sinks/sources, I assume you would like this
>>>> merged object to be once per stream (i e different for a2dp and
>>>> hfp/hsp), which would again break the UI?
>>>>
>>>> This looks like a problem with the approach of trying to merge ports and
>>>> sinks/sources.
>>>
>>> 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)?


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