Arch Linux

gannon

Member

Registered: 2019-06-29

Posts: 29

Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

I'm dual-booting the 4.19.93-1-lts arch kernel on a 2019 Samsung Notebook 9 Pro (np930mbe-k04us).
There is no sound from the internal speakers nor the 3.5mm headphone jack, an issue that was also encountered by Ubuntu users.
I tried

• switching from linux-lts to linux and rebooting

pacman -S linux
pacman -Rs linux-lts
grub-mkconfig -o /boot/grub/grub.cfg
reboot

• Starting pulseaudio with systemctl

systemctl --user enable pulseaudio.service
reboot

• Setting the model= option of the snd-hda-intel module to laptop-dmic

echo 'options snd-hda-intel model=laptop-dmic' >> /etc/modprobe.d/modprobe.conf
reboot

Is it time to read the module code, edit, recompile, and reload the module? If so, how do I start?
I've never written or modified an LKM, nor a device driver, and I don't know where to find info about my hardware (np930mbe) in order to understand the problem.

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 23,181

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

Why are you doing that? You have new hardware so use the new kernel. the LTS kernel is a year old from a HW support stand point, no one is going to bother if you actually have the HW working on the new kernel. Don't set the model option, it isn't what you want 90% of the time.

Either way there's no reason to remove the stable kernel to use the LTS kernel, you often want to have both (unless you sized the boot partition too small)

Last edited by V1del (2020-01-20 08:51:05)

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

Hey V1del! Thanks for the reply. I tried using the new kernel and it didn't fix the problem, which is why I made this post. In fact, not only did it not fix my audio problem, but it caused screen tearing which is why I switched back to the LTS kernel.

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

The linux.org forum also has a thread describing my issue that reads similarly to the Ubuntu bug tracker thread that I listed in my original post.

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 23,181

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

Can you post without adjusted model option:

aplay -lL
amixer -c0
dmesg | grep snd

Last edited by V1del (2020-01-20 10:08:06)

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

Edit: By the way, I checked just to be safe and the output is the same regardless of which kernel I use (LTS kernel 4.19.93-1-lts or latest stable kernel 5.4.8-arch1-1).

Sure thing! Here you go:

• aplay -iL

null
    Discard all samples (playback) or generate zero samples (capture)
default:CARD=PCH
    HDA Intel PCH, ALC298 Analog
    Default Audio Device
sysdefault:CARD=PCH
    HDA Intel PCH, ALC298 Analog
    Default Audio Device
front:CARD=PCH,DEV=0
    HDA Intel PCH, ALC298 Analog
    Front speakers
surround21:CARD=PCH,DEV=0
    HDA Intel PCH, ALC298 Analog
    2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=PCH,DEV=0
    HDA Intel PCH, ALC298 Analog
    4.0 Surround output to Front and Rear speakers
surround41:CARD=PCH,DEV=0
    HDA Intel PCH, ALC298 Analog
    4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=PCH,DEV=0
    HDA Intel PCH, ALC298 Analog
    5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=PCH,DEV=0
    HDA Intel PCH, ALC298 Analog
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=PCH,DEV=0
    HDA Intel PCH, ALC298 Analog
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
hdmi:CARD=PCH,DEV=0
    HDA Intel PCH, HDMI 0
    HDMI Audio Output
hdmi:CARD=PCH,DEV=1
    HDA Intel PCH, HDMI 1
    HDMI Audio Output
hdmi:CARD=PCH,DEV=2
    HDA Intel PCH, HDMI 2
    HDMI Audio Output
hdmi:CARD=PCH,DEV=3
    HDA Intel PCH, HDMI 3
    HDMI Audio Output
