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

[David Henningsson]

On 11/15/2011 11:03 AM, Colin Guthrie wrote:
> 'Twas brillig, and David Henningsson at 15/11/11 06:03 did gyre and gimble:
>> On 11/14/2011 08:56 PM, Colin Guthrie wrote:
>>>> 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.
>
> See if Arun or Tanu have an opinion on this one. My reasoning being that
> it should be uint8_t and if you do end up doing another update for
> Ubuntu's PA before we do a 2.0 release, you might consider tweaking the
> existing value to uint8_t... as it would only really affect users
> running UI tools with older lib vs. newer daemon, it's very unlikely to
> be a practical problem if you were to push a "streamlined" fix. Just
> gives us a little bit of room for improvement should the opportunity
> crop up.

Well, updating a uint32_t -> uint8_t change in the protocol to a stable 
Ubuntu version; with potential of quite some breakage that will cause 
for users running a stable version of Ubuntu - it's just not 
justifiable. (And even if it was, it would give PulseAudio bad 
reputation. We don't need that as an upstream either.)

>>>>       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.
>
> Yeah but if we can avoid unnecessary version bumps then mores the
> better. The code is messy enough with all the version conditions, so if
> we can get it right that's good.

Ok, so how about adding a proplist then? We can then fill that up with 
icon names and possibly other stuff as needed. It just feels like icon 
names belong to a proplist - because it's in a proplist for other objects.

>> 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?
>
> Yeah, although it would be more of a "history" API that would very much
> be optional. It's really just gathers information about what has been
> seen before. IMO the real info should still be available via official
> introspection mechanism.
>
>> 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.
>
> This is technically already possible. Just use the stream restore API.

I haven't looked into the stream (device?) restore API, but you say 
"technically" - is it also the method you officially recommend for 
volume control UIs?

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