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

[Tanu Kaskinen]

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

-- 
Tanu