Phonon + Volume Changes and feedback loops

[Christian Esken]

Am Montag, 29. März 2010 12:04:13 schrieb 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.

But that is 1 -> 2  (Update GUI). Surely that one is needed.
I discussed the 2 ->3 step.

> 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

Exactly.

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

Can't take a look, as currently http://gitorious.org/ seems to be overloaded 
or down. Will try to do so later.

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

I think blockSignal() would be exactly what you need.

 Christian