On Fri, 17 Mar 2023 14:40:21 +0100, Pavel Hofman wrote:
Dne 10. 03. 23 v 14:43 Pavel Hofman napsal(a):
Hi,
Speaker-webcam eMeet C980 Pro does not play, outputs only silent noise. The digital volume seems to be down.
dmesg:
[22406.805176] input: HD Webcam eMeet C980 Pro: HD We as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/usb1/1-7/1-7.1/1-7.1:1.0/input/input27 [22406.829048] usb 1-7.1: current rate 16000 is different from the runtime rate 48000 [22406.933044] usb 1-7.1: Warning! Unlikely big volume range (=10240), cval->res is probably wrong. [22406.933048] usb 1-7.1: [5] FU [PCM Playback Volume] ch = 1, val = -7168/3072/1 [22407.001043] usb 1-7.1: Warning! Unlikely big volume range (=3072), cval->res is probably wrong. [22407.001047] usb 1-7.1: [6] FU [Headset Capture Volume] ch = 1, val = -1536/1536/1
Maybe it's a problem with endianness, like e.g. reported in https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2181737.html
All the large numbers are divisible by 256.
But honestly I do not know what the fix should be - converting the min/max (min >>=8) or the resolution (res >>=8)?
What difference do the two methods make?
The difference is what are real values to be passed to the hardware. The driver scales down and shifts to 0-minimum for ALSA controls in anyway, so the appearance on user-space would be same, but the values to be actually applied to the hardware matter.
What effect does rewriting the cval min/max/res values actually have, with regards to the reading from the device (get) and writing to the device (put) methods?
You should check the actual raw values and see the influence on the hardware at first in trial-and-error manners. This also means to figure out the corresponding dB level, too. The rest depends whether it's a linear mapping with a parameter correction or better to replace with the fixed values, etc.
Takashi