Comment by rectang
5 years ago
Nearly all volume controls suck because by and large the software world is ignorant of the fact that loudness scales logarithmically. 99.9% of volume controls scale the output linearly.
5 years ago
Nearly all volume controls suck because by and large the software world is ignorant of the fact that loudness scales logarithmically. 99.9% of volume controls scale the output linearly.
This is in the same category of error as most programmers thinking that sRGB uses a linear light model. They try to do arithmetic like blending or blurring on the raw image data this inevitably does the wrong thing.
Similarly, most non-AAA game engines ignore the sRGB tone curve and treat all inputs and outputs as if they were linear, which results in unexpected brightness shifts in textures.
Up until very recently, Blender used linear light internally, but output that as sRGB without converting it to the appropriate gamma curve. There's guide after guide online on how to fix Blender by using "filmic" mode, which should be renamed to "not broken" mode.
Same thing as the colour picker in image editors like mspaint or Photoshop. They all have the same rainbow picker that has very visible discontinuities in the colour gradients, like a rippled curtain. It should be smooth, and it is, if using a perception-based colour model instead of linear light output straight to an sRGB monitor without any kind of colour correction.
This kind of thing has been going on for decades, and will continue for decades more. Programming is still a growth industry, so the average developer is inexperienced and doesn't know about these subtleties.
I think more people are aware of gamma correction now.
The best way to do that, if you are using shaders, is to have "fragColor.xyz = pow(col,vec3(1./2.2))"* on your last line. If it looks bad, look elsewhere, you are not allowed to touch that last line. The opposite should be done just after reading textures, if they aren't already linear.
*: sRGB actually has a weird transfer function, but it is closely approximated by a gamma of 2.2
For OpenGL, it will perform conversions automatically when sampling from texture with SRGB type, and opposite when writing to SRGB rendertarget (on desktop GL_FRAMEBUFFER_SRGB also needs to be enabled). I guess other APIs have similiar features.
This doesn't work for alpha blending since even if you output the color in the right space, the GPU might do blending in sRGB space and mess things up.
Best is to properly declare the target framebuffer as sRGB (if it is) and output linear colors while letting the GPU deal with it.
1 reply →
>This is in the same category of error as most programmers thinking that sRGB uses a linear light model. They try to do arithmetic like blending or blurring on the raw image data this inevitably does the wrong thing.
Relevant: https://www.youtube.com/watch?v=LKnqECcg6Gw
I thought Blender did convert to the sRGB gamma properly, the problem without “filmic” is that the highlights clip so badly without a roll off that lighting becomes very difficult and encourages bad workarounds.
I think Elite Dangerous Odyssey recently had this problem. Any ice planet at release was literally blowing out the sun in terms of brightness a thousand fold or so it seemed.
Could you provide good documentation about such thing?
I really liked this article: https://bottosson.github.io/posts/oklab/
OKLAB is a perceptual colour space, which is really useful for things like colour-picker tools, image editor controls, web development, CSS styles, etc...
You can use this kind of colour space to make two colours that are equally bright and equally saturated, but exactly 180 degrees apart on the colour wheel. If you use this instead of RGB hex codes, you get much better looking results. It'll make your app or web page "pop" with minimal effort...
There was a great post about gamma and sRGB from 2016 on HN a couple weeks ago[0] with some discussion[1]
[0] http://blog.johnnovak.net/2016/09/21/what-every-coder-should... [1] https://news.ycombinator.com/item?id=27721094
The classic video for this: https://www.youtube.com/watch?v=LKnqECcg6Gw
Charles Poynton has good references on this. His website is very 90s, but his books (a la Digital Video and HD) are the best clearly explained introduction to color science and gamma vs linear light coding that I've ever read.
https://www.poynton.ca/Poynton-color.html
> 99.9% of volume controls scale the output linearly.
Wrong. Windows's volume output is the percentage squared, and Linux PulseAudio's volume output is the percentage cubed. Nonetheless I would prefer that the volume output was exponential (2^(slider position / constant)). This way, pressing the "volume up" key 3 times always increases the volume by a constant factor, regardless if you're on loud or quiet speaker/headphones. Additionally, on loud headphones, you won't have to fine-tune the volume in the very bottom of the slider (eg. 1 is too quiet, 2 is a bit loud, 3 is painfully loud).
On Windows, I hide the default volume control and instead use Volume2[1] set to exponential mode. On Linux, I haven't found a good solution for getting PulseAudio to use exponential volumes.
[1]: https://irzyxa.blogspot.com/p/downloads.html
Pretty sure Android's volume control isn't linear either. At least perceptively I find the steps relatively even (which implies it's not linear).
When probing my Android phone's output in an oscilloscope, I also saw that it was not linear, and the volume increased more per level when louder. However I have not attempted to compute the exact curve. And I suspect it also differs between different versions of Android or different phones (my Android 11 phones has more volume levels than older phones), or with different audio APIs (some phones use tinyalsa, some use XML files to configure hardware volume gain, some don't).
You've given me an idea for a volume control - enter a function like x^2 or x^3, which is graphed (on a linear scale). Then pick an x. The y value will be your volume. (The component should reverse any platform specific non-linearity first.)
How would you compute the current volume level? You would have to either store the current x value (which could desync if you change the volume level using the OS volume control), or derive the nearest x from the current y value (which may be possible on PulseAudio, but I haven't checked if you're stuck to the nearest 1% or if you can get a more precise or dB level).
1 reply →
I used to own a BlackBerry 10 phone running BB10 OS. At the time, the dev team accepted suggestions on how to make the OS better, and I suggested they make the volume controls logarithmic instead of linear, and they did! I loved how quiet that phone would go while still remaining clear—I used to listen to audiobooks as I fell asleep at night, and rather than use headphones I would just set the volume to level 1 or 2 and put it on my pillow beside my ear. I haven't been able to do that with any other phone since because the volume doesn't go low enough, or if it does the audio is muddy.
I still have my old BB10 Passport. Weird form factor but that was an awesome device. It's too bad Blackberry really shit the bed with their OS and its lack of apps.
I still use my BB Classic as a daily driver. Really not looking forward to next April when 3G is switched off in Australia...
2 replies →
On every iPad I've seen, only the lower 3-4 (of 16) steps are normal indoor range. Even the 1st step is too loud at night. I need half-steps.
Is this due to linear vs logarithmic scaling? Or are people throwing wild parties where the iPad needs to fill a room with sound?
You can go to the control centre or whatever it's called when you pull down from the battery side of the screen and tap and hold the volume widget, you can then drag your finger up/down to change the volume in small increments. I have the same issue as you when I'm listening to stuff at night.
I agree - when trying to watch something next to a sleeping partner even 1 step above muted is too loud. Annoying. I often watch Netflix muted and read subtitles because of this. I guess I need headphones.
But I do really think a volume one half of the current lowest would be useful for me.
Headphones really are the solution. I used to have wired ones and these were quite uncomfortable to handle - cable messed up all the time, and even when you untangle them you have to avoid pulling it, so I used speaker most of the time anyway. I finally bought wireless buds a year ago and I really understood why so many people have these and talk about it - it's just too easy
> Or are people throwing wild parties where the iPad needs to fill a room with sound?
I’ll often use my iPad as a portable media player and max volume is nice for things like music while showering or cooking in the kitchen.
Literally no one wants a logarithmic scale to interact with though. '50% volume' should definitely be in the middle of the slider. The OS should translate that in to decibels. The maths behind it has no place in the UI.
I think no one argues for having it visually. They argue for having the GUI linearity converted to appropriate perceptual linearity, which depends on the medium.
It’s weird how I nominally know this but never really thought about the implications... How does the hardware world do it? I’d expect the normal way to make a volume control would be to have an adjustable-gain amplifier using the standard opamp circuit somewhere, but those aren’t logarithmic in any resistance you could wire to a knob, are they? (Yes, I am deeply ignorant about electronics.)
Logarithmic potentiometers.
https://learnabout-electronics.org/Resistors/resistors_09a.p...
Probably at least as far back as WW II we had linear taper pots and audio taper pots. Bam. Done.
It's exactly as you sugggest/doubt - in audio hardware you use potentiometers (the thing under the knob that has different resistance depending on the rotation) that are designed to have logarithmic scale.
A lot of digital audio applications just do programmable gain in the digital domain. My main rig extends samples to 42 bits and attenuates in the digital domain, then dithers to 32 bits for the analog conversion.
Same for brightness control, at least on my Linux computers. I vaguely remember it feeling right when I used a Mac.