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

[David Henningsson]

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.

>> 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)
>>
>> If "profile" is NULL, PA is free to choose the most fitting profile.
>> If default is true, it will not only set the port, but also set the
>> default sink/source.
>> (Card and port must be set.)
>>
>> This looks to me like a perquisite for better port-based routing. (And
>> then we must get the UIs to actually use it, too.) But I'm not sure if
>> this interferes with e g Tanu's long time routing plans.
>> What do you think?
>
>  From your description the only genuinely new functionality would be the
> ability to tell the server to activate a port without choosing the
> profile explicitly. Is that correct?

Yes, I think so. Although it's the atomicity (doing it all in one API 
call) that's the big thing.

> That certainly wouldn't conflict
> with any of my plans.

Good.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic