Unresponsive Sansa with Frequency Scaling

[Vortex]

Hi everyone,

unfortunately the enabling of frequency scaling causes menu navigation to be extremely slow and unresponsive on my Sansa, especially when playback is not running. I guess it's because the CPU is running at a low frequency when playback is not running, causing menu navigation to be unresponsive.

Navigating through the menus is a real pain right now, especially when scrolling through large lists. Maybe the frequency scaling code should be changed to restore the CPU to normal frequency while the scrollwheel is being used or while the backlight is active or something like that. Another idea would be to power up the CPU while you are in a menu screen with backlight on and set it to "economic" mode once you return to the WPS or the backlight turns off.

Would it be possible to change the frequency scaling code like and should I file a bug report on this?

[cpchan]

unfortunately the enabling of frequency scaling causes menu navigation to be extremely slow and unresponsive on my Sansa, especially when playback is not running. I guess it's because the CPU is running at a low frequency when playback is not running, causing menu navigation to be unresponsive.

Which build are you using? "Frequency Scale" was disabled again a while back and a new "Scrollwheel Acceleration" code was just introduced a couple of days ago. My e280 have been very responsive.

Charles

[Llorean]

Actually, frequency scaling is back in, but I find it quite responsive still. Not perfect, but that won't happen until dual core is working.

[cpchan]

Actually, frequency scaling is back in, but I find it quite responsive still. Not perfect, but that won't happen until dual core is working.

Ah, thanks for the info, Llorean. Just check the SVN log- it just got back in.

Charles

[Vortex]

My e280 have been very responsive.

Mine too, until frequency scaling was re-enabled.

Actually, frequency scaling is back in, but I find it quite responsive still.

I wonder if there is something wrong with mine then, because right now the speed is absolutely unacceptable. It works better when playback is running but it is very slow when playback is stopped and the CPU is running at low speed.

Not perfect, but that won't happen until dual core is working.

What about the suggestions I made in my first post. Would they not work?

[saratoga]

That would work.  I discussed implementing it on IRC a week or two ago, and most people seemed to like the idea.  If you're interested in working on it, we'd accept a well implemented patch (IE one a little more sophisticated then just boosting when the backlight flips and unboosting when it flips off).

[Llorean]

I really don't think the speed is problematic enough to warrant boosting while the backlight is on. Saratoga, have you tried a recent build?

Vortex: What theme are you using? When playback is running, about half the time it should be worse because it's unboosted and yet the CPU is in use so less is available.

[saratoga]

I really don't think the speed is problematic enough to warrant boosting while the backlight is on. Saratoga, have you tried a recent build?

I don't have a problem with it, which is why I dropped the idea.  And anyway, the idea was to boost when the controls are active, and then unboost immediately afterwards.   That way the power increase would be minimal.  

[Llorean]

Minimal, but I still think it might be better to simply spend time optimizing UI code. The worst case situation is going to be during "Unboosted playback," which will go away when Dual Core happens. That leaves the worst case as "Unboosted, no playback" which for me at least is perfectly reasonably speeded right now (turning on and off boost doesn't seem to affect UI speed significantly on my Sansa.) It may be theme dependent, but if it's something that's down to that, it's very possible it can be optimized away.

[cpchan]

Just tested it. Mine is still very responsive while playing music.

Charles