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.
Created attachment 110361 [details] alsa-info.txt Seems the original attachment was silently dropped.
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.
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
(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.
Is it comparably loud as Windows? If so, we can add a fixup for your machine with these verbs.
(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?
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.
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.
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.
(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.
(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.
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.