'Twas brillig, and Tanu Kaskinen at 13/07/11 14:41 did gyre and gimble: > On Thu, 2011-07-07 at 10:55 +0100, Colin Guthrie wrote: >> This allows us to flip from software to hardware volume control as the port's >> mixer path dictates. > > I don't really like the pa_sink_set_flags_from_callbacks() function, > because the sink implementations have to remember to call it whenever > they change the callbacks. I propose that we add > pa_sink_set_get_volume_callback() etc, and do the flag updates and > subscription notification inside those functions. What do you think? Do we want to do the subscription notifications inside such functions or all at once? Will it really matter if we register 10 subscription notifications - does that group it up into just 1 if they are redundant? I guess in principle I'm not against it, other than it adds a bit to the number of functions here and arguably bloats the internal API. Especially as these flags are not super important in a practical sense and don't really get used much (perhaps with the exception of flat volume but that's going to have to come out anyway due to the previous oversight you pointed out ;)) > A somewhat similar thing: I'd add pa_sink_set_decibel_volume() that > takes care of sending the subscription notification so the sink > implementations wouldn't have to care about that. ACK to this (assuming the above also makes sense overall :D) 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/]
