On 02/06/2013 12:48 PM, Tanu Kaskinen wrote:
On Tue, 2013-02-05 at 08:44 +0100, David Henningsson wrote:
On 02/04/2013 05:06 PM, Tanu Kaskinen wrote:
If the phone uses PulseAudio path configuration files for the ALSA
configuration, the Bluetooth port could be flagged with a property. If
the phone uses UCM, I think the UCM configuration should provide the
information, and the port flagged accordingly. If an ALSA port is
flagged that way, I guess alsa-card should not create a routing endpoint
in that case. The endpoint would be created by module-bluetooth-device.
Routing endpoints aside, if it is a technical impossibility / major
inconvenience to have a single port for a single physical entity, one
could have a port property "master-port" which would link the ports
together.
I don't think the Bluetooth module would implement ports for HSP in this
case, so there would be no master port to link to.
Why not? I mean, is this just a matter of "fixing" (you've previously
talked about always having ports for all sinks/sources), or is there a
good reason not to?
But how is exclusivity handled here? I mean, how would you encode the
fact that A2DP should not be used at the same time as HSP, if they don't
belong to the same card?
The headset endpoint could keep the HSP sink and source suspended while
the Bluetooth card has an A2DP profile active.If there are no Bluetooth
cards, maybe the ALSA card should keep the HSP sink and source suspended
until a Bluetooth card appears and takes control. When the Bluetooth
card has the HSP profile active, there's no problem with concurrent HSP
and A2DP use: in that case there are no A2DP sinks or sources at all.
I'm not sure I get this. What prevents a person (using e g pavucontrol
or gnome sound settings) from:
1) Selecting A2DP profile for the BlueZ card
2) Selecting HSP profile for the ALSA card
3) Route one stream to the BlueZ card
4) Route another stream to the ALSA card
I mean, one of the basic properties of two different cards is that they
are independent of each other, if this is not the case, should we
consider merging the bluetooth and ALSA cards instead? (That is just
brainstorming, not an actual proposal)
I don't think merging the cards is necessary, nor desirable. The ALSA
card can have also other functions than being a gateway to the Bluetooth
adapter, and those functions should be available regardless of whether
there are any Bluetooth devices connected or not.The HSP port can't be
separated from the ALSA card either, because those other functions may
be mutually exclusive with the HSP port, so the ALSA card must know when
the HSP port is being used.
So if we assume that (internal) speaker and HSP cannot be used at the
same time, and that HSP and A2DP cannot be used at the same time. What's
the conceptual difference between those two connections?
There is one: the fact that HSP and A2DP are routes to the same physical
device, but that would point towards merging HSP and A2DP into the same
card rather than merging HSP with speaker. But my brainstorming idea was
to merge all three of them into the same card.
Let's remember an important point here: our mission is to make things
convenient for our clients/end users, not ourselves. Our volume control
GUIs must not need to make if statements for whether we happen to be on
a BlueZ card on an ALSA card, ideally they would just choose what end
device they want their audio streamed to. If that means solving one more
hard problem in PulseAudio, I prefer that to having 10 different
workarounds in 10 different client applications.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
