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
