On 2011-02-14 12:45, Colin Guthrie wrote: > 'Twas brillig, and Tanu Kaskinen at 14/02/11 11:19 did gyre and gimble: >> On Sun, 2011-02-13 at 22:05 +0200, Colin Guthrie wrote: >>> With this push based approach, you do loose some individual granularity, >>> but the net volume of the underlying h/w should be the same as your >>> approach. >> >> What granularity would I lose? I think your suggested logic would be >> quite equivalent to the one that I originally proposed. >> >>> The concern I have with the approach outlined, is that it adds >>> complexity to the core and I'm not 100% sure how far the chain can go >>> (e.g. can you have a filter-sink1->filter-sink2->filter-sink3->hw-sink >>> pipeline? - with a push model this is possible). >> >> It's possible with the pull model too - the filter sinks are always >> traversed recursively. About complexity - I haven't done a thorough >> analysis of your suggestion, but I would guess that it would be a little >> bit simpler. There would still be a significant amount of added >> complexity in the core, though. I'll finish the patch using the original >> logic first, and if you want, I can probably do another version to see >> how much the push model will differ. > > I don't really want to create extra work for you, I'm just genuinely > unsure which would be considered a "cleaner" approach (or even if it > really matters at all!!) > > Other opinions welcome :) I have a question: how about the volume store/restore module? Will it store and restore the outermost sink's volume, the innermost one, or both? Another thing is the pick-up of volume/mute changes in the driver - at least that's done on the ALSA side. Will that then be pushed through in the other direction somehow, or...? Just trying to make sure you haven't missed anything :-) -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
