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

[Tanu Kaskinen]

On Wed, 2012-11-28 at 16:25 +0200, Luiz Augusto von Dentz wrote:
> Hi David,
> 
> On Wed, Nov 28, 2012 at 12:14 PM, David Henningsson
> <david.henningsson at canonical.com> wrote:
> > On 11/27/2012 02:35 PM, Luiz Augusto von Dentz wrote:
> >>
> >> Hi Mikel,
> >>
> >> On Tue, Nov 27, 2012 at 9:12 AM, Mikel Astiz <mikel.astiz.oss at gmail.com>
> >> wrote:
> >>>
> >>> Hi Luiz,
> >>>
> >>> On Mon, Nov 26, 2012 at 9:17 PM, Luiz Augusto von Dentz
> >>> <luiz.dentz at gmail.com> wrote:
> >>>>
> >>>> Hi Mikel,
> >>>>
> >>>> On Mon, Nov 26, 2012 at 7:32 PM, Mikel Astiz <mikel.astiz.oss at gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
> >>>>>
> >>>>> This patchset extends the previous patch (resent unmodified here) with
> >>>>> the policy change suggested by Tanu.
> >>>>>
> >>>>> It seems no conclusion was reached about the names etc. but I believe
> >>>>> this is the best alternative without the form factor and in any case the
> >>>>> strings can easily be changed during/after pushing.
> >>>>>
> >>>>> Mikel Astiz (3):
> >>>>>    bluetooth: Merge headset ports into one
> >>>>>    bluetooth: Disable profile auto-switch policy for headsets
> >>>>>    conf: Load bluetooth-policy module by default
> >>>>>
> >>>>>   src/daemon/default.pa.in                        |  4 ++
> >>>>>   src/modules/bluetooth/module-bluetooth-device.c | 72
> >>>>> ++++++++++++++++++-------
> >>>>>   src/modules/bluetooth/module-bluetooth-policy.c |  4 ++
> >>>>>   3 files changed, 60 insertions(+), 20 deletions(-)
> >>>>>
> >>>>> --
> >>>>> 1.7.11.7
> >>>>
> >>>>
> >>>>
> >>>> I would like to see some good reasoning to do these changes, how we
> >>>
> >>>
> >>> There was a long IRC discussion about this and the conclusion was that
> >>> introducing independent ports for A2DP and HSP/HFP headsets was a
> >>> regression (as first pointed out in [1]). There was no general
> >>> consensus but this seems the most strict interpretation of a port,
> >>> which represents a physical device no matter the underlying protocols.
> >>
> >>
> >> Im not sure I follow, my interpretation was that the ports were per
> >> sinks/sources just as the sinks and sources are per profiles
> >
> >
> > This is no longer true - e g, on the ALSA side we have (since 1.0 or 2.0,
> > don't remember) shared ports for different profiles, e g, the "Analog
> > Output" port can be used with both a "Stereo" and a "5.1 Surround" profile.
> 
> Still don't see the problem, why we cannot have multiple output ports
> per card? Or this is because they show up/are selectable in the Output
> tab, because that I would assume is a bug and only ports which belongs
> to the active profile should be listed there.

The problem is not having multiple output ports per card, the problem is
having multiple output ports for the very same speakers. This is mainly
a user interface problem: the user shouldn't need to care about the
different bluetooth profiles when all he wants to do is "route music to
the bluetooth headset". We need a concept for a "routing endpoint".
Headset output is one routing endpoint, not two. We can discuss (after
the 3.0 release) if ports should be used as routing endpoints or whether
something else should be invented, but I think ports are close enough as
is to serve that role.

In any case, both of these things need to be possible: the user needs to
be able to say "route music to the bluetooth headset" without having to
select between A2DP and HSP, and the automatic policies need to be able
to distinguish between the A2DP and HSP "paths". I don't think ports can
alone serve both purposes.

-- 
Tanu