hdmi:CARD=PCH,DEV=4
    HDA Intel PCH, HDMI 4
    HDMI Audio Output
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC298 Analog [ALC298 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 10: HDMI 4 [HDMI 4]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

• amixer -c0

Simple mixer control 'Master',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined
  Playback channels: Mono
  Limits: Playback 0 - 127
  Mono: Playback 11 [9%] [-58.00dB] [off]
Simple mixer control 'Headphone',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 127
  Mono:
  Front Left: Playback 0 [0%] [-63.50dB] [off]
  Front Right: Playback 0 [0%] [-63.50dB] [off]
Simple mixer control 'Speaker',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 127
  Mono:
  Front Left: Playback 127 [100%] [0.00dB] [off]
  Front Right: Playback 127 [100%] [0.00dB] [off]
Simple mixer control 'PCM',0
  Capabilities: pvolume
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 255 [100%] [0.00dB]
  Front Right: Playback 255 [100%] [0.00dB]
Simple mixer control 'Mic',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 0 [0%] [-34.50dB] [off]
  Front Right: Playback 0 [0%] [-34.50dB] [off]
Simple mixer control 'Mic Boost',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 3
  Front Left: 0 [0%] [0.00dB]
  Front Right: 0 [0%] [0.00dB]
Simple mixer control 'IEC958',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'IEC958',1
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'IEC958',2
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'IEC958',3
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'IEC958',4
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 127
  Front Left: Capture 91 [72%] [12.00dB] [on]
  Front Right: Capture 91 [72%] [12.00dB] [on]
Simple mixer control 'Auto-Mute Mode',0
  Capabilities: enum
  Items: 'Disabled' 'Enabled'
  Item0: 'Enabled'
Simple mixer control 'Internal Mic Boost',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 3
  Front Left: 0 [0%] [0.00dB]
  Front Right: 0 [0%] [0.00dB]
Simple mixer control 'Loopback Mixing',0
  Capabilities: enum
  Items: 'Disabled' 'Enabled'
  Item0: 'Disabled'

• dmesg | grep snd

[    5.182384] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[    5.998603] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[    6.123801] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC298: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
[    6.123802] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    6.123803] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[    6.123803] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
[    6.123804] snd_hda_codec_realtek hdaudioC0D0:    inputs:
[    6.123805] snd_hda_codec_realtek hdaudioC0D0:      Mic=0x18
[    6.123805] snd_hda_codec_realtek hdaudioC0D0:      Internal Mic=0x12

Last edited by gannon (2020-01-20 23:53:10)

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 23,181

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

Well most of your stuff is muted...

amixer -c0 set 'Master',0 100% unmute
amixer -c0 set 'Speaker',0 100% unmute
amixer -c0 set 'Headphone',0 100% unmute

that's ALSA default you are supposed to change/set: https://wiki.archlinux.org/index.php/Ad … e_channels

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

Unmuted but it didn't help. Thanks for pointing that out, though! I really appreciate your help, V1del. Any more suggestions?

On a side note, I cloned the linux kernel and started digging around after opening up the Linux Device Drivers 3e pdf. I was able to build and run the "hello world" kernel module as well as the scull character device. No idea how to debug a driver but I guess this is the way to learn!

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 23,181

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

How are you determining that, what do you try to use for playback? Try

speaker-test -c2 -Dhw:0

FWIW the driver is technically there so this might just be some borked pin layout so one other suggestion I still have is to check with hdajackretask if you can redefine a pin to something that actually gives you output. In a similar vein, check if you got a BIOS/UEFI firmware update, they often contain fixes to audio layouts/tables

Last edited by V1del (2020-01-22 08:41:12)

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

No sound with speaker-test.

Samsung Update, a Windows 10 application that came pre-installed on my machine, showed no BIOS/UEFI firmware updates, however there were driver updates available (including a sound driver update). I installed them but still no sound. Not surprising that updating Windows drivers does not affect sound on Arch, but it was worth a shot!

I installed alsa-tools and ran hdajackretask and the Realtek ALC298 codec appears in the dropdown, but I'm not sure which pins to override to what. Tips?

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 23,181

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

I don't know your pin layout, maybe throw in alsa-info.sh output and/or a screenshot of your hdajackretask it should dump something interesting for me to look at. FWIW you can't really break something here and you are free to experiment a bit.

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

alsa-info.sh output and hdajackretask screenshot

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

I got sound in the headphones with model=mono-speakers! Why?

Here is alsa_info.sh output with no options (bad) and with model=mono-speakers (good).

I'm trying to learn with these strategies

1. Read the datasheet. I can't find the ALC298 but I did take a look at ALC269.

2. Read the spec. The Intel HD Audio spec .

3. Run hdajackretask. There did not appear to be any changes in the jack assignments due to model=mono-speakers.

4. Read alsa_info.sh output before/after model=mono-speakers.

