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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
