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

[Janos Kovacs]

Hi,

On Wed, Nov 28, 2012 at 9:51 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:

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

Indeed one idea behind 'routing node's is that a routing nodes can also
represent something which is not implemented by a sink, source or a port.
Such way we could handle all routing scenarios in a uniform way including
DSP scenarios where media streams will not always lead through PA
(phone call).

Currently a node can be just a sink/source without port or a port on a
sink/source.

The sinks of a BT headsets (eg. 'hfp' and 'a2dp' sink) are mapped to
different nodes in our upcoming PoC. However, we have constrains
that make mutually exclusive the two node. Routing is priority list based,
so if a higher priority stream routes to the SCO node than the contstrain
will make the A2DP node unavailable for lower priority streams.
Similarly, in case a speaker and a wired headset were behind
different ports of the same sink, constrains will make unavailable the
wired headset for lower priority streams if a higher priority stream were
routed to speakers.

Constrains also could be used to handle the multiple routing paths
described in example 3. The alternative paths might appear as
different nodes, say 'speaker low quality' and 'speaker high quality'
and a constrain would ensure the mutual exclusiveness. So, if  a
stream were routed to 'high quality speaker', other streams, with lower
priority, would not go to 'low quality speaker' due to the constrain.

In other words, our current thinking is to make flat routing policy and
map SCO and A2DP to different nodes with constrains as opposed
to have a generic BT-headset node with SCO and A2DP modes.

Such flat routing policy maps quite nicely to the priority list based
automatic routing (what we discussed last November). IMO it is
also reasonable for UI base explicit routing. So, for instance, the
UI could show a routing target list:
   'speakers',
   'bluetooth headset (mono / low quality)'
   'bluetooth headset (stereo / HiFi)'

Anyways this is fairly complex, so we try to pull together the PoC which
will make easier to to talk about the whole thing.

br
-janos-