On Tue, 05.01.10 10:06, Colin Guthrie (gmane at colin.guthr.ie) wrote: > > BTW, if you touch this code anyway it might be an idea to create a new > > tab which lists more role-specific sliders/dropdowns than just > > "event". I.e. a music slider, a telephony sleider and so on. > > Actually I'm a bit aprehensive about exposing other roles just yet... > > My reasoning: > > At present pavucontrol: > 1) Shows an Event slider for all sounds with the "event" role. > 2) Hides individual streams with the "event" role. > > This means that there is only one way to adjust the volume of these > streams and that is via the stream restore db and the widget. > > Now the stream restore key format currently has a priority scheme. If a > stream that has a role has a role-based rule, it will take precedence > over an application based stream (IIRC it's role, app id, app name, > media name in that order). That is true. > So if I were to expose the other roles, and someone set a volume for > e.g. music, then went along and started playing multiple files in e.g. > rhythmbox, found it too loud and adjusted the *application* stream for > rhythmbox it would be adjusted for that stream and saved to the db as an > application specific rule, but the next time rhythmbox played anything > (e.g. on track change), the volume would be restored from the *role* > based rule. No. That's not how it works: changing the application volume will influence the role volume. For each stream when it first appears we calculate the key to identify it with in the database, both when reading and when writing, and we never use anything different during the stream's entire lifetime. That means that if for a rhythmbox stream we determine the sink-input-by-role:music key then we will read the volume/device with is it, and write it too. We will never fiddle with sink-input-by-application:Rhythmbox if they role is set. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