5. Look at the Linux kernel code, specifically sound/pci/hda/patch_realtek.c. For example, line 7607 shows where mono-speakers comes from,

7607   {.id = ALC290_FIXUP_MONO_SPEAKERS_HSJACK, .name = "mono-speakers"},

6. Researching problems with ALC298 encountered by other Linux users. For example, the idea to set model=mono-speakers came from Ubuntu bug 181518:

Made a little progress: headphones work with
/etc/modprobe.d/alsa-base.conf:
options snd-hda-intel model=mono-speakers

Volume is loud and clear, in stereo!

7. Patching, building, and running a custom kernel. I used the Arch Build System strategy to compile. The patch that I tried changed 1 line in patch_realtek.c. It did not help but I'm happy to try again.

8. Reading kernel patches.

 git log -p sound/pci/hda/patch_realtek.c 

9. Reading Linux Sound Subsystem Documentation, including Writing an ALSA Driver, More Notes on HD-Audio Driver, and other portions written by the great Takashi Iwai. I also looked through HD-Auddio Codec-Specific Models. My dream is to add a new model alc298-samsung-audio with the QUIRK() call fixing my problem.

I'm here to learn so please be as verbose as you can.

Last edited by gannon (2020-04-13 03:58:50)

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

In Ubuntu bug 181518, Hui Wang (hui.wang) asks for the output of RtHDDump.exe which he attaches in a comment. It looks like a logger from Realtek - think alsa-info.sh but proprietary and for Windows.

I booted into Windows and ran it. Here's the output.

I also re-ran with my headhpones plugged into the jack and saw different output.

Notably, the status of the following two widgets changed from Jack is unplugged to Jack is plugged:

...<snip>...

********** Wid=[0x18] **********
<VREF 80%> <Input Enabled><Output Disable><H-Phn Disable><Jack is plugged>
Amplifier Gain :
    Input Amplifier Gain :
        <Gain Number of step=3, 0dB Offset=0, Step Size=10.00 dB, From 0.00dB to 30.00dB>
        => Gain L:0.00dB(0x00) R:0.00dB(0x00)
Power State : [PS-Act : D0], [PS-Set : D0]

...<snip>...

********** Wid=[0x21] **********
<VREF Hi-Z> <Input Disable><Output Enabled><H-Phn Enabled><Jack is plugged>
Output MUX select to index 0x01 <WID=0x0D>
Amplifier Gain :
    Output Amplifier Gain :
        <Gain Number of step=0, 0dB Offset=0, Step Size=0.00 dB,From 0.00dB to 0.00dB>
        => Index 00 <WID=0x0C> Mute L:1 R:1 , Gain L:0.00dB(0x00) R:0.00dB(0x00)
Power State : [PS-Act : D0], [PS-Set : D0]

This corresponds to hdajackretask where I see Pin ID 0x18 and Pin ID 0x21 corresponding to the microphone input and headphone output. Both register as "Jack is plugged" when I plug into the 3.5mm jack. My headphones have a microphone on the cable. I wonder if that matters.

Anyways, still no clue what to do about the internal speakers or the internal mic, which appear as Pin ID 0x17 and Pin ID 0x12, respectively, in hdajackretask. I'll keep digging.

Last edited by gannon (2020-04-13 08:20:24)

roinincoder

Member

Registered: 2019-10-15

Posts: 12

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

I posted a potential solution to the ubuntu link you've mentioned above. Really curious to see if it solves your headphones issue as that'd verify at least one codec pin configuration. Please try it and let me know.

Last edited by roinincoder (2020-04-13 22:18:54)

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

Early patching was no good.

Did I typo?

-rw-r--r-- 1 root root 70 Apr 13 23:38 /lib/firmware/alc298-sound-patch.fw

[codec]
0x10ec0298 0x144dc169 0

[model]
auto

[verb]
0x1a 0x707 0xc5

-rw-r--r-- 1 root root 116 Apr 13 23:40 /etc/modprobe.d/alc298-sound-patch.conf

options snd-hda-intel patch=alc298-sound-patch.fw,alc298-sound-patch.fw,alc298-sound-patch.fw,alc298-sound-patch.fw

I also tried patch=alc298-sound-patch.fw (without repeating the right hand side 3 more times) becuase on my machine ls /proc/asound only shows one card, card0.

What machine are you using?

What are the semantics of the verbs?

