Video gamers worldwide may be risking irreversible hearing loss and/or tinnitus—persistent ringing/buzzing in the ears—finds a systematic review of the available evidence, published in the open access journal BMJ Public Health.
What evidence there is suggests that the sound levels reported in studies of more than 50,000 people often near, or exceed, permissible safe limits, conclude the researchers.
And given the popularity of these games, greater public health efforts are needed to raise awareness of the potential risks, they urge.
While headphones, earbuds, and music venues have been recognized as sources of potentially unsafe sound levels, relatively little attention has been paid to the effects of video games, including e-sports, on hearing loss, say the researchers.
Hmm, shouldn’t that be a driver level task?
No, it isn’t. OS and app volume controls are not implemented on driver level, but in each application individually, or you wouldn’t be able to change OS volume and in-app volume independent of each other. It’s simple math, multiplying audio sample values with a coefficient, best done in 32 bit floating point.
The question is not whether to do the math at driver level or in the userspace. The question is: if the user sets their volume slider to the middle, what value that coefficient should be? Most apps use simple linear correlation (middle point halves values which is 6 dB of attenuation or -6 dB(FS)) which is not how human hearing works. Log volume control would have the middle point at, eg, -40 dB(FS) and zero point at -80 dB(FS), giving psychoacoustically useful range in both halves of the bar. This is how analog volume controls on amplifiers work (not exactly so, but pretty close).
Driver level volume control can be done, but then you’d need to open your sound card control app and set it there. It would be an addition to OS and app volume controls. It would not be tied to OS or in-app volume controls or affected by standard multimedia keys on your keyboard. And if you decide to do OS volume control at driver level, in-app volume controls would still need to exist and be at the mercy of the app devs competency at implementing it.
Yeah, that all makes sense.