[pulseaudio-discuss] [RFC] API for setting (default) port
tanu.kaskinen at linux.intel.com
Fri May 15 02:23:30 PDT 2015
On Wed, 2015-05-13 at 15:24 +0200, David Henningsson wrote:
> On 2015-05-13 12:06, Tanu Kaskinen wrote:
> > On Wed, 2015-05-13 at 09:29 +0200, David Henningsson wrote:
> >> Since many years ago we have an API for setting default source/sink.
> >> Our default routing today is more port centric. So our UIs (at least the
> >> unity/gnome one) has developed ways around this, so that when a port is
> >> selected it first selects the right profile if needed.
> >> The problem is that in this world it's becoming more difficult to detect
> >> what the user actually wants, when the result is a chain of API calls. E
> >> g, if we first get a "set profile" call, we're not certain whether this
> >> is the user wanting to change the profile for the currently active port,
> >> or if this is the first part of a transition to a new port.
> > This problem description isn't really detailed enough for me to
> > understand what you're trying to solve.
> Ok. Assume you have 2.1 speakers, and headphones without full jack
> detection. (This is the case for some Dell laptops where the jack can be
> both used as headphone, headset and just mic, and the hardware cannot
> detect which one you plugged in.)
> Headphones are plugged in, and the user selects headphones manually.
> This causes the GUI to perform three calls to the API:
> 1) Change profile to stereo (so that we have a profile that supports
> 2) Change port to headphones for the newly created sink.
> 3) Change the default sink to the newly created one.
> Now, assuming we want to save profile per port, PA cannot in step 1 be
> sure whether the user explicitly wanted to switch to a stereo profile
> for the speakers, or whether the profile switch was just part of the
> port switching.
Thanks for the explanation! Now I understand what was the motivation for
the new API, and the addition makes perfect sense.
> >> To overcome this problem, we should have some new API enabling the UI to
> >> set the port directly. E g like this:
> >> pa_set_card_port(card, port, profile, bool default)
I suggest "pa_context_activate_port" or "pa_context_activate_card_port"
as the function name. "pa_(context_)set_card_port" sounds like the card
could only have one port active at a time.
More information about the pulseaudio-discuss