Rockbox General > Rockbox General Discussion

Setting limit volume on rockbox?

<< < (4/11) > >>

Llorean:
Increasing binary size decreases RAM available for the audio buffer which decreases battery life. This effect is most noticeable on the Archos players where even a small decrease in buffer can have noticeable effects, and is much less notable on the software codec targets but still a concern.

I think having an autoload.cfg file where you can set the volume (rather than having it preserved across boots) is a better solution, as this provide a lot more useful functionality as well (if you change settings for your car, you'll know they'll always restore to earphone settings on a reboot, or whatnot).

The binary size argument *must* be applied to ALL features. I don't know if you were around for the volume scale change from % to dB. At that time, MANY people objected. And it would be trivial to have an option to display volume in the old way, as %, on the status bar to go alongside the dB scale, but that tiny amount of code was deemed to be not worth it, as it provided no real functionality or benefit. I see the limited the same way. It's tiny, but it's fluff as all it does is something that is for most users useless, and for those few users it affects something that can be avoided by simple use of their brain and hands.

While the audioscrobbler support is *much* bigger in binary size increase, it's also something that can't simply be accomplished otherwise (other than by tracking listening habits on a sheet of paper and typing up the log, something well outside of 'reasonable').

bascule:

--- Quote from: Llorean on October 20, 2006, 09:22:57 AM ---I think having an autoload.cfg file where you can set the volume (rather than having it preserved across boots) is a better solution, as this provide a lot more useful functionality as well (if you change settings for your car, you'll know they'll always restore to earphone settings on a reboot, or whatnot).
--- End quote ---
Absolutely. This would be really useful functionality and it is implemented using existing functionality (loading a config file).

You could set just the volume, or put in the whole gamut of settings...


--- Quote from: Llorean on October 20, 2006, 09:22:57 AM ---...audioscrobbler...it's something that can't simply be accomplished otherwise...
--- End quote ---

True, but for my money, this is absolute fluff. How is uploading runtime db info to a third party website more 'beneficial' than core audio playback and information functionality?

Could the audioscrobbler patch not have been implemented as a plugin or even an external app querying the Tag Cache database when the player is hooked up to a PC?

I know we're slightly OT now, but maybe the easiest solution to the Archos problem is an optimised Release 3.0 containing a whole load of the most recent enhancements and then accept that anything after that may have to be hand-crafted by removing features and re-compiling?

This would leave the field open for less constrained development for the more powerful targets.

The messy solution, of course, is a code fork, allowing the colour/video/fluff/PDA/etc. targets to go their own way, and keeping a tight version for the audio-only/constrained targets.

Llorean:
I'm not defending the way it was implemented. I personally think it's fluff as well. But actually, as an external app or plugin it wouldn't be able to offer the same functionality if my understanding is correct.

What it currently does, to my understanding, is log songs as you play them. An external app or plugin would have to compare the database to a copy of the database representing what it was the last time logging occurred and generate a log based on that, which would then become impossible if you were running the app from a different computer, or if the runtimeDB had to be regenerated, or any of a host of other reasons.

But this topic is not about Scrobbler support at all.

Genre9mp3:

--- Quote from: Llorean on October 20, 2006, 09:22:57 AM ---Increasing binary size decreases RAM available for the audio buffer which decreases battery life. This effect is most noticeable on the Archos players where even a small decrease in buffer can have noticeable effects, and is much less notable on the software codec targets but still a concern.
--- End quote ---

True but unreasonable and excessive for the feature we are talking. The difference would be way far from noticable even on a HDD Archos player. But as I said, I understand your point of view.

Llorean:
The point isn't that *this* feature would be noticeable. The point is that there are many many "very small" features out there, and they would add up. Is a volume limiter more useful to you than a second option in Volume display that's %? Because we had a *lot* of people who wanted that back when we changed it.

Or since they're both 'very small' we could add both... but eventually it adds up, and it's better to try not to add things in advance if they don't actually *add* something anyway.

Navigation

[0] Message Index

[#] Next page

[*] Previous page