-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Thursday, April 07, 2016 5:27 PM To: Kailang Cc: (alsa-devel@alsa-project.org) Subject: Re: Dell USB audio driver workaround
On Thu, 07 Apr 2016 09:05:52 +0200, Kailang wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, April 06, 2016 5:37 PM To: Kailang Cc: (alsa-devel@alsa-project.org) Subject: Re: Dell USB audio driver workaround
On Wed, 06 Apr 2016 11:22:43 +0200, Kailang wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, April 06, 2016 4:57 PM To: Kailang Cc: (alsa-devel@alsa-project.org) Subject: Re: Dell USB audio driver workaround
On Wed, 06 Apr 2016 08:29:12 +0200, Kailang wrote:
Hi Takashi,
Dell had USB dock. Maybe firmware issue, the master volume always keep at 0x57. Attach patch will fix it to keep at Max volume.
Could you help us to update it?
Well, I don't get how this patch works..
diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index 4f85757..84d9a4e 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -846,6 +846,12 @@ static void
volume_control_quirks(struct
usb_mixer_elem_info *cval, { struct snd_usb_audio *chip = cval->head.mixer->chip; switch (chip->usb_id) {
- case USB_ID(0x0bda, 0x4014): /* Dell workaround */
if (strstr(kctl->id.name, "PlaybackVolume") != NULL) {
cval->min = 0x0000;cval->max = 0x0000;}break;So, this means that this value has to be fixed to 0? If yes, can't we simply remove this volume instead?
Yes, but it need to set Max volume to 0. This is test
on my site.
Because it will rewrite 0x57 value to codec register when
driver is loaded.
And keep 0x57 volume value all the time. So, Master volume
will lower than windows machine.
This case which driver fail to build the alsa mixer(This is
firmware cause it). So, no hardware volume control on this.
If the Max volume value is 0, system will not set default
value 0x57 for first time loading driver.
Which values (min/max) does this FU take and which values
are buggy?
Max value.
Sorry, my question wasn't clear. "What" min and max are they? min=0 and max=0x57?
Oh! Sorry. It's my wrong. I forgot.
Unit: 16 Control: name="PCM Playback Volume", index=0 Info: id=16, control=2, cmask=0x3, channels=2, type="S16" Volume: min=-16256, max=0, dBmin=-6350, dBmax=0
0x0 (codec reg) = (-16256) (USB vloume level) 0x57(codec reg) = 0xEC00(USB vloume level) 0x7F(codec reg) = 0x0000 (USB vloume level)
And, your patch changes both min and max to be 0. That is, it accepts only 0. Does it mean that this FU isn't any proper volume control?
cval->max original is 0. cval->min => I set it to 0. It will be not rewrite 0x57 value to codec.
But it is not buggy value. Min and Max value are all safe.
It got right value from firmware.
But if Max value > 0, maybe < 0x57, it will be not rewrited value. Please look for belowing function.
Our USB firmware fail for build alsa mixer. And we fixed
the firmware already.
But Dell didn't want to update firmware. Because they
release this MP more and more.
So, they request a workaround for this unit.
Below is in mixer.c
static int mixer_ctl_feature_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct usb_mixer_elem_info *cval = kcontrol->private_data; int c,
cnt, val,
oval, err; int changed = 0;
if (cval->cmask) { cnt = 0; for (c = 0; c < MAX_CHANNELS; c++) { if (!(cval->cmask & (1 << c))) continue; err = get_cur_mix_value(cval, c + 1, cnt, &oval); if (err < 0) return cval->mixer->ignore_ctl_error ? 0 : err; val = ucontrol->value.integer.value[cnt]; =========>
This line will get default value( 0x57) from mixer.
So, do you mean that writing the default value (0x57) from the firmware causes the trouble, and it has to be 0?
val = get_abs_value(cval, val); if (oval != val) { set_cur_mix_value(cval, c + 1, cnt, val); changed = 1; } cnt++; } } else { /* master channel */ err = get_cur_mix_value(cval, 0, 0, &oval); if (err < 0) return cval->mixer->ignore_ctl_error ? 0 : err; val = ucontrol->value.integer.value[0]; val = get_abs_value(cval, val); if (val != oval) { set_cur_mix_value(cval, 0, 0, val); changed = 1; } } return changed; }
Judging from your description, the firmware gives the bogus max value (white min value = 0) and a volume higher than zero is attenuation?
I had not test Max value > 0 and < 0x57. cval->min = 0x0000; => this is original. I just post it.
Remove this line is OK.
Well, I still don't understand clearly. What do you mean here as "original"?
thanks,
Takashi
------Please consider the environment before printing this e-mail.