[alsa-devel] [RFC] hda/realtek filtered headphone output

[Takashi Iwai]

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