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

[Tanu Kaskinen]

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?

-- 
Tanu