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

[Tanu Kaskinen]

On Mon, 2013-02-04 at 15:46 +0200, 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:
> > > 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.

After some discussion in IRC, it looks like something like this might be
acceptable to everyone (well, the involved parties have been just Mikel,
David and me):

Keep ports as the concept that represents the physical device, e.g. a
Bluetooth headset. This ensures that existing applications don't need to
be changed.

Create a new concept for "connections to ports", e.g. A2DP output and
HSP output. One name for this concept that has been used is "slave
port", but I'd really want to use something with no "port" in the name.
Suggestions are very welcome. My suggestion is "route".

Does this have anything to do with the policy system that Janos and
Jaska proposed? Not much. This proposal doesn't require the "node"
concept, and doesn't conflict with it either (so it's still something
I'd like to have). Ports would be nodes, as originally planned.
Information needed for conflict resolution would have to be attached to
the "route" objects instead of nodes (for example, the A2DP routes
conflict with the same card's HSP routes).

-- 
Tanu