Rockbox

That's I assume a problem with our multi-threading scheduler. How bad do you feel is the situation? I have had the situation you described on my phone, but in the very most cases I can select items without exposing it (so it's not very bad in my personal situation). But I can imagine that it could possibly worse on an mr500.

Thomas: Was peeking in on IRC (not feeling chatty lately) and saw the concern. Are you saying alot of user input tends to hold up the audio thread? Does the list code properly yield if queue input is continuous? I ask because the queue, if it contains one or more messages, does not pass control to other threads before returning and so a thread depending on some button_xxxx function to pass control during a get, but not yielding explicitely itself can starve out other threads if the queue is always full. There is a possibility of letting other objects work like mutexes, interrupting on a priority basis or just yielding internally under certain conditions if priority is not part of the particular implementation. I'm guessing at what might be going on of course.

Normally, the user input should slow down as the pcm buffer drains and the codec priority is raised. If lists stay fast even when the buffer is draining, this may be the right track.

Yes, the list code has an explicit yield() after a redraw (additionally to the upcoming button_get() call).
I think the button_queue isn't always full since I limited redraws to 20fps, ie the timeout handler posts to the button_queue only every 4 ticks.

But even even if the button_queue was always full, I'd not expect that the main thread can starve the audio one, since the audio thread boosts its priority if it can't keep up decoding.
As I mentioned in irc,  FS#11387  also indicates a scheduler problem. in that task a thread which is mostly waiting for dma to finish (via wakeup_wait()) starves the audio thread.

Thomas,

as I said this situation is very annoying!

This error happens even on a "big" kinetic-scroll, if I scroll down from the top to the bottom
1. with one flip (in German: "mit einem Ruck")
or
2. sequentially with the finger.

Does this patch make it any better?

It's a pity, but I can't build rockbox on my own ...

Here's the binary with that patch applied.

Can you also run the attached test_fps with SVN and with the attached binary (to see if my patch causes any slowdown).

Thomas,

your binary causes some strange graphic glitches ... but yeah, kinetic-scrolling does not influences music plaback ! :-)

This should fix the graphical issues.
EDIT: uploaded the corresponding patch

The graphics glitches seems to be fixed, but the LCD is now quite lethargic.


The results from test_fps with your second patch:

without music:

Main LCD Update:
1/1: 97.0 fps
1/4: 277.0 fps
Main LCD YUV
1/1: 31.6 fps
1/4: 120.0 fps
Remote LCD Update
1/1: -760173.-6 fps
1/4: 502568.8 fps
CPU: 88 Mhz

with music:

Main LCD Update:
1/1: 59.5 fps
1/4: 168.0 fps
Main LCD YUV
1/1: 31.6 fps
1/4: 120.0 fps
Remote LCD Update
1/1: -763450.-1 fps
1/4: 500022.3 fps
CPU: 88 Mhz

Doesn't test_fps stop music when you run it? Is that SVN vs my patched binary or really music vs no music?

I've just replaced your binary "rockbox.mrobe500 " with the one from r28861.

This is really music vs no music,
test_fps does not stop music when I run it.

Have I done something wrong :-X ?

I guess my memory served wrong. The numbers look okay to me, what do you mean with lethargic? also, can you run test_fps on a current build (the .rock I attached should work)? that should show a difference.

The results from test_fps (with current build r28876):

without music:

Main LCD Update:
1/1: 112.5 fps
1/4: 296.5 fps
Main LCD YUV
1/1: 31.6 fps
1/4: 120.5 fps
Remote LCD Update
1/1: -760171.-1 fps
1/4: 502659.8 fps
CPU: 88 Mhz

with music (this time, the music stops when I run test_fps):

1/1: 112.0 fps
1/4: 395.0 fps
Main LCD YUV
1/1: 32.1 fps
1/4: 122.5 fps
Remote LCD Update
1/1: 346300.8 fps
1/4: 988550.7 fps
CPU: 88 Mhz

with lethargic I mean slow (in German "schwerfällig")

ok, the numbers are higher in svn but not too much (without music). but I can imagine that feels a bit slower. I think the port maintainer needs to help me here.
in the meantime I'll commit another patch which should make the issue less bad.

Sorry,
but I must say, it is noticeably slower.

On music playback the marquee, for example, does not run smoothly and the WPS comes in fragments ...

I'm testing now the current build (r28878) and the issue seems to be a little less bad ... now I can do a "big" kinetic-scroll sequentially with the finger without interruption.