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

Thu Aug 23 16:26:20 CEST 2018

On 23 Aug 2018, at 16:18, Takashi Iwai <tiwai at suse.de> wrote:

> [ 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 at suse.de> 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.

Yes, I understand. But given all 5 or so laptops I had with this codec needed this override, I suspect many more of those will be affected (I currently only have 3 of those). I may find out if I get a new ThinkPad later this year (if they still use that codec).

Thus it may be favourable to fix the auto parser as I think you mentioned earlier. If possible, this may avoid adding more override quirks, of which we may need many.

	René

> Takashi
> 
>> 
>> 	René
>> 
>>> Takashi
>>> 
>>>> 
>>>> 	René
>>>> 
>>>> On 06 Mar 2018, at 16:07, René Rebe <rene at exactcode.de> 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
>>>> 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
>> 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
 http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de