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