[pulseaudio-discuss] [RFC] API for setting (default) port

[Tanu Kaskinen]

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 
> headphones)
>   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.

-- 
Tanu