Created attachment 295435 [details] alsa-info output The usb-audio driver reports a pretty crazy decibel range with the Edifier G2000 speaker set: -12800 to -12700 (see attached alsa-info.sh). This means the speakers are silent for most of the PulseAudio volume control -- except the last bit, where they're very loud. This can be worked around with the ignore_dB=1 setting. PipeWire spots the ludicrous dB range and automatically disables decibel control. USB device ID: 2d99:a005. I don't know yet what the correct dB range is, since the speaker set cannot be plugged into the computer for measurement.
OK, then as a temporary workaround, could you try the patch below?
Created attachment 295441 [details] Test fix
(In reply to Takashi Iwai from comment #2) > Created attachment 295441 [details] > Test fix Thanks for your rapid response! I applied the patch and appears to work. - The volume control in GNOME sound settings is behaving sensibly. - There's no dB information reported for the speakers anymore in alsamixer. Shouldn't it be possible to infer the bad-dB quirk in obviously-wrong cases like this without the need for a device-specific entry? (For example here, -128dB and -127dB - the largest value below -96dB so meaningless from a human hearing point-of-view...)
Yeah, I thought of that, but wasn't sure what's the practical threshold. Maybe checking the max dB would be a good start (not the min dB -- which can be really low as long as the chip supports).
Created attachment 295463 [details] Test fix #2
Please check the patch in comment 5 instead of the previous one.
(In reply to Takashi Iwai from comment #6) > Please check the patch in comment 5 instead of the previous one. I tried the patch but it didn't work -- the reason is the cval->dBmax <= -9600 test is under an if (cval->dBmin > cval->dBmax) and for these speakers dBmin is < dBmax -- just really low. I've moved the cval->dBmax <= -9600 test up a level in the code, and this works as expected. I'll attach a patch of my version below for your consideration.
Created attachment 295495 [details] My spin on the fix
Doh, yeah, you're right, it was put in a wrong block. I think we don't need to factor out a function only for this single check, but otherwise the code looks good. I'll submit and merge the fix to upstream. Thanks.
Created attachment 295501 [details] The fix patch to be submitted
(In reply to Takashi Iwai from comment #10) > Created attachment 295501 [details] > The fix patch to be submitted Wait -- isn't that the same as Test fix #2 from comment 5?
My bad, a wrong patch attached. The correct version below.
Created attachment 295503 [details] Corrected patch to be submitted
Excellent -- that looks more like it. Tested OK here. I'll keep an eye out for this in my distro's kernel. Just for reference/commentary: from what I can tell from debug trace, etc. PipeWire ignores dB whenever dBmax is negative. PulseAudio was (for some reason) flipping the sign of a negative dBmax. Thanks again and have a good weekend.
It's good to know about pipewire behavior. The fix was submitted and merged to the upstream tree, which will be likely merged to 5.12-rc1 kernel then backported to stable trees.