Rockbox

Tasklist

FS#11817 - M:Robe 500: Kinetic-scrolling influences music plaback

Attached to Project: Rockbox
Opened by Leo Witt (some-xtc) - Monday, 20 December 2010, 00:10 GMT
Last edited by Thomas Martitz (kugel.) - Sunday, 05 June 2011, 15:14 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System Olympus M:Robe 500
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Version: r28861

Hello,

when I hold the touchscreen on a kinetic-scroll for some seconds (2-3), the music playback gets interrupted.

This is very annoying on big lists and you're still selecting ...

Thanks in advance!
This task depends upon

Closed by  Thomas Martitz (kugel.)
Sunday, 05 June 2011, 15:14 GMT
Reason for closing:  Fixed
Comment by Thomas Martitz (kugel.) - Monday, 20 December 2010, 01:34 GMT
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.
Comment by Michael Sevakis (MikeS) - Monday, 20 December 2010, 03:14 GMT
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.
Comment by Thomas Martitz (kugel.) - Monday, 20 December 2010, 10:34 GMT
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.
Comment by Leo Witt (some-xtc) - Monday, 20 December 2010, 11:22 GMT
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.

Comment by Thomas Martitz (kugel.) - Monday, 20 December 2010, 21:28 GMT
Does this patch make it any better?
Comment by Leo Witt (some-xtc) - Tuesday, 21 December 2010, 10:04 GMT
It's a pity, but I can't build rockbox on my own ...
Comment by Thomas Martitz (kugel.) - Tuesday, 21 December 2010, 20:51 GMT
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).
Comment by Leo Witt (some-xtc) - Tuesday, 21 December 2010, 23:19 GMT
Thomas,

your binary causes some strange graphic glitches ... but yeah, kinetic-scrolling does not influences music plaback ! :-)
Comment by Thomas Martitz (kugel.) - Wednesday, 22 December 2010, 06:12 GMT
This should fix the graphical issues.
EDIT: uploaded the corresponding patch
Comment by Leo Witt (some-xtc) - Wednesday, 22 December 2010, 11:43 GMT
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

Comment by Thomas Martitz (kugel.) - Wednesday, 22 December 2010, 12:12 GMT
Doesn't test_fps stop music when you run it? Is that SVN vs my patched binary or really music vs no music?
Comment by Leo Witt (some-xtc) - Wednesday, 22 December 2010, 12:25 GMT
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 ?
Comment by Thomas Martitz (kugel.) - Wednesday, 22 December 2010, 13:11 GMT
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.
Comment by Leo Witt (some-xtc) - Wednesday, 22 December 2010, 13:59 GMT
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
Comment by Leo Witt (some-xtc) - Wednesday, 22 December 2010, 14:19 GMT
with lethargic I mean slow (in German "schwerfällig")
Comment by Thomas Martitz (kugel.) - Wednesday, 22 December 2010, 15:03 GMT
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.
Comment by Leo Witt (some-xtc) - Wednesday, 22 December 2010, 20:02 GMT
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 ...
Comment by Leo Witt (some-xtc) - Wednesday, 22 December 2010, 20:33 GMT
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.

Loading...