Setting limit volume on rockbox?

[VietPho]

Sigh... 2 weeks ago I accidently put the volume of my 60 gb ipod video rockbox to the max and I killed my Ipod headphones
I just bought the Creative EP-630 for 28$ off Amazon and it would suck if I accidently blow out my new headphones.

My question is how do I set a limit to volume for my rockbox? I was able to do it on apple original firmware, but I can't find out how to do it on rockbox.

[Genre9mp3]

I don't think there is a setting anywhere to set a "volume cap" or something, but I think this would be a nice thing to have. Maybe you can add this to feature requests in the tracker. On a side note, I wouldn't worry to blow out my headphones but I would worry for my ears.

[Llorean]

You can always set the precut in the graphical equalizer menu. For all practical purposes it's a similar idea.

[Genre9mp3]

You can always set the precut in the graphical equalizer menu. For all practical purposes it's a similar idea.

Isn't precut just adjusting the overall gain of the EQ? Surely though, you could end up to a similar functionality by setting a negative precut value so even max volume wouldn't be so loud. But you should have the EQ enabled for that (extra CPU load) and I don't think that it's a similar idea to just set a volume cap somewhere in the settings (eg. -20 dB) so the user won't be able to go further than that.

[pabouk]

Other disadvantages of using the precut setting:
- the signal will be digitally attenuated - so your S/N ratio will be lower (lower audio quality)
- the volume dB scale will be shifted

[Llorean]

But the *advantages* are:

- Does not increase binary size at all beyond current.

Seriously, I don't think it's worth wasting any binary size on an option that simply prevents user error, especially when there are very similar functions that can be achieved using both the equalizer and replaygain (though not ideal, at least they don't increase the binary size any since they're already there).

[L]

If you get proper earphones, they wouldn't blow that easily.

[Genre9mp3]

But the *advantages* are:

- Does not increase binary size at all beyond current.

I disagree with that point because I don't think that adding such an option will increase the binary size so much that we have to worry about. Sure, binary size is an important factor to take into account but so many features are being added into CVS in daily basis and increase the binary size much more than this feature would.

And to quote LinusN from yesterday's logs:

let's just stop adding features to rockbox - the binary size is too big

[Llorean]

Yes, *features* are being added. Things that cannot be done without adding code.

Volume limiting can be done without adding code by a user not increasing the volume.

Saying "it's small" means nothign. It still increases the code size for very very very little added gain.

[Genre9mp3]

Volume limiting can be done without adding code by a user not increasing the volume.

Actually this is not a volume limiting feature, it is a "user error" prevent feature, and I _do_ think that such features are worth adding.

Some may find this feature handy, others may won't gain anything from it and never use it (I never experienced such a problem, so I can say that I wouldn't gain for it) but I don't think that we shouldn't add features to conserve binary size at a small size.

We just see it differently... You see it as a "very very very little added gain" feature while I see it as a "very very very little binary size increase" feature

[Llorean]

Yes, but here's the deal: The more very very very littles you add in, the bigger the binary gets.

It's already officially "too big" (rombox doesn't fit) and this is a feature that if included should go to all targets. How little the size is doesn't matter, if it increases the binary at all. You weigh that something is added vs how beneficial it really is, and to me this doesn't seem like something that benefits Rockbox as a whole. It makes the binary bigger for everyone who doesn't use it, makes it harder still to get Rombox down to a usable size, and benefits a very small number of people who for some reason can't be bothered to check their volume levels.

[Genre9mp3]

I agree. We just weigh it differently.

I'm aware of the rombox problem, but this is something that needs to be handled in a different way otherwise we won't be able to add new features anymore.

[Llorean]

I just don't want features that only provide seem to be beneficial to those who can't be bothered to pay attention to have a negative impact on everyone else's battery life.

A whole host of minor "safety" features could be added (more confirmations on things like file overwrites, automatic precut setting in the equalizer, etc, etc) each "very small" and each slightly decreasing the battery life of everyone who's willing to actually take care of those settings themselves.

Replacement firmware is not something to enter into lightly anyway, and I don't see all this fluff as being beneficial to a user who actually cares about what he's doing, meanwhile it does have a negative effect (albeit small, but cumulative) on all the users who have no use for such fluff.

So, that's why I put such a strong negative weight on what seems like such a minor feature. In the case of any small thing, it can be considered "minor" but at the same time, once it's in, it's *VERY* hard to remove it without huge amounts of objections, so it's better to say "Is this valuable enough to sacrifice something else for later?" and in my opinion it's very certainly not.

[Genre9mp3]

Though I can clearly understand your point of view on this in general, I can't understand how an extra setting can decrease battery life.

[Rincewind]

I don't think that the binary size killer argument should be applied to such a small feature.

perhaps this could be done with only 2 lines of code - just an "if statement" in the right place (plus the menu option to set it, which should be small with the new settings system, too).

recently the last.fm log got commited - I would call that feature a binary size waste.

Every serious software tries to protect users from damages to their health. Btw. I think that Jonathan Gordon's idea to set settings to always start at a default value when starting the player is more useful than an overall volume limit, because I want full volume when I use line-out and the accidential risk of full volume is only there when you start the player and don't know where it was when you shut it off the last time.