https://bugs.kde.org/show_bug.cgi?id=494050
Niklāvs Koļesņikovs <89q1r1...@relay.firefox.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |89q1r1...@relay.firefox.com
--- Comment #1 from Niklāvs Koļesņikovs <89q1r1...@relay.firefox.com> ---
Frankly I have never heard of such a feature and I'm not aware of this being an
intentional thing in the Linux audio stack. I don't think this can even happen
with a jack based headphones but perhaps it would be possible when using USB or
Bluetooth interface, since the device could just disconnect, which would
trigger software fallback to the next device in priority list.
Or the device might be buggy and shutting off for exceeding some kind of
powerdraw limit (as an example USB is supposed to be limited to 500 mA or 2.5
W, although in some cases it could go to 1 or even 1.5A before triggering
safety disconnect from host side).
Either way, please avoid such events in the first place, since anything with W
for watts of sound power right in the ear canal is way more than human ears are
supposed to deal with and could easily cause lasting damage.
I suggest:
1. Turning down the volume of the source of the problem
2. If it's a bug, then please report the buggy client or hardware
3. If it's not a bug, it might be possible to use EasyEffects and its Autogain
filter with the Reference dropdown set to Momentary or one of the Geometric
Mean modes that includes the M letter in the brackets e.g. Geometric Mean (MS)
but, please, also limit the total device volume as per point 1 just in case
EasyEffects is not quick enough or something has gone wrong and the filter is
not getting applied.
Also do not use the PipeWire's new libebur128 filter, since the way its
implemented is not how I'd suggest it's used and it's not going to proect your
ears (at least I'd not expect it to).
--
You are receiving this mail because:
You are watching all bug changes.
