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

[David Henningsson]

On 02/04/2013 02:46 PM, Tanu Kaskinen wrote:
> On Mon, 2013-02-04 at 10:43 +0100, David Henningsson wrote:
>> On 02/04/2013 09:59 AM, Mikel Astiz wrote:
>>> On Wed, Nov 28, 2012 at 8:51 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
>>>> Yes, I've held the opinion for quite some time now that sinks/sources
>>>> should be merged with ports. It's a big change and doesn't bring any new
>>>> features in itself, so I don't consider it as a high-priority thing, but
>>>> patches are welcome.
>>>
>>> Is there any ongoing effort to move this forward? Is there a consensus
>>> about the 1:1 mapping between ports and sink/sources?
>>
>> No, and no.
>>
>>> We decided Immediately before 3.0 that some Bluetooth ports should be
>>> merged (commit 40329acc1a28145643e49207e9d65cd05bbda2c8) but this is
>>> basically UI-oriented and not very convenient for internal use, as
>>> already discussed.
>>>
>>> In this case, I was tracking down a issue we have in
>>> module-bluetooth-device, and the solution would be much simpler if we
>>> had independent ports.
>>
>> 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.


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