What 0x144dc169 for the subsystem id? (I see the vendor id (0x10ec0298) corresponds to ALC298.)

Why 0 for the address of the codec?

Last edited by gannon (2020-04-14 07:08:12)

roinincoder

Member

Registered: 2019-10-15

Posts: 12

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

Interesting, i was under the impression that the pin and verb reassignments are same across all the machine that use a specific sound card model. So verify if the patch was applied after reboot by typing `sudo dmesg | grep -i snd` and one of the output lines must be `... snd_hda_intel... applying patch alc298-sound-patch.fw...` and of course no errors. If you see errors, then must investigate the cause of the error first. In my case there were no errors, nothing muted and all GUIs showed the sound bars moving when playing music. Although no sound was coming out of speakers and headphones were super weak. As far as the questions you asked:

What machine are you using? Samsung Notebook 9 Pen

What are the semantics of the verbs? So the 0x707 is SET_PIN_WIDGET_CONTROL in `hda-verb -L or -l` (aka `set_pin_ctl` in hda-emu utility), there's also 0xf07 which is GET_PIN_WIDGET_CONTROL in `hda-verb -L or -l` (aka `get_pin_ctl` in hda-emu utility). The first value under the `[verb]` is the nid (0x1a) aka pin widget and in my case it was set the the wrong VREF value (HIZ). I read somewhere that this happens because the pin assignments are messed up by the UEFI/BIOS causing an unintended shift to the VREF value. Nevertheless changing the VREF of 0x1a pin to 50, 80 or 100 fixed the headphones so I eventually wrote the early patch for it.

What 0x144dc169 for the subsystem id? (I see the vendor id (0x10ec0298) corresponds to ALC298.) This is the same subsystem id that `hda-analyzer` shows, I did not change that but now that i think of it, i should try the subsystem id from your windows pastebin output. Surprisingly it's actually a larger value 144DC176 (note 176 instead of my default 169). I will try this and report back here.

Why 0 for the address of the codec? This is the sound card codec index. I have a single on-board sound card so there it is. You'll need to find your sound card index, maybe it's set to 1 instead of 0. For me 1 is the HDMI codec, but for you it could be the other way around.

Here's another way of trying the patch and see if 0x1a change can fix your headphones. Run the `hda-analyzer` utility, it requires python2 and pygtk modules. You can get it from github at https://github.com/jeremycline/hda-analyzer. Once you get it running, then check out which codec index is for your ALC298 (either CODEC-0 or CODEC-1) and under that you'd see the 0x1a PIN_WIDGET. Click it and check the assigned VREF value. If it is set to HIZ, then set it to 100 and without closing the `hda-analyzer` play a song to see if headphones are playing it. Plug the headphones before running the program though because jack detection could hinder this experiment. No reboot required here.

** Edit **

The subsystem id had no effects. I think it should be set to what is shown as current subsystem id in `hda-analyzer`.

Also silly me, the 0x1a probably won't work for everyone. This is because it depends how the UEFI/BIOS has messed up the pin assignments. So it could be another PIN_WIDGET that has a shifted VREF value. Should be able to try all of them in `hda-analyzer` though we really need to know the correct pin assignments instead at some point.

Last edited by roinincoder (2020-04-14 09:37:31)

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

So verify if the patch was applied after reboot by typing `sudo dmesg | grep -i snd` and one of the output lines must be `... snd_hda_intel... applying patch alc298-sound-patch.fw...` and of course no errors.

Oh good idea. Yep, I see it. No error messages though.

Edit: I changed the Subsystem Id to 0x144dc176 and it worked!!! Loud and clear in the headphones.

Here's another way of trying the patch and see if 0x1a change can fix your headphones. Run the `hda-analyzer` utility, it requires python2 and pygtk modules. You can get it from github at https://github.com/jeremycline/hda-analyzer. Once you get it running, then check out which codec index is for your ALC298 (either CODEC-0 or CODEC-1) and under that you'd see the 0x1a PIN_WIDGET. Click it and check the assigned VREF value. If it is set to HIZ, then set it to 100 and without closing the `hda-analyzer` play a song to see if headphones are playing it. Plug the headphones before running the program though because jack detection could hinder this experiment. No reboot required here.

It worked!!! Loud and clear in the headphones =)

