The real problem he has is different levels of audio and missing normalization of audio levels. You shouldn't get into the situation of wanting to quickly adjus

The real problem he has is different levels of audio and missing normalization of audio levels. You shouldn't get into the situation of wanting to quickly adjust audio levels in the first place (although I agree that any latency in adjusting the volume is inacceptable). Normalization (especially the real-time case) is an interesting topic. I've experimented with crude algorithms in the past to take all audio samples in a fixed window and then normalize them all to the same level [0]. But it's harder than you'd think. First there is a difference for humans in how loud they perceive the same sound to be at different frequencies. So any measurement function needs to take that into account. ReplayGain does this btw [1]. Then, there is the problem that if you make this window too short, you turn the audio into a garbled mess. If you make the window too long, you increase latency. This is a big deal for streaming settings. And last, you have the problem that silent periods aren't silent. E.g. if the person takes a breath, the level is increased to amplify the muffled sounds of the road nearby to levels to make you think they stand in the middle of a highway :). It's an interesting problem and while I doubt that it'll be solvable by simple hardcoded algorithms, ML might solve it. Then we can finally enjoy audio without having to manually press +++ and --- all the time :). But you know maybe we'll have different problems similar to the inability of phones to photograph the orange sky over SF. [0]: https://github.com/est31/js-audio-normalizer https://github.com/est31/js-audio-normalizer [1]: http://wiki.hydrogenaud.io/index.php?title=ReplayGain_specification#Loudness_filter http://wiki.hydrogenaud.io/index.php?title=ReplayGain_specif...