Hi, On Wed, Nov 28, 2012 at 8:51 PM, Tanu Kaskinen <tanuk at iki.fi> wrote: > 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. An also from another message by Tanu: On Thu, Dec 6, 2012 at 6:18 AM, Tanu Kaskinen <tanuk at iki.fi> wrote: <snip> > Yes, I've held the opinion for quite some time now that sinks/sources > should be merged with ports. It's a big change and doesn't bring any new > features in itself, so I don't consider it as a high-priority thing, but > patches are welcome. Is there any ongoing effort to move this forward? Is there a consensus about the 1:1 mapping between ports and sink/sources? We decided Immediately before 3.0 that some Bluetooth ports should be merged (commit 40329acc1a28145643e49207e9d65cd05bbda2c8) but this is basically UI-oriented and not very convenient for internal use, as already discussed. In this case, I was tracking down a issue we have in module-bluetooth-device, and the solution would be much simpler if we had independent ports. Cheers, Mikel