Edit: After some testing I can confirm that this solution behaves like you described in your forum post. Namely, it's not sticky. Reboots, switching applications, and even activities within one application (e.g. pausing/un-pausing a youtube video in firefox) can revert the effect. I can see why you decided to go with Early Patching.

Also silly me, the 0x1a probably won't work for everyone. This is because it depends how the UEFI/BIOS has messed up the pin assignments. So it could be another PIN_WIDGET that has a shifted VREF value. Should be able to try all of them in `hda-analyzer` though we really need to know the correct pin assignments instead at some point.

Have you tried emailing Kailang Yang? Kailing contributed ALC298 support to patch_realtek.c [1]. Kailang seems like a good person to guide our hda-analyzer experimentation.

Can you post a link with your output from alsa-info.sh? Also RtHDDump.exe?

Edit: I just found your forum post, ALSA sound not working, where you already posted alsa-info.sh output. Can you run RtHDDump.exe?

[1] ALC298 support commit by Kailang Yang

$ git log -p 506b62c33a74
commit 506b62c33a7444b91a93bf2da772f4c7e6656410
Author: Kailang Yang <kailang@realtek.com>
Date:   Thu Dec 18 17:07:44 2014 +0800

    ALSA: hda/realtek - New codec support for ALC298
    
    Add new support for ALC298 codec.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 24db152f0ab1..65f1f4e18ea5 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -326,6 +326,7 @@ static void alc_fill_eapd_coef(struct hda_codec *codec)
        case 0x10ec0283:
        case 0x10ec0286:
        case 0x10ec0288:
+       case 0x10ec0298:
                alc_update_coef_idx(codec, 0x10, 1<<9, 0);
                break;
        case 0x10ec0285:
@@ -2660,6 +2661,7 @@ enum {
        ALC269_TYPE_ALC284,
        ALC269_TYPE_ALC285,
        ALC269_TYPE_ALC286,
+       ALC269_TYPE_ALC298,
        ALC269_TYPE_ALC255,
        ALC269_TYPE_ALC256,
 };
@@ -2688,6 +2690,7 @@ static int alc269_parse_auto_config(struct hda_codec *codec)
        case ALC269_TYPE_ALC282:
        case ALC269_TYPE_ALC283:
        case ALC269_TYPE_ALC286:
+       case ALC269_TYPE_ALC298:
        case ALC269_TYPE_ALC255:
        case ALC269_TYPE_ALC256:
                ssids = alc269_ssids;
@@ -5421,6 +5424,9 @@ static int patch_alc269(struct hda_codec *codec)
                spec->codec_variant = ALC269_TYPE_ALC286;
                spec->shutup = alc286_shutup;
                break;
+       case 0x10ec0298:
+               spec->codec_variant = ALC269_TYPE_ALC298;
+               break;
        case 0x10ec0255:
                spec->codec_variant = ALC269_TYPE_ALC255;
                break;
