[pulseaudio-discuss] Jack detection - Client API for UIs

[David Henningsson]

On 11/14/2011 08:56 PM, Colin Guthrie wrote:
> 'Twas brillig, and David Henningsson at 14/11/11 10:22 did gyre and gimble:
>> On 11/11/2011 03:08 PM, David Henningsson wrote:
>>> On 11/11/2011 12:17 AM, David Henningsson wrote:
>>>> Do you think we can merge these different views and come up with an
>>>> agreed client API within a couple of days?
>>>
>>> Ok, so I can happily say that we had a great IRC conversation on the
>>> topic today. The outcome was:
>>>
>>> * Not to register port objects with the core (for the time being)
>>>
>>> * Not to add "inactive" sinks/sources to the client API (for the time
>>> being)
>>>
>>> * When port availability changes, fire a subscription event for the card.
>>>
>>> * I'm not sure we got consensus on if/when the sink/source should also
>>> get a subscription event, but that can be discussed later.
>>>
>>> * To change the existing proposal's "is_input" and "is_output" to a
>>> bitfield. Thus the new client API proposal is now attached. I'll start
>>> working on implementing this next week unless I hear massive complaints.
>>>
>>> One detail though: should the enums be declared as is (e g
>>> "pa_direction_t direction;") or as ints ("int direction;")? I remember
>>> someone saying enums were more likely to change size than ints.
>>
>> In line with the client API proposal, here's the matching protocol
>> proposal.
>>
>> Any objections?
>>
>>
>> ## v25, implemented by>= 2.0
>>
>> When port availability changes, send a subscription event for the
>> owning card.
>>
>> ## v26, implemented by>= 2.0
>>
>> In reply from PA_COMMAND_GET_CARD_INFO (and thus
>> PA_COMMAND_GET_CARD_INFO_LIST), the following is added:
>>
>>      uint32_t n_ports
>>
>> ....followed by n_ports extended port entries, which look like this:
>>
>>      string name
>>      string description
>>      uint32_t priority
>>      uint32_t available
>
> Can we make this a uint8_t? I know the protocol might send a uint32_t
> for availability elsewhere but there is no reason for this to be carried
> through where it's not needed.

Sure. I'll value the consistency over the three bytes saved here, but 
it's no big deal.

>>      uint8_t direction
>>      uint32_t n_profiles
>>      string profile_name_1
>>      ...
>>      string profile_name_n
>>
>> Profile names must match earlier sent profile names for the same card.
>
> Seems OK.
>
>
>
> Can we get an icon in here somehow? IMO each port should have it's own
> icon to allow for Speakers to be presented differently in UIs to Headphones.
>
>  From what I remember, this is done via a proplist for the other bits of
> the system... as there was some talk of eventually adding a proplist to
> ports, perhaps it's worth adding it in to the protocol and only
> populating "device.icon_name" initially (or even leaving it totally
> blank for now and doing the icon stuff later)?

Well, there's nothing keeping us from adding a v27 when we see the need 
for an icon.

However, you talked in Prague about having some kind of API where you 
could get additional information about a port, e g "last seen". I 
thought the icon name would be taken from there as well?

Thinking further ahead; you might want to be able to set/get per-port 
cvolumes on an inactive port: Imagine our user first listens to death 
metal at high volume through the speakers, then neighbour comes up and 
complains and so the user immediately switches to headphones, but once 
the neighbour has gone to sleep the user switches back to speakers - 
this time at a lower volume, so that the neighbour does not wake up. The 
user then wants to adjust the speaker volume even though headphones are 
currently being used. We don't have to resolve all the details of that 
now either, but it can be good to know where such functionality would 
fit into the greater picture.

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