Bug 62651 - [ALC269VB] Sound volume under Linux is two-three times quieter than under Windows
[ALC269VB] Sound volume under Linux is two-three times quieter than under Win...
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA)
All Linux
: P1 normal
Assigned To: Jaroslav Kysela
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-07 09:06 UTC by Felipe Contreras
Modified: 2013-11-28 17:10 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.11.3
Tree: Mainline
Regression: No


Attachments
alsa-info.txt (25.12 KB, text/plain)
2013-10-07 09:20 UTC, Felipe Contreras
Details

Description Felipe Contreras 2013-10-07 09:06:20 UTC
This is similar, if not the same, as bug #42654.

In Windows the maximum volume is at least twice as loud as it is in Linux. This is particularly clear in the speakers, but might also be on other output devices.
Comment 1 Felipe Contreras 2013-10-07 09:20:40 UTC
Created attachment 110361 [details]
alsa-info.txt

Seems the original attachment was silently dropped.
Comment 2 Takashi Iwai 2013-10-07 10:00:04 UTC
The output route (0x03 -> 0x0d -> 0x14) looks normal, DAC full set, EAPD on.

Could you test with model=nofixup option for snd-hda-intel?  I don't think this would fix your problem, but just to be sure to see that it's no bug in the current fixup code for your device.

Other than that, you can test to turn on each GPIO pin.  One of them might correspond to a speaker amp.

Or, there might be some hidden speaker pins, or a vendor-specific COEF setup.  Such a thing might be found in the extra *.INF file for Windows.
Comment 3 Takashi Iwai 2013-11-26 08:49:55 UTC
Also, you can try the following tweak of COEF stuff
   hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x12
   hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000
Comment 4 Felipe Contreras 2013-11-26 22:05:36 UTC
(In reply to Takashi Iwai from comment #3)
> Also, you can try the following tweak of COEF stuff
>    hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x12
>    hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000

That seems definitely louder for me.
Comment 5 Takashi Iwai 2013-11-26 22:35:12 UTC
Is it comparably loud as Windows?
If so, we can add a fixup for your machine with these verbs.
Comment 6 Felipe Contreras 2013-11-27 18:20:59 UTC
(In reply to Takashi Iwai from comment #5)
> Is it comparably loud as Windows?
> If so, we can add a fixup for your machine with these verbs.

It's not as loud, but it seems as loud as I can get in Windows without distortion (70%). Even if it wasn't, what's the problem in including this?
Comment 7 Takashi Iwai 2013-11-27 19:23:15 UTC
Such an extra amplification must be applied carefully since you can easily burn laptop speakers.  That's why I had to ask to be sure.
(Actually, too loud speakers may be a cause of harddisk damages.  Seriously. Some vendors implement EQ filter for avoiding such problems.)

But if it's not louder than Windows, it should be OK. (Not 100% safe, though.  There must be some reason why BIOS doesn't set up so.)

In anyway, I'm going to apply this change later together with another mic fix for Zenbooks.
Comment 8 Takashi Iwai 2013-11-28 10:21:05 UTC
Interestingly, I got a response from another UX31 owner, and he compared the hardware output level in details between Windows and Linux.  And his test result is that the both outputs are identical.  It was measured by another mic and compared objectively.

So, the likely difference in your experience is either you're using some plugin (like compressor) or software amplification on Windows without knowing.  His test was performed without software side effects explicitly.

Or, another possible reason would be BIOS.  BIOS may set up such coefficients depending on OS to run.

That being said, I cannot apply a patch that is risky for hardware damages for now blindly.  Meanwhile, it'd be not too bad to give an option if anyone doesn't care of such risks.  As a compromise, I'll prepare a patch to add these verbs but only when model=zenbook-boost option is given explicitly.
Comment 9 Takashi Iwai 2013-11-28 10:56:51 UTC
OK, now I added the patch to for-next branch.  It's targeted for 3.14, as this is no regression, and merely an enhancement.

You can add the verbs at the boot via specifying a firmware "patch" file.
Prepare a file like /lib/firmware/alsa/zenbook containing the following:

[codec]
0x10ec0269 0x10431517 0

[verbs]
0x20 0x500 0x12
0x20 0x400 0x3000

Then load it via patch=alsa/zenbook module option for snd-hda-intel driver.
Comment 10 Felipe Contreras 2013-11-28 16:32:58 UTC
(In reply to Takashi Iwai from comment #8)
> Interestingly, I got a response from another UX31 owner, and he compared the
> hardware output level in details between Windows and Linux.

What version of Windows? Also, what model? There's different UX31 models.

> So, the likely difference in your experience is either you're using some plugin (like compressor) or software amplification on Windows without knowing.

Did you even read what I said?

> His test was performed without software side effects explicitly.

And how did he do that? I asked how to do that in Windows.
Comment 11 Takashi Iwai 2013-11-28 16:51:49 UTC
(In reply to Felipe Contreras from comment #10)
> (In reply to Takashi Iwai from comment #8)
> > Interestingly, I got a response from another UX31 owner, and he compared the
> > hardware output level in details between Windows and Linux.
> 
> What version of Windows? Also, what model? There's different UX31 models.

Windows 7.  UX31A and E.

> > So, the likely difference in your experience is either you're using some plugin (like compressor) or software amplification on Windows without knowing.
> 
> Did you even read what I said?

Hrm, which comment did I miss in this thread?

> > His test was performed without software side effects explicitly.
> 
> And how did he do that? I asked how to do that in Windows.

I guess he just tested the bare system with Windows 7 Realtek driver.
The point is that your issue doesn't happen commonly on all relevant machines, thus the workaround cannot be applied blindly.  That's the reason to provide it only via a module option.
Comment 12 Takashi Iwai 2013-11-28 17:10:46 UTC
BTW, as a more constructive task:
if a warm-boot after Windows makes the output louder, please try to get the COEF dumps at both warm- and cold-boots for comparison.

What we need is just to record values with various COEF indices.
Calling two hda-verb commands like below, and the second command returns the current value:
     hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX $IDX
     hda-verb /dev/snd/hwC0D0 0x20 GET_PROC_COEF 0

where $IDX is the COEF index.   For example, 0x12 is for controlling some D-class amp stuff.

I don't know how many different COEF entries are present on Realtek codecs.
I guess it's enough to check up to 0x20.

Through comparison between good and bad cases, we might be able to find the significant COEF bits, which is better than the forcible amp boost.

Note You need to log in before you can comment on or make changes to this bug.