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

[Mikel Astiz]

Hi Tanu,

On Tue, Dec 4, 2012 at 2:42 PM, David Henningsson
<david.henningsson at canonical.com> wrote:
> 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.

What's the reason to have such a strict mapping between ports and sink/sources?

If this could be relaxed, and ports could be associated to multiple
sink/sources, then it's possible that the routing would be using
sink/sources, while the ports would be representing physical devices
and thus shown in the UI.

This could avoid adding this new "routing node", which introduces a
third abstraction layer with concepts that are very close to each
other.

Otherwise, if this 1:1 mapping between ports and sink/sources is so
strict, wouldn't it make sense to merge them?

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

Cheers,
Mikel