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

[Mikel Astiz]

Hi,

On Wed, Nov 28, 2012 at 8:51 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> On Wed, 2012-11-28 at 16:42 +0200, Tanu Kaskinen wrote:
>> 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.
>
> I've changed my mind about the last point. Ports are not really that
> close to the ideal "routing endpoint" concept. For example, on cellular
> phones, pulseaudio may not have access to the actual audio data to and
> from the cellular modem. Modeling the cellular modem with sinks and
> sources doesn't therefore make much sense, in my opinion. Ports are
> pretty tightly coupled to sinks and sources, and I think it makes sense
> to keep things that way. It's still necessary to model the cellular
> modem routing somehow in pulseaudio, but ports don't seem like the best
> choice here.
>
> As another example, the bluetooth SCO link may be implemented as an alsa
> device. In this case there will be bluetooth ports on the alsa card,
> while the a2dp audio still goes through the bluez card. Merging the
> ports in this case isn't something that I'd want to try.
>
> Third example: on the N9, wired headphone output can be done through two
> alsa cards. It depends on the use case which one makes more sense. Like
> in the previous example, ports of two separate cards would have to be
> merged, if we wanted to make ports match 1:1 with physical endpoints.
>
>> 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.
>
> So, I'd like there to be a new concept for routing endpoints. The UI
> should work with those and ignore ports. This is not a new idea, Janos
> and Jaska from Intel have been working on routing, and that involves
> adding a new "routing node" concept. But I've understood that in their
> work there's strictly one routing node for each port, while I'd like it
> to be possible that one node represents multiple ports, or even zero
> ports (like in the cellular modem case). I'm not sure what they think
> about this.

An also from another message by Tanu:

On Thu, Dec 6, 2012 at 6:18 AM, Tanu Kaskinen <tanuk at iki.fi> wrote:

<snip>

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

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.

Cheers,
Mikel