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

[Colin Guthrie]

'Twas brillig, and David Henningsson at 15/11/11 14:00 did gyre and gimble:
> On 11/15/2011 11:03 AM, Colin Guthrie wrote:
>>>> 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.)

Yeah it's no biggie, just depends how you felt about it. As it is a
totally unused part of the protocol as the UI bits were backed out, I
figured the risk was minimal, but you know better than me here - unless
I've picked something up wrong.... entirely possible!

Either way I still think it would be better to use uint8 as it's the
correct field size, but if the others have any opinions here, I won't
nitpick :)


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

Yeah, that's what I originally suggested, so obviously I think it's OK,
provided no-one else objects :)


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

Actually thinking about it a bit more, I'm mixing up modules here... gah!

We don't currently save the stream volumes separately for each port,
this is only done in device-restore. I did write a protocol extension
for device-restore, but I didn't take it as far as the actual volume
parts - only the formats that a given device supports. So we'd have to
extend the protocol extension to allow editing of the volumes as well as
the formats.

The stream-restore protocol extension does allow editing of the volumes.

Even if the stream-restore stuff worked, I don't really know if I'd
officially recommend it as the logic behind assigning a "stream restore
id" would have to be implemented client side. FYI, this is how the
"Event Sounds" sliders work in e.g. pavucontrol and gnome-volume-control.


But even then the API to use really depends on the kind of client you
are writing... if you want your client to work with volumes that are not
current present, then you'll need the device-restore protocol extensions
(and extend that to actually implement the bits I skipped!), otherwise,
I'd recommend only the "normal" APIs for volume adjustments.

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/