On Wed, 2011-07-13 at 15:31 +0100, Colin Guthrie wrote: > '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? Redundant change events are dropped, so there's no significant penalty of generating 10 events for one transaction. > 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 Despite this bloat I think having the setter functions would be cleaner. It's not a big deal if you think otherwise - as you say, the practical implications are rather small. -- Tanu
