Rockbox

I was sort of just waiting to see if there were issues just leaving it to block since the fade was shortened so much in an earlier commit. I have it mostly worked out already and will post a patch ASAP. Volume fading will be done in a tick task to ensure accuracy and audio will be notified when it completes.

Try this one out. Seems to work well for me. I hope it addresses the issue well.

   async-playback-fade-01.patch (11.1 KiB)

The delay is much shorter, yet is still present.

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

Mike you’re not getting dircache panics? I had 3, but my build if unclean, so there’s a chance it’s unrelated.

The engine changes state immediately after receiving the message to pause/resume, lets the UI thread proceed, then the fade happens in the background, unreleated to the playback state. There really isn’t anything more I could do on its end to improve it since it doesn’t block the UI for longer than it takes to process that. I gave the WPS a look and what’s left might be delay in the screen updates. The old fade() function in wps.c would call skin_update() immediately, but fade() is not used now.

ETA: No dircache panics BTW. I try other targets.

I see that. I was just trying to find a less complex and a slightly faster solution to look cool, and failed :).
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!

This one makes “stop” mean “stop” as it should. Includes WPS update calls that should be there. I’m going with this with any needed tweaks for commit. Give it a go.

   async-playback-fade-02.patch (11.3 KiB)

Your patch is terrible. It now solves the issue completely, while I couldn’t do neither that, nor improve your 1st.
I am against committing as this is just not fair.

I like your style. Sure there’s nothing I can do to make it worse?

I think this is the worst one so far…a far, far worse thing that I did than I have ever done. It is far too basic in comparison to the others.

   async-playback-fade-03.patch (10.3 KiB)