[ corrected to the right ML ] On Thu, 23 Aug 2018 14:37:39 +0200, René Rebe wrote: > > Hi, > > On 23 Aug 2018, at 14:31, Takashi Iwai <tiwai@xxxxxxx> wrote: > > > On Thu, 23 Aug 2018 13:10:39 +0200, > > René Rebe wrote: > >> > >> Hi Takashi, > >> > >> I uploaded the requested log but did not hear back. > >> The limited headphone frequency response (aka high-pass) is still an issue with 4.18. > >> I rebased the patch: > >> > >> https://svn.exactcode.de/t2/trunk/package/base/linux/hda-realtek.patch > >> > >> This affects more devices (e.g. Dell XPS 13, ThinkPads) any maybe many more which I do not have at hand. > >> > >> Further guidance how to proceed with this issue to get it fixed upstream is welcome. > > > > As mentioned, a better way is to define the preferred mapping table. > > Take a look at alc274_fixup_bind_dacs() as an example > > Did you had a chance to look at the log I uploaded to get an idea if it is possible to improve this auto parser to figure out the connection? Did you take a look at the function? It's pretty straightforward, you can specify the mapping you'd need there. Takashi > > René > > > Takashi > > > >> > >> René > >> > >> On 06 Mar 2018, at 16:07, René Rebe <rene@xxxxxxxxxxxx> wrote: > >> > >>> Hi Takashi, > >>> > >>> On 03/05/2018 12:55 PM, 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. > >>> > >>> To avoid sending the huge output to the list, I pressed the upload button, and it gave me this Url: > >>> > >>> > >>> http://www.alsa-project.org/db/?f=c68cad9c06aa999f017f1e43b52448d778d2903f > >>> > >>> This is with the linked patch, if you want to see it without the change, I need to re-build my kernel again :-/ > >>> > >>>> 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). > >>> > >>> Let me know if I should try some alternative solution, ... > >>> > >>> René > >>> > >>> -- > >>> René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin > >>> https://exactcode.com | https://t2sde.org | https://rene.rebe.de > >> > >> -- > >> ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin > >> DE Legal: Amtsgericht Berlin (Charlottenburg) HRB 105123B, Tax-ID#: DE251602478 > >> Managing Director: René Rebe > >> http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de > >> > > -- > ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin > DE Legal: Amtsgericht Berlin (Charlottenburg) HRB 105123B, Tax-ID#: DE251602478 > Managing Director: René Rebe > http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