@@ -6368,6 +6374,7 @@ static const struct hda_codec_preset snd_hda_preset_realtek[] = {
        { .id = 0x10ec0290, .name = "ALC290", .patch = patch_alc269 },
        { .id = 0x10ec0292, .name = "ALC292", .patch = patch_alc269 },
        { .id = 0x10ec0293, .name = "ALC293", .patch = patch_alc269 },
+       { .id = 0x10ec0298, .name = "ALC298", .patch = patch_alc269 },
        { .id = 0x10ec0861, .rev = 0x100340, .name = "ALC660",
          .patch = patch_alc861 },
        { .id = 0x10ec0660, .name = "ALC660-VD", .patch = patch_alc861vd },

Last edited by gannon (2020-04-16 05:38:50)

roinincoder

Member

Registered: 2019-10-15

Posts: 12

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

Just contacted Kailang in a short email describing the effect. I think this is a new ALC298 variant and it does require a c patch since the early patching is limited. I could not connect any PIN_WIDGETS as "Internal" speaker or headphone, but setting any of them to "Jack" works fine. This simply means no internal speakers/mics can be configured and hence rendering "Early Patching" as not effective for retasking internal PIN_WIDGETS

Now like i mentioned in the launchpad Ubuntu link you've posted before, I am not a system developer and I know more about oranges than i do c lang so my skills are limited here.

As far as running the Realtek utility, it requires windows which I do not have. Perhaps I can run windows in QEMU and use a PCI passthrough for sound-card just to run it. Will report back here on that.

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

I know nothing about kernel hacking, but I know some C, and I was able to modify the kernel and recompile using the Arch Build System and run it on my laptop without any problems.

As far as running the Realtek utility, it requires windows which I do not have. Perhaps I can run windows in QEMU and use a PCI passthrough for sound-card just to run it. Will report back here on that.

For inspiration here's a launchpad thread, "No sound from right audio channel", where logging all of the PCI IO activity from Windows inside of qemu was the key to fixing the Huawei Matebook X.

Here's a similar thread, HP Spectre x360 (Kabylake) just front speakers work, that includes comments from the great Takashi Iwai. Takashi is the sound commit leader:

$ git shortlog -s -n sound | head
  6935	Takashi Iwai
  4368	Mark Brown
  2283	Kuninori Morimoto
  1161	Lars-Peter Clausen
   794	Takashi Sakamoto
   662	Peter Ujfalusi
   660	Clemens Ladisch
   641	Linus Torvalds
   602	Axel Lin
   381	Pierre-Louis Bossart

I think Takashi is also the code owner of snd_hda_intel and the author of much of the Linux Sound Subsystem Documentation.

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

I made a kernel patch that implements the quirk that you discovered, roinincoder.

It works for me, does it work for you?

I used the Kernel/Arch Build System and Patching Packages wikipages to patch and build the kernel. It takes ~45 minutes to compile using all 8 hardware threads on my AMD Ryzen 5 2400G [1]. By default makepkg uses 1 thread, so you need to set MAKEFLAGS to use more:

vim /etc/makepkg.conf # set MAKEFLAGS="-j8"

Here's the patch

From ce2a52c84cd2690db286993ebef6bf25b619293b Mon Sep 17 00:00:00 2001
From: Mike Pozulp <pozulp.llvm@gmail.com>
Date: Thu, 16 Apr 2020 20:49:12 -0700
Subject: [PATCH] ALSA: hda/realtek: Add quirk for Samsung Notebook

Some models of the Samsung Notebook 9 have very quiet and distorted
headphone output. This quirk changes the VREF value of the ALC298
codec NID 0x1a from default HIZ to new 100.
---
 sound/pci/hda/patch_realtek.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 63e1a56f705b..9b14ed5c75d7 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5923,6 +5923,7 @@ enum {
 	ALC294_FIXUP_ASUS_DUAL_SPK,
 	ALC285_FIXUP_THINKPAD_HEADSET_JACK,
 	ALC294_FIXUP_ASUS_HPE,
+	ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -7061,6 +7062,13 @@ static const struct hda_fixup alc269_fixups[] = {
 		.chained = true,
 		.chain_id = ALC294_FIXUP_ASUS_HEADSET_MIC
 	},
+	[ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET] = {
+		.type = HDA_FIXUP_VERBS,
+		.v.verbs = (const struct hda_verb[]) {
+			{ 0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, 0xc5 },
+			{ }
+		},
+	},
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7336,6 +7344,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
 	SND_PCI_QUIRK(0x1d72, 0x1901, "RedmiBook 14", ALC256_FIXUP_ASUS_HEADSET_MIC),
 	SND_PCI_QUIRK(0x10ec, 0x118c, "Medion EE4254 MD62100", ALC256_FIXUP_MEDION_HEADSET_NO_PRESENCE),
+	SND_PCI_QUIRK(0x144d, 0xc169, "Samsung Notebook 9 Pen (NP930SBE-K01US)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
+	SND_PCI_QUIRK(0x144d, 0xc176, "Samsung Notebook 9 Pro (NP930MBE-K04US)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
 
 #if 0
 	/* Below is a quirk table taken from the old code.
-- 
2.24.1

When we solve the speaker problem we can add the solution to the patch.

[1] Incremental builds are, of course, much faster. If I adjust the patch and recompile it takes just a minute or two. If I set CONFIG_SND_DEBUG_VERBOSE=y and recompile it takes ~5 minutes. The linux sound subsystem documentation says this option produces more output but I couldn't see it. I wasn't sure where to look (I tried dmesg) or how to induce the output (what is probing?).

roinincoder

Member

Registered: 2019-10-15

Posts: 12

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

Nice work, but my own "Early Patching" solution seem to work just fine considering I really don't have a machine for the  task. The only issue with early patching was that firefox/chromium based web browsers (gnome web worked fine) stopped responding to keyboard inputs, which I also solved by adding `GTK_IM_MODULE=xim` to /etc/security/pam_env.conf file. So now headphones work and browsers work so I can look forward to actually seeing I2S implemented. Not sure why kernel guys are quiet about this, perhaps some of us can contribute seeing the I2S specification is publicly available.

If some poor soul comes looking and cannot carry gannon's solution above, then see if you can try this. Here's my early patch procedure as a reference:

1. Step 1: Save it to /lib/firmware/alc298-sound-patch.fw. Note that you have to use your own combo of <vendor id> <subsystem id> <codec index> for the `codec` line to work. I only place mine here, but you may need to adjust `[codec]` line values specially if you have multiple sound cards. Typically the hardware sound card is at CODEC-0 and HDMI is at CODEC-1. For gannon the <subsystem id> ends in 172 instead of 169 like mine does. To find these you can use `hda-analyzer` as I mentioned in post #17 here on this topic.

   [codec]
   0x10ec0298 0x144dc169 0
   
   [verb]
   0x1a 0x707 0xc5

2. Step 2: You'd need to tell ALSA about the early patch. Save it to /etc/modprobe.d/alc298-sound-patch.conf

   options snd-hda-intel patch=alc298-sound-patch.fw

   Restart and headphones should work now.

PS: if you experience issues with typing in firefox/chromium then add the variable mentioned at the beginning of this post and restart.

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

How did you figure this out? That is, what made you think that changing the VREF value from HIZ to 100 on NID 0x1a would fix headphone audio? Could your strategy help to fix the speakers?

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

I found another "Early Patching" solution:

[pincfg]
0x1a 0x01a1913c

This causes the VREF value on NID 0x1a to be set to 80, but I'm not sure why. I used 0x01a1913c because it is the same 4 bytes used by the model=mono-speakers option from the Ubuntu bug. You can verify the effect with

$ cat /sys/class/sound/hwC0D0/driver_pin_configs
0x1a 0x01a1913c

Compare that to the default configuration from the BIOS

$ cat /sys/class/sound/hwC0D0/init_pin_configs
0x12 0x90a60130
0x13 0x40000000
0x14 0x411111f0
0x17 0x90170110
0x18 0x04a11020
0x19 0x411111f0
0x1a 0x411111f0 <---- very different from 0x01a1913c
0x1d 0x40630245
0x1e 0x411111f0
0x1f 0x411111f0
0x21 0x04211050

Are the silent speakers just another configuration default issue? The repeated 0x411111f0 values look very suspicious. See Section 7.3.3.31 Configuration Default of the hda spec for the semantics of these bit patterns.

Edit: FYI, I see the same values in Windows (from RtHDDump.exe):

Wid=12  Codec=90A60130  Drv=90A60130  Loc=00000000
Wid=13  Codec=40000000  Drv=40000000  Loc=00000000
Wid=14  Codec=411111F0  Drv=411111F0  Loc=00000000
Wid=17  Codec=90170110  Drv=90170110  Loc=00000000
Wid=18  Codec=04A11020  Drv=04A11020  Loc=00020200
Wid=19  Codec=411111F0  Drv=411111F0  Loc=00000000
Wid=1A  Codec=411111F0  Drv=411111F0  Loc=00020400
Wid=1D  Codec=40630245  Drv=40630245  Loc=00000000
Wid=1E  Codec=411111F0  Drv=411111F0  Loc=00000700
Wid=1F  Codec=411111F0  Drv=411111F0  Loc=00000800
Wid=21  Codec=04211050  Drv=04211050  Loc=00020200

Edit #2: cat driver_pin_configs should be cat user_pin_configs, because this is an Early Patch. If the config is performed in patch_realtek.c then it would appear in driver_pin_configs (as it does when using the model= option).

Last edited by gannon (2020-04-21 07:37:44)

gannon

Member

Registered: 2019-06-29

Posts: 29

Re: Debugging Samsung Notebook 9 Pro (HDA Intel / Realtek ALC298) driver

roinincoder and I reported a kernel bug, https://bugzilla.kernel.org/show_bug.cgi?id=207423