Re: [alsa-devel] [RFC] hda/realtek filtered headphone output
[ 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
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
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
participants (2)
-
René Rebe -
Takashi Iwai