Phonon + Volume Changes and feedback loops

[Colin Guthrie]

'Twas brillig, and Christian Esken at 29/03/10 10:55 did gyre and gimble:
> KMix faces exactly the same challenge (for the Slider), and it simply uses 
> blockSignal() (see mdwslider.cpp).

Ahh interesting. I'll look into blockSignal() usage but I'm not sure if
it'll work due to the async nature of some updates. Certainly worth me
looking at tho'.

> The basic point is, that 2 -> 3 should be avoided. I don't see any reason to 
> update the volume to the GUI after a change comes in from the Hardware or PA. 
> We know that the value is already correct. Why is this done?

It's needed because the change can be triggered externally to the GUI in
question. e.g. to use kmix as an example: if the user uses alsamixer to
change the alsa volume, the kmix GUI should be updated. The same is true
in the case of per-application volumes with PA. e.g. the volume dial in
amarok should be updated when the user changes the amarok stream volume
in the kmix "Playback Streams" tab.

When this happens, we know that the value is *incorrect* :)


> Would it be possible to run blockSignal() if the source is external?
> External would mean, that it is coming from the slot connected to 
> volumeChanged().

I'll look into it, but I'm not sure when to reset the blockSignal() to
allow it again. I've not looked into how it works, so it may only be a
one shot anyway. and like you say if it's external it may not work
either. I'll look into it tho'.


> Any request coming in from Hardware or PA must never be reflected back. There 
> is no need for a counter or flag, as far as i understood.

When the change comes in, we have to make sure the GUI shows that
change, but that we do not push the change back to the h/w or PA again
if the change that updated the GUI did not come from user input to the
GUI... bah! Go go gadget poor explanation again :p



I think the current protection I added in phonon with the following commit:
http://gitorious.org/phonon/phonon/commit/801c316c7afa324e99406d65451e9e5aebadb213

solves this issue for me in my tests... but if blockSignal() works
better then I'll look into using that instead.

Many thanks for the feedback :)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]