Nazo
2[H]4U
- Joined
- Apr 2, 2002
- Messages
- 3,672
Ok, so I love Android and all of the openness and choices it gives its users compared to iOS, however, there is one thing and one thing only that Apple has had Google beaten on pretty much from the start, and it's one of the most senseless stupidest things possible: the volume control. Google for some reason elected to limit the number of positions the volume can be set to to a very tiny number of options (15 to be specific.) The funny thing is, it's not even something hard-coded in, just a variable that's defined during compilation and can't be externally overridden. The unfortunate result is volume that's either annoyingly quiet or painfully loud. I've tried all sorts of tricks including trying to modify the volume of my entire music collection to an arbitrary value (I tried a bunch of different things, but I think I ended up with 93.5dB being the least annoying value I could come up with, and even that just wasn't right. Even when PowerAmp implemented ReplayGain (though to be honest it seems like it doesn't work right or something to me) and I was able to set odd gain values I just couldn't get the volume quite right. I've also tried third party apps that pretend to try to give you precise volume control, but in the end they just don't work at all or do a horrible job (or in one case, would work at first and then the moment you played anything else it would just reset -- I'm guessing it used the ALSA mixer method, but that sadly isn't a very good method.)
So finally it seems I've found a fix thanks to a couple of kind users of Head-Fi.org: http://chrisdube.com/increase-number-of-volume-steps-in-android/ Basically the idea is to use Baksmali to "decompile" the framework jar, you edit the /android/media/AudioService.smali file it produces and search for a variable array with some four or so 0xft values and change the first of those 0xft values to something more (I started out with 0x21t for 33 positions, but in the end I found that 50 -- eg 0x32t works best with the best balance of control and getting to the volume you want quickly when holding the up or down.) Then just "Smali" it to "recompile" essentially and overwrite the classes.dex file it produces in the original framework.jar file and replace that on your Android device, then rebooting to apply the change.
It's a bit of a pain to do -- especially annoying for me is how long it takes for the Smali recompile to run (but I have a weak CPU in this minimal computer after all) -- it requires a PC as there seems to be no way that I can find at least to do this from a tablet/phone, and finally and most importantly, you must do this again every single time you update the OS since it will change the framework.jar file to whatever is in the updater files though. Honestly, I'm considering trying to figure out how to submit a patch to the CyanogenMod team as at least, but I'm really not very good with that stuff. (I don't suppose anyone here is?) It's my hope that if CyanogenMod should fix such a basic bug, maybe people might start to realize and fix it properly for a change. (Given the rather painful results of the built-in 15-position volume control and the way it kind of encourages many people to listen too loud rather than just right I maintain that a higher number still makes more sense as a default regardless of whatever theoretical reasons they might have had behind setting the volume control to such a coarse value. Really though, the best long-term solution would be some way for the user to change it rather than some default being forced on them, but, if there MUST be a default it should be reasonable IMO...) Eventually it would presumably make it into the stock OS once people realized what a difference it makes...
So finally it seems I've found a fix thanks to a couple of kind users of Head-Fi.org: http://chrisdube.com/increase-number-of-volume-steps-in-android/ Basically the idea is to use Baksmali to "decompile" the framework jar, you edit the /android/media/AudioService.smali file it produces and search for a variable array with some four or so 0xft values and change the first of those 0xft values to something more (I started out with 0x21t for 33 positions, but in the end I found that 50 -- eg 0x32t works best with the best balance of control and getting to the volume you want quickly when holding the up or down.) Then just "Smali" it to "recompile" essentially and overwrite the classes.dex file it produces in the original framework.jar file and replace that on your Android device, then rebooting to apply the change.
It's a bit of a pain to do -- especially annoying for me is how long it takes for the Smali recompile to run (but I have a weak CPU in this minimal computer after all) -- it requires a PC as there seems to be no way that I can find at least to do this from a tablet/phone, and finally and most importantly, you must do this again every single time you update the OS since it will change the framework.jar file to whatever is in the updater files though. Honestly, I'm considering trying to figure out how to submit a patch to the CyanogenMod team as at least, but I'm really not very good with that stuff. (I don't suppose anyone here is?) It's my hope that if CyanogenMod should fix such a basic bug, maybe people might start to realize and fix it properly for a change. (Given the rather painful results of the built-in 15-position volume control and the way it kind of encourages many people to listen too loud rather than just right I maintain that a higher number still makes more sense as a default regardless of whatever theoretical reasons they might have had behind setting the volume control to such a coarse value. Really though, the best long-term solution would be some way for the user to change it rather than some default being forced on them, but, if there MUST be a default it should be reasonable IMO...) Eventually it would presumably make it into the stock OS once people realized what a difference it makes...