Setting limit volume on rockbox?

[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]

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).

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...

...audioscrobbler...it's something that can't simply be accomplished otherwise...

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]

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.

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.

[Genre9mp3]

Yes... so this leads us back on how someone weighs the benefit of a feature. And I still think that this feature adds something even if I don't actually need it myself. I must agree though that the autoload.cfg idea would be better to have.

So I guess, that's probably the benefit of arguing about functionality

[Rincewind]

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.

As I said, the limit can be accomplished with the autoload feature. It seems to me that you don't object to that. So I would say that a better way to settle an argument over a feature request is to turn the request into something more general that we can all consider useful.

I was around when the db change came up and found the whole argument funny and entertaining because I couldn't care less. But it also shows that many people (especially non-developers) care about things that we (If you don't object that I call myself a developer here) don't consider to be important.

Maybe important isn't the right word here, but don't know how to describe my thoughts in english better.

[Llorean]

I just see the volume limiter as a "convenience" instead of a feature, since a human can easily limit the volume by simply not turning it up.

And in my mind that makes it very difficult to justify, independent of size.

I can easily see how it would be important to some people, but I really don't understand why those people find it so difficult to not turn up the volume. I guess that's my problem, that I can't see their point of view at all.

[Genre9mp3]

I can easily see how it would be important to some people, but I really don't understand why those people find it so difficult to not turn up the volume. I guess that's my problem, that I can't see their point of view at all.

This is why I consider that this feature/convenience/whatever would "add" to the project. From my point of view, if some users find important something, then this worths to be added (as long as it doesn't add any reasonable disadvantages). It's just how I see Rockbox. Functionality that you can't get with retailOS.

[baobab68]

If I might add my 2c?

I am very conscious of protecting my hearing, and always *try* to keep the volume low as possible.

But:

- the player is in my pocket and I can't read the volume level
- I can't resist turning it up when the best part of a song comes on!

I don't know the overall status of the project etc though, as the other participants in this thread do, but as a user I know that I am a sucker for a good song..!

[saratoga]

I don't see the point of argueing about this.  If someone wants the feature, let them create a patch for it, then we can evaluate the patch and decide if its worth including, or if we should just make it an optional feature for 3rd party builds.

[lowlight]

There's acutally a dangerous bug in the volume menu...the list wraps allowing you to go from min->max.  Since the volume updates as you scroll, be careful

[gorman]

I just see the volume limiter as a "convenience" instead of a feature, since a human can easily limit the volume by simply not turning it up.

And in my mind that makes it very difficult to justify, independent of size.

I can easily see how it would be important to some people, but I really don't understand why those people find it so difficult to not turn up the volume. I guess that's my problem, that I can't see their point of view at all.

Hi! I'm resurrecting this thread after using the search feature on the forums, looking for just this function.

I have a rockboxed Gigabeat and I believe that for certain targets this function could be more important than for others. On the Gigabeat it's entirely too easy to raise the volume by mistake, considering it's bound to the up/down commands on the touch-sensitive cross. It happened to me the other day and I risked seriously damaging my hearing.
It probably might be easier to take away volume control from the cross, as I mentioned somewhere else, but I just wanted to point out that it's not just a matter of "it's not tough not to turn up the volume".

Cheers!

[JeoL]

As a user who is prone to making mistakes, I think this option would be very good.

[Febs]

You can achieve a similar result in Rockbox right now by using the ReplayGain pre-amp and Equalizer pre-cut settings.