On 02/04/2013 02:46 PM, Tanu Kaskinen wrote:
On Mon, 2013-02-04 at 10:43 +0100, David Henningsson wrote:
On 02/04/2013 09:59 AM, Mikel Astiz wrote:
On Wed, Nov 28, 2012 at 8:51 PM, Tanu Kaskinen <[email protected]> wrote:
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?
No, and no.
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.
So; if port are merged with sinks/sources, I assume you would like this
merged object to be once per stream (i e different for a2dp and
hfp/hsp), which would again break the UI?
This looks like a problem with the approach of trying to merge ports and
sinks/sources.
I don't think merging ports with sinks/sources is the most relevant
question here. The question is how to simultaneously present a Bluetooth
headset as a single routing endpoint to the user and have means to
sufficiently distinguish between A2DP and HSP inside PulseAudio.
I haven't fully understood the problem with having merged ports for A2DP
and HSP - there are still different sources and sinks, so one could just
look at the current active sink if that's what you need to know.
I do understand that if something was modelled in one way, and then we
had to do an emergency fix because the model caused regressions in the
UI, the fixups become ugly as a result. What I don't know yet is why
multiple ports for A2DP and HSP would be a better model inside
PulseAudio from start?
I have proposed that we use the routing nodes of the policy work done by
Janos and Jaska to represent the headset as a single routing endpoint,
and associate multiple ports (A2DP and HSP) with that routing endpoint.
I would like to reach a consensus about this proposal. Is it ok for
everybody? David? Janos? Jaska? Please comment.
It is difficult to have an opinion without knowing more about the
routing framework and what a routing endpoint really is. But even if
this proposal gets implemented, still somebody needs to rewrite the UI
to use routing endpoints instead of ports - which should be an argument
against this proposal in the first place.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
