Bug 211929

Summary: USB audio bad decibel data: EDIFIER G2000
Product: Drivers Reporter: James Ettle (james)
Component: Sound(ALSA)Assignee: Jaroslav Kysela (perex)
Status: RESOLVED CODE_FIX    
Severity: normal CC: tiwai
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 5.10.16-200.fc33.x86_64 Subsystem:
Regression: No Bisected commit-id:
Attachments: alsa-info output
Test fix
Test fix #2
My spin on the fix
The fix patch to be submitted
Corrected patch to be submitted

Description James Ettle 2021-02-25 08:55:43 UTC
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.
Comment 1 Takashi Iwai 2021-02-25 11:22:09 UTC
OK, then as a temporary workaround, could you try the patch below?
Comment 2 Takashi Iwai 2021-02-25 11:22:40 UTC
Created attachment 295441 [details]
Test fix
Comment 3 James Ettle 2021-02-25 17:34:34 UTC
(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...)
Comment 4 Takashi Iwai 2021-02-26 09:29:41 UTC
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).
Comment 5 Takashi Iwai 2021-02-26 09:36:14 UTC
Created attachment 295463 [details]
Test fix #2
Comment 6 Takashi Iwai 2021-02-26 09:37:18 UTC
Please check the patch in comment 5 instead of the previous one.
Comment 7 James Ettle 2021-02-26 21:23:22 UTC
(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.
Comment 8 James Ettle 2021-02-26 21:25:07 UTC
Created attachment 295495 [details]
My spin on the fix
Comment 9 Takashi Iwai 2021-02-27 08:00:44 UTC
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.
Comment 10 Takashi Iwai 2021-02-27 08:11:07 UTC
Created attachment 295501 [details]
The fix patch to be submitted
Comment 11 James Ettle 2021-02-27 08:22:27 UTC
(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?
Comment 12 Takashi Iwai 2021-02-27 09:01:34 UTC
My bad, a wrong patch attached.  The correct version below.
Comment 13 Takashi Iwai 2021-02-27 09:02:04 UTC
Created attachment 295503 [details]
Corrected patch to be submitted
Comment 14 James Ettle 2021-02-27 10:38:59 UTC
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.
Comment 15 Takashi Iwai 2021-02-27 17:39:33 UTC
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.