FS#12238 - WPS delay on pause introduced by r30097
Attached to Project:
Rockbox
Opened by Glued (glued) - Saturday, 20 August 2011, 17:59 GMT
Last edited by Michael Sevakis (MikeS) - Tuesday, 23 August 2011, 01:39 GMT
Opened by Glued (glued) - Saturday, 20 August 2011, 17:59 GMT
Last edited by Michael Sevakis (MikeS) - Tuesday, 23 August 2011, 01:39 GMT
|
Detailsr30097 is a commit of MikeS
Mike, unfortunately the mixer fade out on pause has a side effect on WPS: the pause mode kicks in after a very noticeable delay. It is an issue for themes that handle pause events, f.e. switching viewports on it. Now switching feels slow like walking in water. I've honestly tried fixing it in apps/gui/wps.c > pause_action / unpause_action, but my code either looks dirty or doesn't work. Since it's your patch, you probably could fix it properly. At least I hope you can. |
This task depends upon
Closed by Michael Sevakis (MikeS)
Tuesday, 23 August 2011, 01:39 GMT
Reason for closing: Accepted
Additional comments about closing: The worst possible solution was chosen for r30340. ;-)
Tuesday, 23 August 2011, 01:39 GMT
Reason for closing: Accepted
Additional comments about closing: The worst possible solution was chosen for r30340. ;-)
(Dodges the slipper.)
Do you think maybe instead of ticks > timeout api the ui playback status should be just directly connected to buttons actions?
An elevator button lights up when you press it, after all, not on arrival. Plus fading is pretty internal by nature. And from a user pov, it's more important to see that the button wasn't missed / diff viewport / stuff than that the fade is completed.
I was actually trying to map actions <> ui directly, thinking to impress you with a shorter solution, but the code is so damn new to me, that I scared my cat cursing.
ETA: No dircache panics BTW. I try other targets.
As to the delay amount, it's a huge improvement, barely noticeable now. I'm pretty amazed you've came up with the ticks idea that fast.
I checked your code char by char, and there's really no way it could be done faster.
P.S. Please ignore my panics note, absolutely nothing to do with your code, sorry.
Core playback functionality needs to get the heck out of screen code, which actually shouldn't be too hard. Anyway, indeed the fading is indeed deep inside this because it uses the mixer and that complexity should remain well hidden.
The consequence of this is that the audio_stop becomes a request for something to happen later and unless I enforce that stop should take effect immediately, the playback engine is still running until the fade is complete (not true with audio_hard_stop, which must have the engine idle). As a side effect, the stop can even be reversed by requesting another action before the fade completes, but that's what it is, a side effect of delaying the transistion. It is possible to make a stop request "no return".
Things to think about...
P.S.R. Will do, which makes things easier on me! :-)
I am against committing as this is just not fair.