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@xxxxxxxxxxxxxxx/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
