Re: [RFC] hda/realtek filtered headphone output

Re: [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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [RFC] hda/realtek filtered headphone output

[Takashi Iwai]

[ 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@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.


Takashi

> 
> 	René
> 
> > Takashi
> > 
> >> 
> >> 	René
> >> 
> >> On 06 Mar 2018, at 16:07, René Rebe <rene@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
> >> 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@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [RFC] hda/realtek filtered headphone output

[René Rebe]

On 23 Aug 2018, at 16:18, Takashi Iwai <tiwai@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@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@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

Re: [RFC] hda/realtek filtered headphone output

[Takashi Iwai]

On Thu, 23 Aug 2018 16:26:20 +0200,
René Rebe wrote:
> 
> 
> On 23 Aug 2018, at 16:18, Takashi Iwai <tiwai@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@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.

It's clearly a hardware-specific requirement, and it is the very
purpose of quirk entries.  Nothing to do with the standard parser.

Thinkpads do have already own quirk entries, so if any, it can be
applied there -- only if we know that it's absolutely safe to apply
generically to all Thinkpad models.


Takashi

> 
> 	René
> 
> > Takashi
> > 
> >> 
> >> 	René
> >> 
> >>> Takashi
> >>> 
> >>>> 
> >>>> 	René
> >>>> 
> >>>> On 06 Mar 2018, at 16:07, René Rebe <rene@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
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[RFC] hda/realtek filtered headphone output

[René Rebe]

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!

Greetings from Berlin,
	René Rebe

-- 
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