• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Plugins
  • Assigned To No-one
  • Operating System iPod Nano 2G
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by mamarley - 2010-06-09
Last edited by kugel. - 2011-06-13

FS#11387 - PictureFlow runs jerkily while playing music on Nano2G after the recent feature addition

After the series of commits that added WPS integration for PictureFlow, I have noticed that PictureFlow runs very jerkily if the player is playing music at the same time. Before those commits, it was almost perfectly smooth, even when playing music. I tried forcing boost before the test, but that didn’t affect the performance.

Closed by  kugel.
2011-06-13 16:50
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407


can you track down which commit did it?

Not at the moment, but I should be able to later today. I will get back to you when I have.

OK, I have narrowed it down to somewhere between 26713 and 26719. Considering that the only commit in that range that actually affects PictureFlow is 26713, I am reasonably sure that is the one that caused the problem.

can you roll back to 26712 and try patching each of the patches from starting from #2? I would guess #4 would be the problem…

No doubt it’s #6 - audio_dropouts patch. This one inserts new yields in the rendering loop.
On Fuze this improves the smoothness and prevents audio from dropping out when scrolling quickly.

If the problem is visible in USim then I could try finding a fix. I have no Nano2G to test.
That patch is worthwhile for Fuze targets as it improves both scrolling and audio playback.

If it’s a matter of the Nano2G not being able to handle the increased yields then perhaps try adding a condition around the 3 lines inserted at line 1807 so that it yields less often. eg. if( x % 10 == 0 ) { … 3lines }. I did this during testing on Fuze but it worked the same or better without it. It doesn’t need to yield so often but yielding more than once per render makes a marked improvement.

I was thinking it was probably #6, too. Why not just put an #ifdef around it so it only applies for the targets that need it?

I’m ok with an #ifdef but I don’t have any idea what targets have problems or not. I wouldn’t want it to be a big messy thing there.
I mean for the time being it could be #ifndef for nano2g b/c we know that has problems. But if more deviations turn up we should figure out what underlying cause (if one) makes it a problem.

Did you try running with those 3 lines removed to see if PF returned to past behaviour? I can make a patch for testing that if need be.

Yes, removing those four lines does cause it to return to normal behavior. I don’t understand why it doesn’t work well though, since (I think) the Nano2G is one of the more powerful targets…

Try leaving the yield line in place but commenting the two following lines that resync (bmp = … , and ptr = …). The surface line can cause loading a file at a point which may introduce a visible delay. Disabling those may smooth the display but cause visible glitches to appear. If that helps then I’ll look for a better approach for that.

Can please test this patch?
It still works fine on my fuze but cuts down yields by 10x.
I tried some other methods here but none were smooth and glitch free.
I suspect on the Nano2G must have higher overhead on memory mgmt and/or task switching.
Let me know if this improves a little or a lot.

With just the patch, it still runs jerkily (though less so than without it.) I am now trying removing those two lines…

With the resync code commented out, there is no visible difference from just the yield-test patch.

I’m thinking the added yield was an incorrect fix.

On my fuze, you can get drop outs when scrolling slowly too, and it is loading slides (loading happens in a seperate thread, so it yields). That means the audio thread doesn’t run even though there are yields.

Indeed, decreasing the priority (tested with PRIORITY_BUFFERING) of the loading thread let’s pf run less flaky and without audio dropouts. I cannot tell if loading slides takes longer or not though (but I suspect it does).


Available keyboard shortcuts


Task Details

Task Editing