Bug 65251

Well, the max -34.5dB looks wrong.  It's fine to limit the raw value range, but then better to give the proper dB range as well.

(In reply to Takashi Iwai from comment #1)
> Well, the max -34.5dB looks wrong.  It's fine to limit the raw value range,
> but then better to give the proper dB range as well.

i am not sure if i understand correctly...

setting cval->dBmax directly in volume_control_quirks has no effect since 
after the function-call, the dB range is calculated from the raw range (line ~1004 in mixer.c):
cval->dBmax = (convert_signed_value(cval, cval->max) * 100) / 256;

also the existing quirks never define any dB values.

i dont know what a proper dB range would look like or what the meaning of cval->res is. my current dB range however also causes alsamixer to allow only two discrete values (-34.5dB and -35dB) without any steps in between.

should it be possible to obtain a proper dB range from modifying the raw range? in which way?

In that case, just add a patch like below.

--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -987,6 +987,9 @@ static int get_min_max_with_quirks(struct usb_mixer_elem_info *cval,
        if (kctl)
                volume_control_quirks(cval, kctl);
 
+       if (cval->dBmin != cval->dBmax)
+               return 0; /* already set in quirk */
+
        /* USB descriptions contain the dB scale in 1/256 dB unit
         * while ALSA TLV contains in 1/100 dB unit
         */

Yes, other quirks don't have dB overwrites just because they didn't need it.
But in your case, it'd make more sense to correct dB range as well.

with your patch the following heuristic settings deliver a good volume "range" and usable volume control sliders with pulseaudio.

cval->min = -9200;
cval->max = -9100;
cval->res = 1;
cval->dBmin = -100;
cval->dBmax = 0;

there is something wrong with the firmware of the gamecom 780. i dont know if some of these devices work correctly...

raw values of about -9100 deliver normal loudness, values at -7000 start getting too loud, values below -9200 are silence. so it was not possible to find a range which delivers a smooth transition from silence to normal loudness.

however, with a max raw value of something like -9100 (instead of 0, which is insanely loud) and a min valeu of -9200, the PCM volume control no longer works i.e. it only changes the volume in a very small lower spectrum of the headset (which actually corresponds to normal loudness).

with the parameters provided i still can use pulseaudio to get full control of the headset volume.
as a side effect the dB range determines an area below 100% in the volume control sliders of pulseaudio for which the slider has no effect. so a smaller dBmin value means a larger area in the volume control sliders which is not usable. below this area volume control works fine. this area of the pulseaudio master volume control corresponds to the PCM range.

so these changes actually somehow disable PCM volume control for the gamecom 780 and only allow a very small range of reasonable values.

Created attachment 115511 [details]
gamecom 780 volume quirks

The min -1dB looks also strange. It's better to pick up a bit more realistic value.  You can compare the actual output level with HD-audio on your machine, for example.

other devices on my machine have ranges like -50 to 0 dB.

i know, but thats because if i limit the raw range for the headset as i did (in order to prevent extreme loudness!) , i can hear no difference when using the pcm volume control. so it actually is somehow realistic?

Wait...  I thought the range between -9200 and -9100, you'd get the (audibly) different volumes.  But it's not actually, and you get only the almost same loudness no matter which value is taken between this limited range?

yes, there is no audiable difference between -9200 and -9100. the loudness in this region is however normal or reasonable. for values higher than -9100 it slowly gets louder (too loud). below about -9200 there is no sound at all (i can try to find out the exact value).

i am sure its a fimware problem.

Hrm, then it might be better to just skip this node (e.g. put it in mixer_maps.c).  Do you need to initialize this node value, or is it set well as default?

If an extra initialization (e.g. -9100) is needed, the last patch may be simpler although it looks puzzling to others; please add comments on it in the patch.

i am not sure if i understand you correctly.
the raw min and max values are the nodes?

default raw min value is -9472.
but everything below and including -9218 is complete silence. from -9219 upwards i have normal loudness. so it is better to force raw min to about -9200 in order to avoid this abrupt change from silcence to normal volume.

default raw max is 0.
values above -9100 are getting too loud. so -9100 seems a good choice for raw max.

i will provide a commented patch for mixer.c, or should this case be handled in mixer_maps.c?

Created attachment 115531 [details]
gamecom 780 volume quirks with comments

some remarks:

- the headset may use a C-Media (CM6300) chip which can also be used in unpowered desktop speakers. this may be the reason for the extreme loudness.
http://soundingboard.plantronics.com/message/41466#41466
http://www.cmedia.com.tw/ProductsDetail/page-p/C1Serno-25/C2Serno-26/C3Serno-0/PSerno-22.html

- not sure if this problem exists for all devices, or if the patch could raise problems for others.

OK, the latest patch looks good enough.  Could you give a proper subject and patch descriptions with your sign-off for merging to the upstream?  See Documentation/SubmittingPatches for details.

If you can't submit it properly, I'd like rather to fix in a different way.

Basically PCM volume control is useless, and it's just there not to set a wrong value.  What if skipping this node completely and keep untouched?

For skipping a control, we can create a usbmix_name_map[] containing a NID to ignore.  Passing NULL to name means ignoring it.  See ebox44_map[] in mixer_maps.c as an example.

In anyway, could you give lsusb -v output?

Created attachment 118381 [details]
lsusb output

sry for the delay, here is the lsusb output.

"id" in usb_name_map corresponds to "bTerminalID" in lsusb output?
however i created a name_map and set everything from 1 to 14 to NULL.
makes no difference.

would it be possible to derive the correct map from a datasheet of the chip?

Created attachment 118391 [details]
template for mixer_maps.c

ok, took me some time until i figured out how to read lsusb output -- which you btw can find in the prvious attachment. here is what i used to play around with the name map. still too loud.

OK what about the patch below?  It *disables* the mixer control on NID 0x09, and it initializes the default value to a fixed value.

Created attachment 118931 [details]
Test fix patch

works great! thank you!

i saw in quirks.c that there are some quirks defined for chips rather than devices. so this information may be useful for future quirks: the plantronics headset is probably based on a CM6302 (or CM6300) chip.

After recently upgrading to a kernel patched with this, I found that my Gamecom 780 headset had very low volume and I wasn't able to adjust it. Removing this patch and recompiling the kernel module fixed this. The sensitivity and cutoff issues are much preferable to having no control at all. At the very least, the volume controls should not be disabled if possible.

How "very low" is it?  The default volume was chosen as a sane value by the original reporter.  If you need a different value, please adjust and give back the best value.

It wasn't inaudible, but it was below a useful listening volume- even at max on the pulseaudio slider. At the very least, having the volume fixed at 'too loud' at least allows for some wiggle room with userspace volume control, though considering the adjustment issues related to the headset already, I don't know if it's possible. When I have a chance, I'll take a look and see if I can tweak some of the values.

Hello.

The issue I have with this patch is that setting my volume to 100% is equivalent to setting it to ~10% on Windows. I can hear sounds, but it's not at a comfortable level (it is too quiet).

Setting this value (-7200): u8 buf[2] = { 0xe0, 0xe3 }; -- at 100% my volume is now OK.

Would it be possible to adjust so that it starts being a bit loud at 30-40% ? Having my sound slider set to 100% feels wrong, I can't go higher than that for low-volume music / movies.

I'm not sure how to find the correct "range" or "values" that would make it perfect on my machine, do you have enough information with the values I wrote at the top of this message?

Thanks

refer to datasheet , there is dynamic range control (bit 7 of playback dac control)

(In reply to Jason Pleau from comment #24)
> Hello.
> 
> The issue I have with this patch is that setting my volume to 100% is
> equivalent to setting it to ~10% on Windows. I can hear sounds, but it's not
> at a comfortable level (it is too quiet).
> 
> Setting this value (-7200): u8 buf[2] = { 0xe0, 0xe3 }; -- at 100% my volume
> is now OK.
> 
> Would it be possible to adjust so that it starts being a bit loud at 30-40%
> ? Having my sound slider set to 100% feels wrong, I can't go higher than
> that for low-volume music / movies.
> 
> I'm not sure how to find the correct "range" or "values" that would make it
> perfect on my machine, do you have enough information with the values I
> wrote at the top of this message?
> 
> Thanks

hi,

for me setting u8 buf[2] = { 0xe0, 0xe3 } and volume control to 100% is very loud (probably not a good idea to wear them at 80% volume control and above). my usable volume range is between 20% and 60%.

in windows i usually set my volume control to 10%. even then some applications are much too loud.

i bought my headset in europe, it was bundled with a game... maybe there are GC780 devices with different chipsets or different firmware out there? maybe mine is defect? however, others (see links in the beginning ot this report) also have the same problem as me.

no idea how this can be resolved. if there is no clean solution, maybe there is a value that is ok for everyone? if i use u8 buf[2] = { 0x74, 0xdf } for example the maximum volume is louder but the volume control slider still works as intended.

I was fine with how the headset functioned prior to the initial patch being implemented. When I bought the headset, I quickly found that it had a comfortable range between 25% and ~40%, which is odd, but it's perfectly usable. Adding the quirk was a quick hack in an attempt to "fix" an issue had by a single user. The real issue seems to be with driving this particular chip, but an actual solution to that would be somewhat complex as far as I can tell.

i feel really sorry if my efforts messed things up for others in the end!
if the patch makes the headset unusable and safe for really everybode else -- which i however doubt -- it should probably be removed or dealt with in some other way?

if someone could show me an example, how to access and control the EEPROM (?) from within the usb audio stack (is this the right way to target this issue?) as Raymond suggested (page 30 of the datasheet??) and what i could possibly do there, i maybe could try to find a solution for the loudness problem, or at least break the device.

For me, without the patch, my headset is either completed muted at 24%, and way too loud at 25% volume. So the patch definitely helped. But the maximum volume is too low (again, this is a personnal perception, other people can have different opinions on what too loud / quiet is).

Would it be possible that instead of hard-coding the maximum volume, that it would be configurable by the user (the current value could be the default)? Either via a module parameter to snd_usb_audio, or via exposing a new control for example in alsamixer? I have no experience whatsoever in kernel/alsa programming, so it may very well be impossible to do that, I'm just throwing out ideas.

Thanks

Jason

I didn't mean to come off as harsh as I did. I use my headset day in and day out while working and the patch was quite frustrating- I couldn't figure out what had happened and spent a few hours reconfiguring and reinstalling my sound stack before I discovered this change.

Like I said, without this quirk, I have limited comfortable volume range, but the headset is very usable. I have to admit, I don't understand the full details of how these drivers (and quirks) work, but my understanding is that volume control is disabled and the volume is set at a fixed point, leaving it to userland utilities to handle the volume. Would re-enabling PCM volume control, like Jason stated, be a viable option? I suppose it still wouldn't be a true solution, though whatever that solution actually is lies beyond my capabilities and understanding.

So, it looks like there are differences between chips even though all are with the same USB ID.  Could you guys upload the content of "lsusb -v" (only for the device), and compare with each other?  We might see a difference there, at least.

Then, what we definitely need is to identify which *raw* value to be set.  Forget about mixer percentage representation.  You need to check the raw value like {0xe0, 0xe3}.  Note that the firmware might be really crazy and may handle it in a different endian.  So, you'd need to check each 1 value and each bit.

Also, check the baseline: any of you get the equivalent loudness as Windows ever?  And, try to compare the loudness with other devices, e.g. the onboard audio.  They have also dB expression (found in mixer), and you can guess the dB from that.

Created attachment 138581 [details]
output of lsusb -v

i cant find any dB values in windows. heres a matrix with different volume control percentages for normal/comfortable loudness:

earplugs    GC780
------------------------------------------------------------------
55%         100%      linux {0x74,0xdc} (current official patch)
55%         65%       linux {0x74,0xdf}
55%         55%       linux {0x74,0xe3}
55%         45%       linux {0x74,0xe6}
50%         10%       windows

Created attachment 138671 [details]
output of lsusb -v

I will have to test with more values tomorrow (I'll use the same ones as random237849 used)

However what I can tell is with official default value in the kernel tree :

Windows: 10% ~ Linux GC780: 100%
Linux earplugs: 20% ~ Linux GC780: 100%

There is quite a gap, I will post more values tomorrow.

Thanks for looking into this

Jason

Created attachment 138681 [details]
another output of lsusb -v

do the driver build all those controls which present in the block diagram of datasheet ?

do those controls have save dB ranges as specified in datasheet ?

I just replaced sound/usb/quirks.c:
 return snd_usb_gamecon780_boot_quirk(dev);
with 
 return 0;


That`s fixed volume control and they not too much loud.

Just testing: Linux: 100% = Windows: 100%

There 2 models of Plantronics 780: http://www.plantronics.com/uk/product/gamecom-780#models with the same USB ID.

Last models have fix in firmware.

Additional info: http://www.spinics.net/linux/fedora/alsa-user/msg11668.html

I think its fixed from amixer side.

> That`s fixed volume control and they not too much loud.

for me at least it reverts back to astronomical loudness.

> There 2 models of Plantronics 780:
> http://www.plantronics.com/uk/product/gamecom-780#models with the same USB
> ID.
> 
> Last models have fix in firmware.

then you probably have the model with the fixed firmware?

> Additional info: http://www.spinics.net/linux/fedora/alsa-user/msg11668.html
> 
> I think its fixed from amixer side.

this thread is from 2013 and was mentioned here already. nothing is fixed imho.

> So, it looks like there are differences between chips even though all are
> with
> the same USB ID.  Could you guys upload the content of "lsusb -v" (only for
> the device), and compare with each other?  We might see a difference there,
> at least.

i cannot see any difference in the lsusb outputs. is there another possiblity to distinguish different chipset or firmware versions?

> do the driver build all those controls which present in the block diagram of
> datasheet ?
> do those controls have save dB ranges as specified in datasheet ?

no, neither with nor without the current patch.

(In reply to random237849 from comment #40)
> > So, it looks like there are differences between chips even though all are
> with
> > the same USB ID.  Could you guys upload the content of "lsusb -v" (only for
> > the device), and compare with each other?  We might see a difference there,
> > at least.
> 
> i cannot see any difference in the lsusb outputs. is there another
> possiblity to distinguish different chipset or firmware versions?

The values the device returns for some verbs might be different.
For example, the dB ranges are taken by UAC_GET_MIN and UAC_GET_MAX verbs in addition to UAC_GET_RES.  Try to add some debug printk()'s in get_min_max_with_quirks() to show the values returned by each get_ctl_value() call there.

Try patch from this message, and paste what show:
http://www.spinics.net/linux/fedora/alsa-user/msg11664.html

Yeah, but the patch might not show the difference since it shows the reduced values.  But let's see...

Sry, i changed /usr/share/alsa/cards/USB-Audio.conf near line #46:
        "Logitech Speaker Lapdesk N700" 999
        "Logitech USB Headset" 999
        "Logitech Wireless Headset" 999
-       "Plantronics GameCom 780" 999
+#      "Plantronics GameCom 780" 999
        "Plantronics USB Headset" 999
        "Plantronics Wireless Audio" 999
        "SB WoW Headset" 999


And change system Audo Setup to Digital Stereo. (S/PDIF)

Created attachment 141371 [details]
patch for displaying raw device values

> The values the device returns for some verbs might be different.
> For example, the dB ranges are taken by UAC_GET_MIN and UAC_GET_MAX verbs in
> addition to UAC_GET_RES.  Try to add some debug printk()'s in
> get_min_max_with_quirks() to show the values returned by each
> get_ctl_value() call there.

would these changes (to mixer.c and mixer_maps.c) print out the values we need to compare?

in my case it says:
XXX XXX XXX XXX (mixer.c) XXX min = -9472 XXX max = 0 XXX res = 16 XXX
which is the same as reported in the alsa-user thread.

Created attachment 143391 [details]
output of `lsusb -v -s <gc780-device>`

Since 3.15.3 the 'no sound below 24%' has been resolved, but I'm also experiencing a reduced volume range (with maximum being a just-below-comfortable level).

The output of the above patch is:
XXX XXX XXX XXX (mixer.c) XXX min = -9472 XXX max = 0 XXX res = 16 XXX

Please also see the attached output from lsusb.

you possibly need to measure/calibrate the whole range of playback volume 


use audacity generate a full ampltitude sine wave

playback through the headphone and capture the signal back using mic 

check the amplitude of record signal while changing the playback volume

i think its fixed for all now.

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/sound/usb/quirks.c?id=542baf94ec3c5526955b4c9fd899c7f30fae4ebe

thx.

Hi, I have similar issue but I'm not using Plantronics Gamecom 780 USB Headset but using [Uptech SA110 USB 2.0 Audio Card](http://www.upmostgroup.com/tw/product/info/76/768#%E7%94%A2%E5%93%81%E6%B8%85%E5%96%AE), which is also using C-Media CM6300 chip.

For me the problem still not fixed on custom built v4.4.1 with Ubuntu 15.10 amd64.

The symptom:
    * no sound when output volume set < approx. 25%
    * volume too loud when output volume set > approx. 25%

Created attachment 206571 [details]
Output of lsusb -v of "Uptech SA110 USB 2.0 Audio Card"