'Twas brillig, and Tanu Kaskinen at 13/07/11 17:19 did gyre and gimble: > 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. Just for reference, I've done this in my tree now, and it solves the flat volume problem too I think. I'll send another review request when I've addressed the patch 4 comments. Cheers 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/]
