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

[David Henningsson]

On 12/04/2012 05:07 AM, Tanu Kaskinen wrote:
> On Sun, 2012-12-02 at 22:33 +0200, Janos Kovacs wrote:
>> 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)'

I don't have one mono headset and a different stereo headset, I have one 
headset only. Therefore there should be only one row in the UI.

> The problem is that some people (me included) think that the UI should
> not have separate entries for high and low quality headset output. Why
> should the user care about the high/low quality distinction?

Exactly; the system, by default, should just choose what it think is 
best for the user.

In my world, a2dp output and hfp output are just two different edges 
between the same two nodes (the sink input and the headset port). Or 
maybe a property of the edge between the nodes.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic