[pulseaudio-discuss] New feature in the works: "volume sharing"

[David Henningsson]

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