Phonon + Volume Changes and feedback loops

[Colin Guthrie]

'Twas brillig, and Christian Esken at 29/03/10 16:43 did gyre and gimble:
> 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.

Yeah sorry, I think I was confused by the phrase "I don't see any reason
to update the volume to the GUI" which I took to mean the GUIs
representation of the current volume. I think I basically misundersood
and we're pretty much in agreement here :)

>> 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.

Yeah some sort of emergency reboot:
http://blog.gitorious.org/2010/03/29/emergency-reboot-2/

>> 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.

I had a quick look at the blockSignals() docs and it seems that after
turning it off, I'd need to turn it back on somehow (e.g. there is no
"block one setValue signal" capability). With the current solution
linked above, I turn the handling back on after ignoring a change but to
do that I have to do it in the slot for that change. With blockSignals()
I'd have to find a way to unblock them again after one has been thrown
away.... I couldn't see a way to do that, but perhaps I missed that?

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/]

_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia