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

[Colin Guthrie]

'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.

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

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

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/