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
