Resending with the correct Cc to alsa-devel ML...
On Mon, 05 Mar 2018 12:55:30 +0100, Takashi Iwai wrote:
On Sat, 03 Mar 2018 13:06:49 +0100, René Rebe wrote:
Hi all,
testing some new laptops, I noticed the headphone frequency response was lacking bass. First I noticed this in the Lenovo T470s, and later I found this also be the case on Surface Pro 2 and 3. The Dell XPS13 may also be affected, but I had to return it before I found out the solution on the other machines:
https://www.youtube.com/watch?v=a1YkPtfC4LI
I had not yet sent the patch because a) I was too busy and b) I wanted to review this further.
As the other day I got a Lenovo ideapad 720s to test with exactly the same issue, here is the current hacked patch:
https://svn.exactcode.de/t2/trunk/package/base/linux/surface-audio.patch
However, given that all newer realtek codecs that came on my desk are affected, maybe there is something wrong with the hda_auto_parser.c - I did not yet fully grasp all the logic of that.
As you can see in the patch and video (…) the problem is the signal routing of NID 0x15 or 0x21 (depending whether it is an older, or newer codec). This is the headphone out, and as far as I can see the auto_parser assigned the index 0 pcm output (NID 0x0c) which result in this filtered frequency response, likely intended for the laptop’s speakers? Using the next NID (I guess that was 0xd?) results in a full frequency response and at least to my ears is immediately hearable and obvious.
Without this fixed routing the headphone sounds like a PC speaker in a coke can.
So the question for the authors and HDA experts: Can this be fixed in the auto_parser, or is my patch (which btw. has to small unrelated cleanups) modulo potentially some renaming of the enum and function, now that more than the Surface is affected, the way to go? If this can be fixed more generally I would be happy to hear!
Could you give the output of alsa-info.sh? We need to check the details of the codec topology.
In general, the right approach is to fix at parsing the routing, not fiddling with the codec routing dynamically at initialization.
Currently the easy fix would be to provide the fixed DAC connection list. Maybe we can enhance the generic parser to receive some hints for DAC selection. The routes are determined by calculating "badness" values per route, so in theory, we can give some badness values depending on the target pin type (headphone, speaker, etc).
thanks,
Takashi