Rockbox Ports are now being developed for various digital audio players!
Fuzev2: Lowering PCLK helps, but does not solve the problem.
I think devices with a wheel will boost whenever the wheel is used.
Updated builds:http://web.mit.edu/mgg6/www/rockbox-clipv2.7zhttp://web.mit.edu/mgg6/www/rockbox-clipplus.7z
Running fine on an older Clip+ (end of 2009!). The only things I noticed:1. pressing the submenu during playback seems to take a longer time to display the playlist (the button press is registered correctly, but after I depress the button it takes almost 2 seconds to display the playlist - ~2500 entries2. accessing the Database (~1500 songs on the card) seems slower - I get to read the "Searching for..." text when entering letter C artists for example (~65 artists).
Quote from: florin on January 08, 2015, 04:58:20 AMRunning fine on an older Clip+ (end of 2009!). The only things I noticed:1. pressing the submenu during playback seems to take a longer time to display the playlist (the button press is registered correctly, but after I depress the button it takes almost 2 seconds to display the playlist - ~2500 entries2. accessing the Database (~1500 songs on the card) seems slower - I get to read the "Searching for..." text when entering letter C artists for example (~65 artists). It's OK, in that case we need to rise voltage. The voltage settings for clip+ based from my runtime tests, where I listen music with file manager and low demand FLAC. I don't use a database and playlists. So each folder contains average 15 tracks, it's very easy for my player to handle that without a noticeable delay. But I didn't test a player with database and with big playlists.I think that we need to implement a special setting in menu of rockbox where user can change a power consume preference:1) Very low power consume. Good for playing music like file manager with low consume formats. Player uses a power optimization that enables frequency scaling and applies extremely lowered but stable voltages.2) Balanced. For everyday use. Player uses a power optimization that enables frequency scaling and applies a balances values of lowered voltages.3) High Performance. Good for very big database, playlists and for playing codecs with high power consume. Player don't uses any power optimizations.
I think that we need to implement a special setting in menu of rockbox where user can change a power consume preference:1) Very low power consume. Good for playing music like file manager with low consume formats. Player uses a power optimization that enables frequency scaling and applies extremely lowered but stable voltages.2) Balanced. For everyday use. Player uses a power optimization that enables frequency scaling and applies a balances values of lowered voltages.3) High Performance. Good for very big database, playlists and for playing codecs with high power consume. Player don't uses any power optimizations.
We already have GUI_BOOST, so we only need slightly rework it. In preference user be able to set timeout for this boosting (if 0 - no gui boost).
When you say "We already have GUI_BOOST", do you mean "it exists for other devices and I am aware of it", or do you believe it to be enabled for this particular device?
#define HAVE_GUI_BOOST is only present on the iPods, and it was only ever intended to be enabled on the PP (PortalPlayer) based iPods, but it seems to have snuck its way in to the configs for the iPod Nano 2G and iPod Classic, almost certainly accidentally by way of copy and paste error from reusing the device configuration from another iPod as a base during the port's creation.
Neither of which, in my personal opinion, actually require this as both have fairly powerful SoCs that are more than capable of providing a smooth user experience on their un-boosted clock frequencies. In fact, if it wasn't for this define, these devices wouldn't really ever need to boost at all, except for decoding (for the sake of efficiency) or if you were to use one of the more ridiculous codecs.Additionally, I do not believe a configurable timeout should be necessary at all.
Also in:sansaconnect.hsansae200.hsansaview.hsansafuze.hsansafuzev2.h
Neither of which, in my personal opinion, actually require this as both have fairly powerful SoCs that are more than capable of providing a smooth user experience on their un-boosted clock frequencies. In fact, if it wasn't for this define, these devices wouldn't really ever need to boost at all, except for decoding (for the sake of efficiency) or if you were to use one of the more ridiculous codecs.You have better solution for florin problem?
In practice, I'm strictly against boosting unless its absolutely necessary.
The 'solution' at this stage would be to not use a volatile experimental build.
Besides, I don't really think that a singular users unmeasured observation provides any clear evidence of a problem.
Page created in 0.072 seconds with 21 queries.