[950SBE/951SBE, Realtek ALC298, Speaker, Internal] No sound on internal speakers, very very quiet on headphones

[Martin S]

I've been googling this issue for 10's of hours and tried many things.

Relase of Ubuntu: 19.10

Expected outcome: Music plays on the internal speakers and headphones.

Actual outcome: I can barely hear audio using headphones with volume turned up to 150%. Absolutely nothing comes out of the speakers. (The speakers sound great under Windows 10.)

Complete alsa-info output is attached, but here are some snippets:

!!DMI Information
!!---------------

Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
Product Name: 950SBE/951SBE
Product Version: P06RES
Firmware Version: P06RES.075.190529.SP
Board Vendor: SAMSUNG ELECTRONICS CO., LTD.
Board Name: NP950SBE-K01US

!!Kernel Information
!!------------------

Kernel release: 5.3.0-19-generic
Operating System: GNU/Linux
Architecture: x86_64
Processor: x86_64
SMP Enabled: Yes

!!ALSA Version
!!------------

Driver version: k5.3.0-19-generic
Library version: 1.1.9
Utilities version: 1.1.9

!!Loaded ALSA modules
!!-------------------

snd_hda_intel

!!Sound Servers on this system
!!----------------------------

Pulseaudio:
      Installed - Yes (/usr/bin/pulseaudio)
      Running - Yes

!!Soundcards recognised by ALSA
!!-----------------------------

 0 [PCH ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0x604b118000 irq 177

!!PCI Soundcards installed in the system
!!--------------------------------------

00:1f.3 Multimedia audio controller: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 11)

!!Advanced information - PCI Vendor/Device/Subsystem ID's
!!-------------------------------------------------------

00:1f.3 0401: 8086:9dc8 (rev 11)
        DeviceName: Onboard - Sound

!!HDA-Intel Codec information
!!---------------------------
--startcollapse--

Codec: Realtek ALC298
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0298
Subsystem Id: 0x144dc812
Revision Id: 0x100103
No Modem Function Group found
Default PCM:
    rates [0x60]: 44100 48000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
State of AFG node 0x01:
  Power states: D0 D1 D2 D3 D3cold CLKSTOP EPSS
  Power: setting=D0, actual=D0
GPIO: io=8, o=0, i=0, unsolicited=1, wake=0
  IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[4]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[5]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[6]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
  IO[7]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out
  Control: name="Headphone Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Device: name="ALC298 Analog", type="Audio", device=0
  Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=0
  Amp-Out vals: [0x00 0x00]
  Converter: stream=1, channel=0
  PCM:
    rates [0x60]: 44100 48000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
  Power states: D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out
  Control: name="Speaker Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=0
  Amp-Out vals: [0x7f 0x7f]
  Converter: stream=1, channel=0

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: alsa-base 1.0.25+dfsg-0ubuntu5
ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
Uname: Linux 5.3.0-19-generic x86_64
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: martin 1383 F.... pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Wed Nov 6 06:20:08 2019
InstallationDate: Installed on 2019-11-03 (3 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
PackageArchitecture: all
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: alsa-driver
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed
Symptom_Card: Built-in Audio - HDA Intel PCH
Symptom_DevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: martin 1383 F.... pulseaudio
Symptom_Jack: Speaker, Internal
Symptom_Type: No sound at all
Title: [950SBE/951SBE, Realtek ALC298, Speaker, Internal] No sound at all
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/29/2019
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P06RES.075.190529.SP
dmi.board.asset.tag: No Asset Tag
dmi.board.name: NP950SBE-K01US
dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.board.version: SGL9849A0Q-C01-G003-S0001+10.0.17763
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 31
dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP06RES.075.190529.SP:bd05/29/2019:svnSAMSUNGELECTRONICSCO.,LTD.:pn950SBE/951SBE:pvrP06RES:rvnSAMSUNGELECTRONICSCO.,LTD.:rnNP950SBE-K01US:rvrSGL9849A0Q-C01-G003-S0001+10.0.17763:cvnSAMSUNGELECTRONICSCO.,LTD.:ct31:cvrN/A:
dmi.product.family: Notebook 9 Series
dmi.product.name: 950SBE/951SBE
dmi.product.sku: SCAI-A5A5-A5A5-A5A5-PRES
dmi.product.version: P06RES
dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD.
mtime.conffile..etc.modprobe.d.alsa-base.conf: 2019-11-05T23:13:55.854413

[Filipe Garrett (wowbaggerbr)]

I have a very similar issue with another Samsung laptop: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1850702

[Hui Wang (hui.wang)]

Please collect an alsa-info.txt with coeff dumped:

sudo su
echo 1 > /sys/module/snd_hda_codec/parameters/dump_coef
then run alsa-info and upload the log.

thx.

[Martin S (martins4321)]

In the last few days, I've tried a few more things (incl. re-installing alsa, pulseaudio multiple times), but still have the same issue: headphones are extremely quiet, and nothing coming out of the internal speakers. The alsa-info with coefficients is attached.

Thanks for looking.

[Hui Wang (hui.wang)]

I will find a machine wit alc298 next week, and compare the coeff with your machine.

thx.

[Martin S (martins4321)]

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!

alsa-info.sh output is attached with coefficients. Headphones were not plugged in at that time to keep the diffs to a minimum.

[Hui Wang (hui.wang)]

Please test:
options snd-hda-intel model=headset-mode-no-hp-mic

[Martin S (martins4321)]

Using options snd-hda-intel model=headset-mode-no-hp-mic

Result:
Headphones: very very quiet
Internal speakers: Nothing

Alsa-info is attached.

Thank you.

[Hui Wang (hui.wang)]

Please remove the model=xxxx or keep model=headset-mode-no-hp-mic

When headphone is very very quiet, please run:
sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x8e
sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x20
//check if headphone can output sound normally?

sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x19
sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x317
//check if headphone can output sound normally?

sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x1110
//check if headphone can output sound normally?

sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x4f
sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0xc429
//check if headphone can output sound normally?

[Martin S (martins4321)]

Hi,
I was surprised, but none of these settings helped. Mode was set originally to
options snd-hda-intel model=headset-mode-no-hp-mic

sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x8e
sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x20
//check if headphone can output sound normally?

Running speaker-test:
very very quiet

sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x19
sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x317
//check if headphone can output sound normally?

same result

sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x1110
//check if headphone can output sound normally?

same result

sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x4f
sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0xc429
//check if headphone can output sound normally?

same result

[Martin S (martins4321)]

FYI: I just re-tested with model=mono-speakers, and there the headhpone output likewise does not change for any of the above settings: it works great the entire time.

Thanks,
Martin

[Hui Wang (hui.wang)]

Ah, please test model=dell-headset3, it should work.

And please also add options snd-hda-codec-realtek dyndbg, then boot the system without the headphone plugged.

after boot up, plug headphone, and test if it works well. If it works well, please upload the dmesg.

thx.

[Hui Wang (hui.wang)]

And for speaker's issue, please verify that both speaker and headphone work well under windows, then using this tool to collect a log under windows, the log is a useful reference for linux.

thx.

[Martin S (martins4321)]

<<<<<<<<<<<<<<<<<<<
Ah, please test model=dell-headset3, it should work.

And please also add options snd-hda-codec-realtek dyndbg, then boot the system without the headphone plugged.

after boot up, plug headphone, and test if it works well. If it works well, please upload the dmesg.
>>>>>>>>>>>>>>>>>>>>

Yes, headphones work well. dmesg output is attached.

Thank you.

[Hui Wang (hui.wang)]

If you have time, please run #13 on the windows10.

And If you have time, please redo the test of #10, after finishing all commands, please generate an alsa-info.txt-with-coeff, let us check if all those commands successfully executed.

[Martin S (martins4321)]

>>>>>>>>>>>>>>>>>>>>>
please verify that both speaker and headphone work well under windows, then using this tool to collect a log under windows, the log is a useful reference for linux.
<<<<<<<<<<<<<<<<<<<<<

Output attached; looks like this might be helpful to get the speakers to work.

Thank you,
Martin

[Martin S (martins4321)]

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
nd If you have time, please redo the test of #10, after finishing all commands, please generate an alsa-info.txt-with-coeff, let us check if all those commands successfully executed.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Option: dell-headset3
Headphone works, and does not seem to change when any of the below settings are applied. alsa-info output attached; it was generated after the last command in the sequence.

martin@martins-samsung:~$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x8e
nid = 0x20, verb = 0x500, param = 0x8e
value = 0x0
martin@martins-samsung:~$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x20
nid = 0x20, verb = 0x400, param = 0x20
value = 0x0

>>>>>>>> NO change

martin@martins-samsung:~$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x19
nid = 0x20, verb = 0x500, param = 0x19
value = 0x0
martin@martins-samsung:~$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x317
nid = 0x20, verb = 0x400, param = 0x317
value = 0x0

>>>>>>>> NO change

martin@martins-samsung:~$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
nid = 0x20, verb = 0x500, param = 0x67
value = 0x0
martin@martins-samsung:~$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x1110
nid = 0x20, verb = 0x400, param = 0x1110
value = 0x0

>>>>>>>> NO change

martin@martins-samsung:~$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x4f
nid = 0x20, verb = 0x500, param = 0x4f
value = 0x0
martin@martins-samsung:~$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0xc429
nid = 0x20, verb = 0x400, param = 0xc429
value = 0x0

>>>>>>>> NO change

Thanks,
Martin

[Martin S (martins4321)]

Attachment to #17 was incorrect (forgot to turn on coefficients)

Attached is alsa-info with coefficients.

[Hui Wang (hui.wang)]

Please remove any modle=xxxx from alsa-base.conf

Install the testing kernel and reboot, then test headphone and speaker with the testing kernel.
https://people.canonical.com/~hwang4/samsung-test/
(to install the testing kernel, sudo dpkg -i linux-modules-xxx.deb; sudo dpkg -i linux-image-xxx.deb; sudo dpkg -i linux-modules-extra-xxxx.deb)

If headphone and speaker still don't work, please run this script and retest the headphone and speaker again.

then upload the dmesg and alsa-info.txt-with-coeff

[Martin S (martins4321)]

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Install the testing kernel and reboot,
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Couldn't boot after installing all 3 .deb's:

error: /boot/vmlinuz-5.3.0.23.25+samsung-test-generic has invalid signature
error: you need to load the kernel first

Press any key to continue...

[Martin S (martins4321)]

Hi,

1) Steps:
- Removed the option model=
- Rebooted
- turned off Secure Boot and booted with your test kernel.

Result:
No sound from speakers.
Very very quiet headphones.

2) Steps:
sudo set-coeff.sh
sudo su
echo 1 > /sys/module/snd_hda_codec/parameters/dump_coef

Result:
No sound from speakers.
Very very quiet headphones.

alsa-info is attached.

Thanks,
Martin

[Martin S (martins4321)]

dmesg output attached from #21, step 2)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Klaus Ahrenberg (klausahrenberg)]

I own model NT950SBE, same issue: No sound at headphones and speaker. I tried Ubuntu and Manjaro with latest kernels - no progress. After changing Alss-config according to post #6, haedphones are working now. Thanks.

/etc/modprobe.d/alsa-base.conf:
options snd-hda-intel model=mono-speakers

I attach my Realtek dump-file made in Windows. Hope that helps a bit to get a solution for the problem.

[Terry Magnus Drever (terrymagnusdrever)]

I have exactly the same problem on a Samsung Galaxy Flex Book.

Headphones are working with the following
options snd-hda-intel model=mono-speakers

Speakers do not work.

[Terry Magnus Drever (terrymagnusdrever)]

Attached my realtek dump.

[Duke Fong (duke-c)]

Same problem with Samsung Galaxy Book Flex 930QCG.

The Samsung Galaxy Chromebook and Galaxy Book Flex look very similar, the sound chip should be the same, the Chromebook is open source and also uses the Linux kernel, can we refer to the Chromebook code?

[Mike Pozulp (gannon1)]

Exactly the same problem with Samsung Notebook 9 Pro (np930mbe-k04us) which also has an ALC298.

Headphones are working with model=mono-speakers.

I attached my Realtek dump.

I'm also soliciting the arch forum for help (I'm running arch):

https://bbs.archlinux.org/viewtopic.php?pid=1897858

[Mike Pozulp (gannon1)]

I attached the Realtek dump with my headphones plugged into the jack for comparison.

[ironincoder (ironincoder)]

I have been trying to get ALC298 working for a while now and wanted to share my findings. This issue exist on all distros and is an ALSA problem (not pulseaudio). Verified it when found a fix for the headphone by using the kernel's early patching feature. To use this feature, write a simple patch (instructions here https://www.kernel.org/doc/html/v5.0/sound/hd-audio/notes.html):

[codec]
0x10ec0298 0x144dc169 0

[model]
auto

[verb]
0x1a 0x707 0xc5

and save it as /lib/firmware/alc298-sound-patch.fw then save:

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

to /etc/modprobe.d/alc298-sound-patch.conf

Then reboot the machine and try your headphones. Next speakers! unfortunately all three mixer pins in the hda codec are set to mute and I'm working like a maniac to find a way of unmuting them, hoping that would fix the speakers. Hope this helps someone.

Went from web development to system development over this issue. Some may call that progress!

[ironincoder (ironincoder)]

Here's the full procedure to fix the headphones.

Step 1: Do the patch above, you can skip the [model] line if you wish since I found it had no effects on anything. Please note that the subsystem id can be different for various laptops (lenovo samsung etc...) so make sure you have the correct <vendor id> <subsystem id> <codec index> for the [codec] line values. To get these three values you can use https://github.com/jeremycline/hda-analyzer which requires python2 and pygtk module to run correctly. Another way is to use `sudo alsa-info.sh` command from terminal (press n when asked to upload information) to find the values. It will create a file under tmp folder which you can open via sudo vi or nano. Inside the file is a line !!HDA-Intel Codec information under which you will find the 3 values required for early patch to work, here's mine:
...
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0298
Subsystem Id: 0x144dc169
...

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

PS2: if you are a hero, then see gannon's C patch doing this same thing in a more reliable way (custom kernel).

[ironincoder (ironincoder)]

for got the variable for browsers fix (if it happens to you). Add `GTK_IM_MODULE=xim` to /etc/security/pam_env.conf file.

[Mike Pozulp (gannon1)]

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

[Terry Magnus Drever (terrymagnusdrever)]

Quite some investigations you did there ironincoder, don't forget to post here if you manage to get the speakers going. ;) I was actually wondering where the correct place to post and get codec issues fixed is, because this probably isn't the place? Is there a bug tracker for Alsa?

[Mike Pozulp (gannon1)]

Good news! A very smart Arch user by the name of ronincoder discovered a fix for the headphone jack. I worked with ronincoder to make a kernel patch [1] and our patch made it into the 5.7 kernel release! It was also applied to the 5.4 LTS kernel. I booted both 5.7.2 and 5.4.46 and the headphone jack audio is loud and clear. :)

Does it work for you? It should if you have a Samsung Notebook 9 Pro NP930SBE-K01US or NP930MBE-K04US (ronincoder's is the former, mine is the latter). You can check your laptop model by running alsa_info.sh and looking at "Board Name". The Realtek ALC298 codec in the NP930SBE-K01US and NP930MBE-K04US identifies itself with "Subsystem Id" 0x144dc169 and 0x144dc176, respectively. If snd_hda_intel sees either of these ids it implements the fix.

What about the speakers? I reported the no-sound-on-internal-speakers issue on the kernel bugzilla [2]. Linux sound maintainer Jaroslav Kysela speculates that there may be some amplifiers connected to the HDA codec which are not initialized by the BIOS, and are thus not active in Linux. He suggests dumping the codec communication for the Windows driver using QEMU. We could then parse the dump and replay the communication in Linux using Early Patching [3] or writing another kernel patch. It's been a month since Jaroslav made this suggestion and I've made some progress but I still don't have a good dump. Please join the discussion on the kernel bugzilla if you'd like to help me. ^^

[1] For reference, our patch made it into Linus' tree as commit 14425f1f521f (ALSA: hda/realtek: Add quirk for Samsung Notebook).
[2] https://bugzilla.kernel.org/show_bug.cgi?id=207423
[3] https://www.kernel.org/doc/html/v4.17/sound/hd-audio/notes.html#early-patching

[PowerKiKi (adrien-crivelli)]

I just installed a fresh Xubuntu 20.04 (Linux 5.4.0-42-generic) on my brand new Samsung Galaxy Book Ion NT950XCJ-X716A. And of course I do experience the issues described here: very low volume on headphones and no sound on speakers.

In pavucontrol, under "Output devices", I see 3 HDMI outputs, and the last one is "Speaker + Headphones". I would have expected to see something like "Built-in Audio Analog Stereo", but it's not there. Under "Configuration", I would also expect something related to built-in, but the only profiles available are "Play HiFi quality Music" and "Off".

From reading this thread it seems that a (partial?) fix is on the way. Is there a way for me try that patch already ?

And is there anything else I can do to help fix the remaining issues ? I am not sure what log are useful and how to get them ?

[jhubuntu20 (jhubuntu20)]

I have the same computer and issue as PowerKiKi... the new Samsung Ion running ubuntu 20.04.

I have found that I can make the headset jack work temporarily if I issue this command :

sudo hda-verb /dev/snd/hwC0D0 0x1a SET_PIN_WIDGET_CONTROL 0x5

But it only lasts until the sound subsystem goes to sleep (i.e. no sound to play or changing sound sources). Is there some way to make this last without having to constantly reissue the command?

I have found no viable way to make the speakers work. One forum I read said it might be related to the AKG Smart Amp in these new Samsung devices, but I have no way to prove or disprove that.

[PowerKiKi (adrien-crivelli)]

I can confirm that after installing the package `alsa-tools`, then the following command will restore sound on headphones instantaneously:

sudo hda-verb /dev/snd/hwC0D0 0x1a SET_PIN_WIDGET_CONTROL 0x5

In the meantime I did try a newer kernel, linux-headers-5.7.0-050700_5.7.0-050700.202006082127, but without success. I'll give 5.8.1 a try too...

[PowerKiKi (adrien-crivelli)]

linux-headers-5.8.1-050801_5.8.1-050801.202008111432 and booting with secure boot disabled will not anything. Still no sound, and the command workaround still works.

On a side note, the built-in mic does work as expected. So I use bluetooth headphones for listening and built-in mic for speaking.

PS: John, did you find a way to get the keyboard backlight working ? and are you running on intel or nvidia gpu (in my case nvidia gpu will always freeze the whole computer after ~10-30 minutes of desktop usage) ?

[jhubuntu20 (jhubuntu20)]

I have the 13 inch Ion with the intel built in gpu. I am also running standard Ubuntu and not Xbuntu. I have never had the system lock up or freeze on any occasion and I use it for at least 10 hours a day. My keyboard lights have also always worked perfectly from the start. In fact, the computer is an almost perfect machine for Linux and my only issues have been the sound and the fingerprint reader (which is not recognized by Linux, but I don't actually care about anyway).

Its frustrating I can't get the headphone modification to stick as a fix. I have tried everything I can think of... including adding it as a systemd daemon, adding it as an Alsa patch, adding as a hacky @reboot cron job, and changing the "options snd-hda-intel" settings in alsa-base.conf. In all cases it feels like the verb modification is lost when Alsa goes into power save mode for any reason (music source stops or sound source changes etc.). I have even tried to disable alsa power save both in alsa-base.conf and the individual files in "/sys/module/snd_hda_intel/parameters/". No luck in either case.....

If anyone is tracking, this is also a duplicate of the bug "https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1886493" where another user reported the exact same issue with the new Ions (I assume the new Samsung Galaxy Book Flex models have the same issue, but don't have one to confirm)... Just fyi...

[Mike Pozulp (gannon1)]

@PowerKiKi @John Hoff Does Early Patching as described above by ironincoder fix the problem?

If it does, and you post your alsa_info.sh output, I can submit a kernel patch for you. I did so just now for a user named terrydrever who has a Samsung Galaxy Flex Book (NT950QCG-X716) and confirmed that Early Patching fixed the bug. See https://bugzilla.kernel.org/show_bug.cgi?id=207423 for terrydrever's comments. Here's the patch https://bugzilla.kernel.org/attachment.cgi?id=290897.*

*This patch will not fix your laptop. The patch tells the driver, snd_hda_intel, to apply the fix if it sees Subsystem Id 0x144dc189, which uniquely identifies the Flex Book. The driver also applys the fix for 3 other Subsystem Ids, see https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c#L7689-L7692.

[jhubuntu20 (jhubuntu20)]

@gannon1 Thanks for the reply. Perhaps I am missing something because it seems like it should work, but I have not had any luck with the method described by ironincoder. Just to be sure I did it again from the start using the following steps (perhaps I just didn't understand and missed a step)...

- I ran alsa_info.sh and found the relevant section :

     !!HDA-Intel Codec information
     !!---------------------------
     --startcollapse--

     Codec: Realtek ALC298
     Address: 0
     AFG Function Id: 0x1 (unsol 1)
     Vendor Id: 0x10ec0298
     Subsystem Id: 0x144dc18a
     Revision Id: 0x100103

- I created a new file named /lib/firmware/alc298-sound-patch.fw and included this text in that file (his comments said you could skip the model section):

     [codec]
     0x10ec0298 0x144dc18a 0

     [verb]
     0x1a 0x707 0xc5

- I created a new file named /etc/modprobe.d/alc298-sound-patch.conf and included this text :

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

- I rebooted completely and plugged in my headphones and turned on some music. I didn't hear anything.

- I then manually ran the command sudo hda-verb /dev/snd/hwC0D0 0x1a SET_PIN_WIDGET_CONTROL 0x5
 and it works perfectly until I change sound sources or the music stops.

Did I miss a step to make this active? I can share the full output of alsa_info.sh if its helpful...

[Mike Pozulp (gannon1)]

@John Hoff Looks good to me. Can you try again after changing

[verb]
0x1a 0x707 0xc5

to

[verb]
0x1a 0x707 0x5

The latter should be identical to your hda-verb command (0x707 is the encoding for SET_PIN_WIDGET_CONTROL) except that Early Patching modifies the hda configuration BEFORE initializing the codec. I'm curious if that makes it stick (ie continue working after you change sound sources or stop the music).

[jhubuntu20 (jhubuntu20)]

@gannon1

Sure. I tried just that single character change first. No change after reboot, i.e. still had to issue the manual command. If I use the manual command with either 0x5 or 0xc5 it works perfectly in both cases. Just for good measure I also tried adding back the model section too, but no help there either. This is what I currently have in /lib/firmware/alc298-sound-patch.fw...

[codec]
0x10ec0298 0x144dc18a 0

[model]
auto

[verb]
0x1a 0x707 0x5

For whatever reason it just does not seem to find and activate the patch....

[Mike Pozulp (gannon1)]

@John Hoff

Darn. Let's try something else.

I submitted a kernel patch adding model=alc298-samsung-headphone (see attached). It exposes the quirk that fixed my Samsung Notebook 9 Pro as a "model" option that you can pass to snd_hda_intel. Give it a try:

1) Apply my patch to the linux kernel, compile, and run it. (Alternatively, wait until my patch lands in your favorite linux distribution's kernel binary and then upgrade.)

2) echo "options snd-hda-intel model=alc298-samsung-headphone" > /etc/modprobe.d/alsa-base.conf

3) Reboot

I tested on my Samsung Notebook 9 Pro (NP930MBE-K04US) which runs Arch. The filename in step 2) might be different for Ubuntu.

[jhubuntu20 (jhubuntu20)]

OK, While I would prefer to wait until the patch lands, for an ubuntu LTS that can take a while, so I tried to do it manually. I downloaded the kernel src, but I am having trouble applying the patch. I am using the command :

patch -i ~/Desktop/0001-ALSA-hda-realtek-Add-model-alc298-samsung-headphone.patch

(I downloaded your patch to my desktop folder), but this gives me an error saying "can't find file to patch at input line 20"... which is this line in the script :

@@ -7867,6 +7867,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = {
  {.id = ALC299_FIXUP_PREDATOR_SPK, .name = "predator-spk"},
  {.id = ALC298_FIXUP_HUAWEI_MBX_STEREO, .name = "huawei-mbx-stereo"},
  {.id = ALC256_FIXUP_MEDION_HEADSET_NO_PRESENCE, .name = "alc256-medion-headset"},
+ {.id = ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET, .name = "alc298-samsung-headphone"},
  {}
 };

Am I not applying the patch correctly?

[jhubuntu20 (jhubuntu20)]

@gannon1

I also tried :

patch -p1 < ~/Desktop/0001-ALSA-hda-realtek-Add-model-alc298-samsung-headphone.patch

And received the same error...

[Mike Pozulp (gannon1)]

@John Hoff

This works for me

git clone <email address hidden>:torvalds/linux.git
cd linux
git checkout v5.8
git apply ~/Desktop/0001-ALSA-hda-realtek-Add-model-alc298-samsung-headphone.patch

[jhubuntu20 (jhubuntu20)]

Yea, sorry. I was working off an apt-get version of the kernel source, then after posting, I noticed you were using git. I have downloaded from the source from git and applied the patch successfully. The new custom kernel is now in the make process. I will update once it finishes and I can activate....

[jhubuntu20 (jhubuntu20)]

@gannon1

OK, so :

    - downloaded kernel source
    - applied patch
    - ran make to create new debs
    - activated new custom kernel
    - added "options snd-hda-intel model=alc298-samsung-headphone" to alsa-base.conf
    - rebooted
    - used "uname -r" to ensure the new custom kernel was active

I then started some music and still had no sound. I manually ran the hda verb and its fixed, so essentially no change...

I am using standard Ubuntu 20.04 LTS, so on my initial git checkout I used :

    git clone git://kernel.ubuntu.com/ubuntu/ubuntu-focal.git

My custom kernel is 5.4.44-custom, which makes since because it showed as 5.4.x before I started...

I notice in your comment you did a checkout of v5.8... does that make a difference?

[Mike Pozulp (gannon1)]

@John Hoff

> I notice in your comment you did a checkout of v5.8... does that make a difference?

The fact that you were able to apply the patch and compile makes me think that a checkout of v5.8 would not make a difference.

Can you try this patch instead? (See attached)

Delete /etc/modprobe.d/alsa-base.conf because you don't need it anymore. This new patch instructs the driver, snd_hda_intel, to apply the quirk when it sees your machine, which it identifies by observing your subsystem id (0x144dc18a).

I did *not* submit this new patch for inclusion in the kernel. I made it just for you to try. If it works for you then I can add a signed-off-by line and submit it.

[jhubuntu20 (jhubuntu20)]

@gannon1

OK, had some small struggles with grub on efi, but yes, once I made a completely new kernel version with just this patch then it did work and does survive reboots and source changes, etc. So at least until a new kernel comes out I am set :)

Is there anything I can do to help with the speaker investigation?

[Mike Pozulp (gannon1)]

@John Hoff

Woohoo!!! Way to go John! That's great news. I submitted a patch to LKML (see attached). The content is the same as the patch that worked for you; all I did was change the commit message. Hopefully it lands in your favorite kernel distribution soon. :)

> Is there anything I can do to help with the speaker investigation?

Yes, come over to the kernel bugzilla and read what I've written [1]. Comment 28 lists a 2-step process - get a good trace then minimize the verbs - which has proven to be a significant technical challenge. Comment 24 describes where I left off in my quest for a trace.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=207423

[jhubuntu20 (jhubuntu20)]

@gannon1

I am still reading through all the links, but I think I get the basic concept. Like you I don't readily have a working windows VM to trace, but I will see if I can set something up. Ill let you know if I have any luck....

[Mike Pozulp (gannon1)]

@John Hoff

The windows VM is the key. It's the top layer of the 3-layer cake. The middle layer is linux and the bottom layer is the hardware. In linux we record the windows driver communicating with the audio codec in the hardware's firmware with the hope that we can play back the recording in the linux driver.

Comment 19 [1] shows my excitement when I got the VM working. Specifically, I had a windows VM in which I could play audio and hear it in the speakers. I could see the windows driver communication with the audio codec in the VM's IOMMU. I can help you get to this point, which is where I'm stuck.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=207423#c19

[jhubuntu20 (jhubuntu20)]

@gannon1

I follow the concept. I tried first using vmware workstation, mostly just cause I already had it installed for another purpose, but unfortunately no luck there. Vmware abstracts the underlying hardware and windows doesn't even see it as a realtek audio device. I also shared the problem of not being able to get samsung update installed, but I used your driver download you posted and it did install, but sadly I can't get speaker sound even with the driver in wmware...

So, I will see if I can find some time this weekend to get qemu going. One thought on your other thread... if you suspend or reboot the entire VM then you will see tons of traffic as it communicates with every hardware device. Perhaps instead you could just go into device manager and then disable and re-enable the audio device specifically while tracing. Seems like it would greatly reduce the search data, assuming it actually issues the needed command during a disable... just a thought...

[PowerKiKi (adrien-crivelli)]

@John Hoff

I saw your were successful in applying the patch. I am trying to reproduce here, but I struggled quite a bit with kernel compile/installation. I am also a bit wary of breaking my entire system as it is my daily driver.

On my latest attempt, I ended up with a running kernel 5.4.0-42, but without WiFi... :-/

Would you have any resources to help me apply the patch, compile and install the kernel the way you did ?

[jhubuntu20 (jhubuntu20)]

@PowerKiKi

I am happy to share the steps I took for information purposes, with the understanding that I can't take any responsibility on whether they will work for you or not. Performing anything like this on your daily required PC is definitely a risk. Also, your on Xbuntu, so not sure if that will cause differences or not. I did not lose wifi or anything else in the process. I did have one issue to work around with Grub2.... at least on my Ubuntu it auto installed with Grub in hidden mode. That is not a problem per say, but if you want to be able to choose between kernels at boot time then you have to switch back to menu mode... Also keep in mind that this will work until updates pushes a new kernel to your machine. Until the patch from gannon1 is accepted and incorporated by canonical it will require redoing it with every kernel update (definite technical debt). All that being said, here are the steps I took....

- check active kernel (just to see what it is before you start)
     uname -r

- Install prereqs
     sudo apt-get install git build-essential kernel-package fakeroot libncurses5-dev

- Install git if missing for some reason (i already had it installed for work)
     sudo apt-get install git

- Download patch and place at Desktop
     0001-ALSA-hda-realtek-Add-quirk-for-Samsung-Galaxy-Book-I.patch

- Create a new directory in home folder (any name you like)

- CD into new folder (in terminal)

- Clone kernel (this is likely slightly different for Xbuntu, I would recommend researching first)
      git clone git://kernel.ubuntu.com/ubuntu/ubuntu-focal.git

- CD into the `ubuntu-focal` folder created by the Git clone (in terminal, name likely xbuntu-focal for Xbuntu)

- Apply patch (change path if you didn't use Desktop and add name of patch)
     patch -p1 < ~/Desktop/{patch name with .patch}

- Make kernel (run these commands in terminal in folder created by git where you applied patch)
     cp /boot/config-`uname -r` .config
     make oldconfig
     make menuconfig (the instructions I found had this step, but i just exited)
     make clean
     make -j `getconf _NPROCESSORS_ONLN` deb-pkg LOCALVERSION=-custom
        {NOTE : change -custom to an identifier of your choice, this will be part of kernel name}

- Install newly created debs (run from same folder in terminal)
     sudo dpkg -i ../*.deb

- Update grub2
     sudo update-grub2

- Reboot (select new header in advanced options if needed) - hopefully at this point it reboots successfully and new kernel is active!

- Check to be sure new kernel was activated (you will see your identifier if successful)
     uname -r

[jhubuntu20 (jhubuntu20)]

@gannon1

Mike, I must be missing a step, but I installed qemu and virtual machine manager successfully, then found a win 10 iso and installed and activated windows in a new VM.... However, when I run that driver you mentioned in comment 19, it runs without error, but my vm still doesn't seem to know its a samsung pc. I also installed samsung update from the app store and it runs and says its not a samsung pc. Is there something I need to do to allow pass through of the underlying hardware? I do not have speaker sound in windows or linux...

[Mike Pozulp (gannon1)]

@John Hoff

> Is there something I need to do to allow pass through of the underlying hardware?

Yes. It's called vfio passthrough. Can you try doing what I did in comment 15 [1]? It is based off of the instructions in the QemuHDADump wiki [2].

[1] https://bugzilla.kernel.org/show_bug.cgi?id=207423#c15
[2] https://github.com/Conmanx360/QemuHDADump/wiki/Setup-and-usage-of-the-program

[PowerKiKi (adrien-crivelli)]

John, thank your for your help. I was able to build and run a patched kernel. And even get the sound back, but only after a modification in the patch. I noticed Mike created the patch for your machine, but named it "Samsung Galaxy Book Ion (NT950XCJ-X716A)". This is incorrect because NT950XCJ-X716A is my 15-inch machines, but you said you have a 13-inch machine.

Could you please let us know what is your model (via `sudo dmidecode -s baseboard-product-name`) ?

Then we can submit a new patch that correct the original one, and also add support for my model.

[jhubuntu20 (jhubuntu20)]

@PowerKiKi

Sure, it returns the following :

NP930XCJ-K01US

In the US, there are currently just two models of the Ion, my model and
the 15" model - NP950XCJ-K01US. The specs say both models have the same audio, so you could probably include that model as well, unless you need someone to confirm on that specific hardware....

[jhubuntu20 (jhubuntu20)]

@gannon1

Mike, I didn't have luck with the exact steps in comment 15, but the wiki written by Conner was very solid. I had to work through a couple small differences on my system, but now I have a working QEMU VM where the realtek hardware is recognized and the speakers actually work! I worked through all errors I encountered with the QemuHDADump progam and it appears to be running as expected. I went into device manager and disabled and then re-enabled the realtek audio device, and during the re-enable it recorded the following writes (along with creating related frame binary files) :

Current verb 0x2a14 Region0+0x804, 0xc0000381, 4
Current verb 0x2a14 Region0+0x1d2, 0x11, 2
Current verb 0x2a14 Region0+0x804, 0xc0000781, 4
Current verb 0x2a14 Region0+0x1d8, 0x7a5c000, 4
Current verb 0x2a14 Region0+0x1dc, 0x1, 4
Current verb 0x2a14 Region0+0x1d2, 0x11, 2
Current verb 0x2a14 Region0+0x1d2, 0x31, 2
Current verb 0x2a3c Region0+0x804, 0xc0000783, 4
Current verb 0x2c60 Region4+0xa0000, 0xffffffff, 4
Current verb 0x2c60 Region4+0xa0004, 0x0, 4
Current verb 0x2c60 Region4+0xd8, 0x30300008, 4
Current verb 0x2c60 Region4+0xd0, 0xc4000000, 4
Current verb 0x2c60 Region4+0xd4, 0x80000000, 4
Current verb 0x2c60 Region4+0xc0, 0xe4000000, 4
Current verb 0x2c60 Region4+0xc4, 0xe4000000, 4
Current verb 0x2c60 Region4+0xc, 0x0, 4
Current verb 0x2c60 Region4+0xa0000, 0x1, 4
Current verb 0x2c60 Region4+0xa0004, 0x0, 4
Current verb 0x2c60 Region4+0xd8, 0x0, 4
Current verb 0x2c60 Region4+0xd0, 0xc7000000, 4
Current verb 0x2c60 Region4+0xd4, 0x80000000, 4
Current verb 0x2c60 Region4+0xc0, 0xe7000000, 4
Current verb 0x2c60 Region4+0xc4, 0xe7000000, 4
Current verb 0x2c60 Region4+0xc, 0x0, 4
Current verb 0x2c60 Region4+0x4, 0x1010f0e, 4
Current verb 0x2c60 Region4+0x4, 0x1010f0f, 4
Current verb 0x2c60 Region4+0x8, 0x0, 4
Current verb 0x2c60 Region4+0xe8, 0x0, 4
Current verb 0x2c60 Region4+0x4, 0x1000f0f, 4

Now what? I am not sure what to do with any of this data....

[Mike Pozulp (gannon1)]

@John Hoff @PowerKiKi

Is "Samsung Galaxy Book Ion (NT950XCJ-X716A)" not a correct description of John's laptop? If not, it doesn't matter to snd_hda_intel which only looks at the subsystem id (0x144dc18a), but it's worth changing it for the benefit of any humans who read the kernel code.

I use the output from alsa_info.sh and dmidecode to determine the subsystem id and what to put for the string description, but I don't have your hardware so I can't check the output for you, which is how I (possibly) made a mistake in writing the description string.

[Mike Pozulp (gannon1)]

@John Hoff

John, great work!

> Now what? I am not sure what to do with any of this data....

Now the hard part. Here's what I think is going on:

The windows driver running in the VM controls the audio codec. How? According to section 4.4 of the Intel HDA Spec [1], the driver writes to a circular buffer known as the Command Output Ring Buffer (CORB). The HDA controller, which is implemented by the hardware manufacturer and shipped as firmware in the chipset, takes commands from the CORB and sends them to the codec.

Qemu provides the memory for the VM. That means qemu can see every time the VM writes to memory. That's a lot of writes! We only care about the subset of writes to the memory region allocated for the HDA controller, which is what we get when we specify "vfio_region_write" event tracing. My laptop has this HDA controller

00:1f.3 Multimedia audio controller [0401]: Intel Corporation Cannon Point-LP High Definition Audio Controller [8086:9dc8] (rev 11)

so when I see qemu output a trace line that looks like

3064@1591386653.159507:vfio_region_write (0000:00:1f.3:region0+0xe, 0x7fff, 2)

I know that the driver wrote to the HDA controller memory because the pci device id "1f.3" matches the HDA controller. We can decode the rest of the line by looking at the qemu source code [2]. 0xe is the memory offset at which the driver wrote, 0x7fff is the data, and 2 is the size of the data in bytes.

Which vfio_region_write events are CORB writes? The answer requires an understanding of the CORB protocol. The CORB has a fixed size which may be up to 256 entries. That means that all CORB writes are made to memory within a CORBSIZE range of addresses. After the driver writes an HDA verb to the CORB, the driver writes a value from 0x0 to 0xff to the CORB Write Pointer (CORBWP) register which tells the HDA controller the last valid CORB entry offset so the HDA controller knows how far to read before stopping and waiting for more data.

Enter QemuHDADump (QHDAD). QHDAD is a program that someone wrote and published on github which attempts to parse vfio_region_write lines from qemu to determine the CORB address and record all HDA verbs written to the CORB. The author of QHDAD has his/her own hardware and did not test it on my laptop or your laptop so it is likely buggy and therefore may not produce a good recording of verbs. We don't have to use QHDAD; we just need some way to parse CORB writes from vfio_region_write events.

Because the speaker sound works on Windows that means that if we send the verbs in the recording to the HDA controller using snd_hda_intel we may be able to get the speakers work on Linux. Once we demonstrate that the speakers function after passing all the verbs in the recording we need to minimize the verbs if we want any hope of our patch being included in the kernel. Many of the verbs will be "getters" instead of "setters" which we can delete. After that it may be a tedious trial-and-error process to see which of the remaining verbs we can delete. The verb encodings are specified in the Intel HDA Spec which can help us guess what can be deleted.

The end goal is a patch which looks like this one [3].

[1] https://www.intel...

[PowerKiKi (adrien-crivelli)]

@Mike Pozulp, it is correct that the model name referred in the merged patch is incorrect. It refers to my model.

For future reference here is my alsa-info.sh: http://alsa-project.org/db/?f=f13c46c58bba7ed21035e65230899b18419cd337

Where we can see:

    Board Name: NT950XCJ-X716A
    ...
    Subsystem Id: 0x144dc830

I attached here the patch fixing the model name for John's, and adding support for headphone for my model.

I'd love to submit the patch, but I've never done that before. I'll see if I can figure it out later tonight...

[Mike Pozulp (gannon1)]

@PowerKiKi

Wondeful, thank you for clarifying. =)

> I'd love to submit the patch, but I've never done that before. I'll see if I can figure it out later tonight...

That would be great - go for it! Nick Desaulniers has a good blog post which describes how to submit a patch [1]. I read it and then ran this sequence of commands to generate and submit my first patch:

git commit
git format-patch HEAD~1
./scripts/checkpatch.pl 0001-ALSA-hda-realtek-Add-quirk-for-Samsung-Notebook.patch
git send-email 0001-ALSA-hda-realtek-Add-quirk-for-Samsung-Notebook.patch
./scripts/get_maintainer.pl 0001-ALSA-hda-realtek-Add-quirk-for-Samsung-Notebook.patch
git send-email \
--cc-cmd='./scripts/get_maintainer.pl 0001-ALSA-hda-realtek-Add-quirk-for-Samsung-Notebook.patch' \
0001-ALSA-hda-realtek-Add-quirk-for-Samsung-Notebook.patch

[1] http://nickdesaulniers.github.io/blog/2017/05/16/submitting-your-first-patch-to-the-linux-kernel-and-responding-to-feedback/

[PowerKiKi (adrien-crivelli)]

@Mike, thanks for your help! I was able to submit the patch. Easier than I thought :-)

FYI it ended up there: https://lkml.org/lkml/2020/8/24/977

[jhubuntu20 (jhubuntu20)]

@gannon1

I am tracking what your saying concept wise. Here is a summary of what I did today, in part just to help me clarify my thoughts and in part so you can maybe correct any gaps and save me troubleshooting time :).

- I have gone through all the documents in the wiki for QemuHDADump and as far as I can tell it is running as expected on my PC and creating good logs. I am able to see the logging happening in real-time and I get the frame binary files. I am also able to use his extract and format programs to "see" the data as text. As an example, the attached file named CORB has the final formatted output from disabling and re-enabling the realtek device in windows....

- Looking at the HDA spec, this seems to be the only detailed description of the CORB entries :

     HDA Spec CORB 32 bit format
     The controller generated (outbound) Verb format
         Bits 31:28 Codec Address
         Bits 27:20 Node ID
         Bits 19:0 Verb Payload

     It is not currently clear to me how to parse the "verb payload" or how to map
     these CORB values into anything useful.

- Several of the documents you listed and your comments mention playing back or using the values to turn on the sound. I assume (maybe incorrectly), that we are trying to a) produce a list of HDA Verb commands that match each CORB entry to prove the sound turns on and then B) work to whittle down the list to the minimum required ones. Part B will be effort, but I think that will just be applied time once we achieve Part A. For Part A, again my assumption, we are trying to convert CORB values into the HDA Verb format :

    HDA Verb format
     The hwdep device name
     The widget NID
     The verb
     The parameter

- Since I was stuck on what to do with the output from QemuHDADump, I went back and read the other articles more, specifically the BSD article. That author took a different approach and instead of using the QemuHDADump program, he just altered Qemu to give him more info in the output. His source code was available so I worked with that to try and replicate his results. I couldn't just use his common.c file directly because we are on different version of qemu, but I was able to modify the common.c file on my version of qemu, and then remake qemu successfully. So now, instead of just getting lines like this :

15469@1598294292.270884:vfio_region_write (0000:00:1f.3:region0+0x48, 0xad, 2)
15469@1598294292.270975:vfio_region_write (0000:00:1f.3:region0+0x20, 0x40000000, 4)
15469@1598294292.270983:vfio_region_write (0000:00:1f.3:region0+0x5d, 0x1, 1)

I get more information, like this :

15469@1598294292.272359:vfio_region_write (0000:00:1f.3:region0+0x5d, 0x1, 1)
RIRBWP advance to 185, last WP 183
CORB caddr:0x9 nid:0x47 control:0x407 param:0x20 response:0x64756c63 (ex 0x6f466465)
CORB caddr:0x0 nid:0x0 control:0x1 param:0xe6 response:0x65735572 (ex 0x544e4900)
RIRBWP advance to 185, last WP 185
RIRBWP advance to 185, last WP 185
RIRBWP advance to 185, last WP 185
15469@1598294292.272436:vfio_region_write (0000:00:1f.3:region0+0x20, 0xc0000000, 4)
CORBWP advance to 187, last WP 185
CORB[186] = 0x0 (caddr:0x0 nid:0x0 control:0x0 param:0x0)
CORB[187]...

[jhubuntu20 (jhubuntu20)]

@gannon1

enable file...

[jhubuntu20 (jhubuntu20)]

@gannon1

disable file

[Mike Pozulp (gannon1)]

@John Hoff

> enable file...

Can you re-attach? I don't see it.

> Anyway, thoughts? Do you have any more clarity on how to replay the CORB commands?

Take a look at this patch [1]. Use the CORB command recording to write a similar patch. It will contain a 2034-entry long array of hda_verb structs [2]. Each hda_verb contains

{Node ID, Verb ID, Payload}

Apply your patch, compile, and run.

[1] https://github.com/tespeleta/linux/commit/761cca49e9153b7832fa3f887b875e5ad1517892
[2] https://github.com/torvalds/linux/blob/master/include/sound/hda_codec.h#L360-L364

[Sanggyu Lee (sanggyu)]

I have similar problems in 950XBE.
I tried
$sudo hda-verb /dev/snd/hwC0D0 0x1a SET_PIN_WIDGET_CONTROL 0xc5
but there's still no sound from the headphone.
Are the pins different for Samsung Notebook 9 Always?

!!DMI Information
!!---------------

Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
Product Name: 950XBE
Product Version: P05AHC
Firmware Version: P05AHC.061.190423.PS
Board Vendor: SAMSUNG ELECTRONICS CO., LTD.
Board Name: NT950XBE-X58

!!HDA-Intel Codec information
!!---------------------------
--startcollapse--

Codec: Realtek ALC298
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0298
Subsystem Id: 0x144dc16f
Revision Id: 0x100103

[Sanggyu Lee (sanggyu)]

After changing alsa-base.config according to #6, headphones are working in 950XBE.
Attaching alsa-info with model=mono-speakers and headphones connected.

[jhubuntu20 (jhubuntu20)]

@gannon1

Not sure what happened to the enable file, here it is again...

Anyway, on your other comment, I assume the Verb ID and Payload you mention would be the control and param values from my logging?

Do you know if that is a way to do this troubleshooting with the hda verb approach as opposed to a patch (i.e. do you know how to properly map the values from my new logging to HDA Verbs or is there another way to execute the commands)? I ask because I am not confident in my ability to create a perfect patch on a single try (never having done it before) and this is my main work computer, so I need to be somewhat careful. I could try the patch approach in a linux VM maybe, but not sure if that would be predictable....

[jhubuntu20 (jhubuntu20)]

@gannon1

I am also going to create a new recording today that is just the VM booting. It seems to me that our problem may not be the audio device itself, but the AKG smart amp not turning on. I am not confident that the disable and re-enable I was doing of the realtek audio device in windows impacts the amp. It might, but I know for sure that when I boot the VM the speakers are made active because the sound works at that point. Also, I had to bind 4 different things to my immot group to make this all work, so that also makes me think it is not just a single device we are after....

[jhubuntu20 (jhubuntu20)]

@gannon1

Some thoughts based on what I did today. I did make a recording (twice to make sure I didn't do it poorly) of the VM boot process. So from the time the VM initializes until you first see the win 10 desktop. To my surprise there is only 1 single CORB command during that process. It is this line and it is issued ~2173 times during the boot sequence of the vm :

CORB[45] = 0x0 (caddr:0x0 nid:0x0 control:0x0 param:0x0)

So I don't think that was super helpful, other than it leads me to believe that the audio device and speakers are not initialized until needed, which might help shrink our search a bit. I next took a simple 9 second wav file and placed it on the desktop. I (trying 3 times to make sure it was reproducible) booted the VM, cleared the logs, and then clicked on the sound file to play it with media player. It does play through the speakers, so it seems like this data will have what we need. I was also concerned that if the driver is enabled JIT then perhaps it also disables it again when the sound ends, so I devised a way to capture just the CORB commands between the time I clicked on the file and I first heard sound....

I then used scripting to reduce it to just the CORB[x] lines and that gives us the attached smaller list of 944 CORB commands (attachment Play2Slim).

[jhubuntu20 (jhubuntu20)]

@gannon1

Mike, depending on your answers to my many questions from today, if the only way we know to proceed is to build and test a patch, could you help with building the patch (or at least the basic framework of the patch so I can just plug in the CORB values)? I used the attached spreadsheet to parse out the values to hopefully make that process easier. I am comfortable making a new kernel if I have a probably valid patch, but I am not as comfortable at this point making a good patch based on your links. I know I can and probably should learn that process, but I would need to stand up a new machine and it would take much more time (and I would really like to have sound again soon).

[Mike Pozulp (gannon1)]

@John Hoff

> Mike, depending on your answers to my many questions from today, if the only way we know to proceed is to build and test a patch, could you help with building the patch (or at least the basic framework of the patch so I can just plug in the CORB values)?

Absolutely. I'll write a patch and test it on my machine, after which I'll share it with you. In the mean time you could try Early Patching. Your Early Patching file will have an enormous [verb] section which will look like this

[verb]
0x1a 0x707 0xc5
.
.
.

Each line contains three space-separated hex values: Node ID, Verb ID, and Payload. You will have one line for each verb in the CORB dump, so that could be 1000s of lines.

I think hda-verb < Early Patching < kernel patch, in the sense that a kernel patch has the highest-probability of success, hda-verb has the lowest, and Early Patching is somewhere in between. This is because I think that some codec values are read-write at initialization time but then become read-only at runtime (only Realtek, the ALC298 manufacturer, knows for sure*). A kernel patch allows us to write values at codec initialization time, whereas hda-verb is at runtime, and Early Patching is somewhere in between.

*Perhaps we can know: I found a datasheet for the ALC269 [1]. I think the ALC269 is very similar to the ALC298 codec in our laptops. Among other things, the datasheet describes verb semantics. It's a nice supplement to the Intel HDA spec. I don't recall seeing anything about initialization-time vs runtime, but perhaps I have not read it closely enough - the datasheet is only somewhat less dense and technical than the Intel HDA spec so it's not an easy read! :)

[1] https://www.hardwaresecrets.com/datasheets/alc269.pdf

[jhubuntu20 (jhubuntu20)]

@gannon1

Thanks. You are correct that HDA Verbs were not successful. Assuming I did it correctly, I already wrote a script to produce a script that had each of the 944 verbs and it did not turn on the sound. I tried that yesterday, but failed to mention it.

If you find that a patch with the 944 does work then let me know and I will be happy to help with the grunt work to reduce the list. I am assuming we will just break the list in two halves, see which half works, and repeat until we see a small enough remainder or find the specific line(s)....

In the meantime I will take a look at the early patching approach...

[jhubuntu20 (jhubuntu20)]

@gannon1

Using the same steps we tried before, no luck with early patching. Early patching didn't work on the Ion for headphones either, so could be something with this laptop. Attached are the fw and conf files if any else wants to try it... just change the id value to match your sound device...

[jhubuntu20 (jhubuntu20)]

conf file...

[jhubuntu20 (jhubuntu20)]

@gannon1

Mike, after reading more on the patch links you sent me before, it occurred to me I might have an easier way to test the 944 while you create the proper patch. Namely, I followed the same procedure as before with the headphone patch, but right before I made the new custom kernel I just added the new candidate CORB values to the new patch_realtek.c file in my new custom header... so basically just modified the samsung headphone very quiet fixup (partial sample below). While not a proper solution, I figured it might work for testing. Unfortunately, even after rebuilding, etc, I still don't have sound. Assuming I didn't miss anything, I am not sure why we wouldn't have the right corb value since the 944 covered from boot to hearing sound. I guess I can try again with the full halt and restart process as listed in the openbsd article...

[ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET] = {
  .type = HDA_FIXUP_VERBS,
  .v.verbs = (const struct hda_verb[]) {
   { 0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, 0xc5 },
   { 0x0, 0x0, 0x2a },
   { 0x0, 0x230, 0x3 },
   { 0x0, 0x0, 0x27 },
   { 0x0, 0x0, 0x0 },
   { 0x19, 0xa7c, 0x2 },
   { 0x37, 0xb0a, 0x0 },
   { 0x50, 0xa00, 0x11 },
   { 0x22, 0xa16, 0x2 },
   { 0x1, 0x19c, 0x7b },
   { 0x70, 0x22d, 0xa },
   { 0x47, 0xb02, 0x2a },
   { 0x70, 0xa00, 0x11 },
   { 0x20, 0x11, 0x9e },
   { 0x2, 0xa58, 0x17 },
   { 0x0, 0x330, 0x3 },
   { 0x0, 0x0, 0x2e },
   { 0x0, 0x0, 0x0 },
   { 0x62, 0x802, 0x3 },
   { 0x20, 0xa00, 0x11 },
   { 0x32, 0xa14, 0x2 },
   { 0x40, 0x20c, 0x2d },
   { 0x20, 0x11, 0x9a },
                        ... (all 944 lines)

[Mike Pozulp (gannon1)]

@John Hoff

> Namely, I followed the same procedure as before with the headphone patch, but right before I made the new custom kernel I just added the new candidate CORB values to the new patch_realtek.c file in my new custom header... so basically just modified the samsung headphone very quiet fixup (partial sample below).

Looks good to me.

> I guess I can try again with the full halt and restart process as listed in the openbsd article...

Good idea.

No one promised us that this would work. However, we gave it a try, which is what Jaroslav asked us to do way back in May (see bugzilla comment 14 [1]). Can you post your results in the kernel bugzilla and then ping Jaroslav?

$ ./scripts/get_maintainer.pl sound/pci/hda/patch_realtek.c |grep Jaroslav
Jaroslav Kysela <email address hidden> (maintainer:SOUND)

[1] https://bugzilla.kernel.org/show_bug.cgi?id=207423#c14

[jhubuntu20 (jhubuntu20)]

@gannon1

Sure. I found I am not getting the consistent output from the new logging that I expected, so I want to try a couple of things this weekend to understand it better. Then I will type up a brief summary and post it in the other thread...

[jhubuntu20 (jhubuntu20)]

@gannon1 @PowerKiKi

Mike, I never heard back from Jaroslav (I suspect he is pretty busy), and my consulting work is very slow with the pandemic so I just continued to work on it. Your concept is spot on. Thank you for all the wisdom and thoughtful guidance. I am happy to report, after much more effort than I care to admit, that step 1 has been successfully achieved and I have stereo sound through my laptop speakers... finally! Once you get through all the numerous setup pitfalls, it seems (a bit of an assumption on my part) like the big gotcha is that the windows driver appears to instantaneously turn off the speakers when not in use (i.e. if you record a large time period like booting or disabling and enabling devices then the speakers start and end in off mode and you never catch it). It took numerous attempts to catch the right segments.

Anyway, I have begun working on step 2 now. I stared with >2000 verbs and am down to what seems to be a consistent 788. I am confident there are more to eliminate because it turns on the left speaker (alone) then turns on the right speaker (alone), then (most importantly) ends with stereo. For at least the galaxy book ion (likely will work for others too), I should be able to provide an optimized result soonish.

PowerKiKi, even with the Xbuntu difference, I feel confident what I have now will at least work for you since you have the same Ion hardware. The sound is actually pretty good on these laptops (I never heard it before today because I wiped windows on day 1 :).... If you would like to give it a shot, just run the attached script. I use it on top of running a custom kernel that includes Mike's headphone patch and I have full sound on speakers and headphones during the entire session. Once I minimize the verbs I will try creating a custom kernel with the final verbs (I have skipped that for now because the hda verbs work fine and each attempt at a custom kernel is about an hour journey..)

[PowerKiKi (adrien-crivelli)]

This is great news !

I just tried your script, while a song was already playing, and I instantly got sound on my speakers (both left and right).

While the script is running I can hear each side coming on. First left, then right.

I also noticed that if switching to my bluetooth headphones, the headphones will start, and the speakers will stop (as expected). However when switching off my bluetooth headphones, the speaker will not work again. But of course running the script again will restore speaker sound. This sounds similar to the "non-sticky" behavior we experienced for cabled headphones.

Anyway thanks a lot for the huge effort you put into this !

PS: I also run a custom Kernel with a slight variation of Mike's patch.

[jhubuntu20 (jhubuntu20)]

@PowerKiKi

Yes, this is just a temporary step until I finish minimizing the verbs. I was hoping it would be as easy as just finding the single command or two in the group of 788, but it appears to be a longer combination of sequences, so will take just a bit more tinkering to isolate. I will get it sorted and then we can ask Mike to add it as part of his patch. I didn't test with bluetooth headphones (I still use old school wired ones), but bluetooth is a completely different pathway and bluetooth audio has always worked on mine from the very start. I am able to go between regular headphones and the speakers now and pulse changes the source automatically back and forth, so for me at least, it is not as bad as the original stickiness problem. Pretty much once I boot and run the script it lasts until I reboot. As you suggest, we can hopefully even eliminate that step once Mike adds to a patch...

[jhubuntu20 (jhubuntu20)]

@PowerKiKi
@terrymagnusdrever
@gannon1

Just to document this for anyone else that might benefit, attached is the final script I created. I reduced the previous list further from 788 to 358 verbs. There may be a few extra ones left, but probably not many based on my testing, as removing more tends to lose one speaker or not generate enough volume or other weird unexpected side effects. Its definitely a long sequence of blocks of data that is critical as opposed to one or two single statements. Anyway this smaller list appears to achieve the original goal. If anyone ever wants to reduce further, the data is broken into many blocks that look something like this (where the row right after the one that ends with 0x23 appears to be most important - so in this case its one of the 0x20 blocks):

sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0x26
sudo hda-verb /dev/snd/hwC0D0 0x20 0xc00 0x0
sudo hda-verb /dev/snd/hwC0D0 0x20 0x500 0x23
sudo hda-verb /dev/snd/hwC0D0 0x20 0x400 0x20
sudo hda-verb /dev/snd/hwC0D0 0x20 0x400 0x0
sudo hda-verb /dev/snd/hwC0D0 0x20 0x400 0xc0
sudo hda-verb /dev/snd/hwC0D0 0x20 0x4b0 0x11

Once you learn to work with the data as blocks it gets a lot easier to sort.

Anyway, as far as what to do with this script....

I was not able to make a kernel patch that worked (maybe Mike can) and I was not able to get early patching to work (which could be me because I have never had any success with early patching). Originally I was just running the script manually at boot, but I found that just creating a simple systemd daemon does the trick (steps below). Now when I boot I have full sound and it seems to last for a while. What was most unexpected was that I also added back the single HDA verb for the headphones (which I specifically tried and found did not work before as a stand alone daemon) and now my headphones work along with the speakers WITHOUT using the custom kernel patch that Mike created. Bizarre, but whatever works.

Since my last script worked for PowerKiKi I feel confident this will work for most Ion owners, but there is nothing in the script that is truly specific to the Ion laptop. The Samsung Flex was released on the same day and appears to have the same audio hardware, so likely this works for flex users too. It may also work for pro or always users, I am just not as sure on the hardware on those.

Steps to create daemon

1) Place the verb script in whatever location you prefer (it needs to stay in one spot)

2) Make the permissions on the script file 777 and +x

3) Create a new daemon file named .... /etc/systemd/system/ionsound.service

4) Place this text in your new daemon file

    [Unit]
    After=network.service

    [Service]
    ExecStart={full path to where you placed the file}/TO912.sh

    [Install]
    WantedBy=default.target

5) Update the daemon file permissions to 664

    sudo chmod 664 /etc/systemd/system/ionsound.service

6) Activate the daemon

    sudo systemctl daemon-reload
    sudo systemctl enable ionsound.service

7) Reboot and you should have sound

[PowerKiKi (adrien-crivelli)]

This new script also works for me, thanks.

However, with both versions of the script sound will stop working after ~30 seconds of inactivity. So it is not "sticky" in my case. An easy workaround is to play an audio file on infinite loop with volume down to zero. This will keep the speakers enabled forever without any side-effect.

I can live with that for a while.

[jhubuntu20 (jhubuntu20)]

@PowerKiKi

That is very odd, mine lasts for hours and hours.....

I wouldn't think ubuntu and xbuntu would be that different with regard to audio hardware mgmt, but one guess off the top of my head is that before I found this thread I turned off power mgmt for snd_hda_intel to try to get the headphone verb to be sticky. Obviously this will increase power usage some, but I have not noticed any difference in battery life. If you want to try it, here are the steps I tried (it can be reversed easily if it doesn't help)...

1) Go to folder

    /sys/module/snd_hda_intel/parameters/

2) modify 2 files

    sudo gedit power_save

         change 1 to 0

    sudo gedit power_save_controller

         change Y to N

3) If you still have an alsa-base file (Mike had me delete mine with his patch), you can add these lines too...

    sudo gedit /etc/modprobe.d/alsa-base.conf

         Add

         options snd-hda-intel power_save=0
  options snd-hda-intel power_save_controller=N

[ironincoder (ironincoder)]

I got a chance to get the pro 9 back for a brief moment and run the CORB script from @John, but that 0x20 block did not do it for this sub-model (0x144dc169).

[jhubuntu20 (jhubuntu20)]

@ironincoder

I highlighted the 0x20 block just to explain how the data is structured. You need to run the full script (TO912.sh) with all 358 verbs to hear sound.

[Kacper Michajłow (kasper93)]

I tested your script on my 930SBE. It sort of worked, I indeed got output on speakers, but the quality was terrible, sound was metallic and tiny. Generally looks like we are setting AMP coefficients and those vary between models. I will set up and dump verbs for my machine when I get some free time.

[Kacper Michajłow (kasper93)]

Also an idea for understanding what specific verbs are responsible for. In Samsung Settings thingy there is a audio profile selection, we could diff verbs set between those profiles.

[jhubuntu20 (jhubuntu20)]

@kasper93

That is good to know. Makes sense that the CORB values might differ somewhat. The ION has the AKG smart amp and dolby what not, so my CORB sequence is likely tuned for that combination of items. It actually sounds really good for a laptop. I think there may already be a fix out there for the metallic sound issue. I never had it on my system, but remember reading about it on other setups. If nothing else, we know the procedure recommend by Mike works and you could just capture the CORB values (with a decent amount of effort) on each different system. I am not sure what the samsung settings thingy is, but that sounds like it could be very helpful.

[Kacper Michajłow (kasper93)]

@jhubuntu20

> The ION has the AKG smart amp and dolby what not

Same here actually, I believe Samsung used the same hardware.

> I think there may already be a fix out there for the metallic sound issue

Yeah, my bad. I did quick test and start typing response, sorry. It is PulseAudio that mess up my audio. When I bypass PA, sound is perfect. I compared it to Windows. Windows is a lot louder like 35% is already loud, on Linux it is ~75%. But it is perfectly fine. As for quality, this would need proper testing, if everything is on par. Also those are laptop speakers, so it doesn't matter much, one wouldn't listen to music and expect quality output on those tiny speakers :)

> I am not sure what the samsung settings thingy is

I meant Samsung Setting application (Fn+F1), there are 4 audio profiles to select and I believe they adjust amp/dac parameters when switching them, but that's not that important.

[Kacper Michajłow (kasper93)]

Just for reference to fix my remaining audio issues I did:

1. Compiled latest PulseAudio (https://gitlab.freedesktop.org/pulseaudio/pulseaudio)
2. Copied latest ucm2 configs to /usr/share/local (https://github.com/alsa-project/alsa-ucm-conf)
3. Enabled SOF driver
    echo "options snd_intel_dspcfg dsp_driver=3" > /etc/modprobe.d/sof-options.conf

Works like charm now. Good work, it must have took so quality time to extract and minimize number of verbs needed.

[Kacper Michajłow (kasper93)]

duh, in step 2 /usr/share/alsa of course.

[jhubuntu20 (jhubuntu20)]

@kasper93

That is great news, sounds like the same fix will work for multiple models then!

[Duke Fong (duke-c)]

@kasper93

I still have the metallic sound issue, after did 3 steps you list in #99. (No problem without pulseaudio.)

It must be that a certain detail has not been handled properly. Do you know what it is?

I have to put this line in /etc/modprobe.d/alsa-base.conf, without it, the sound card driver refuses to install:

options snd-hda-intel dmic_detect=0

By the way, my laptop's id and model are not in the patch. I added a line to sound/pci/hda/patch_realtek.c by myself:

SND_PCI_QUIRK(0x144d, 0xc188, "Samsung Galaxy Flex Book (NT930QCGI-PS5)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),

[jhubuntu20 (jhubuntu20)]

@PowerKiKi

PowerKiKi, I had to reload my pc for another project, and after reloading I found that same lack of stickiness... Not wanting to go backwards, I felt I had to chase down the full fix. This should fix your issue (caused by pulse) if you want to skip the background audio file...I also improved the Daemon script to ensure later execution and added a second daemon to run the script on suspend/restore. With this setup I have not had to manually run the script in a week or so. Its like sound just works normally now...

Fresh Install Setup Steps

 sudo apt-get install alsa-tools
 Rename alsa-base to bkup /etc/modprobe.d/alsa-base.conf
 placed TO912.sh script with verbs and set as 777 +x
 create and placed $ sudo chmod 664 /etc/systemd/system/ionsound.service

  [Unit]
  Description=Custom Sound

  [Service]
  Type=idle
  ExecStart=/home/ion420/Hoff/Linux_Files/Ion_Audio/TO912.sh

  [Install]
  WantedBy=multi-user.target

 create and placed $ sudo chmod 664 /etc/systemd/system/ionsoundsleep.service

  [Unit]
  Description=Custom Sound Sleep Fix

  [Service]
  Type=idle
  ExecStart=/home/ion420/Hoff/Linux_Files/Ion_Audio/TO912.sh

  [Install]
  WantedBy=suspend.target

 activate
  sudo systemctl daemon-reload
  sudo systemctl enable ionsound.service
  sudo systemctl enable ionsoundsleep.service

 turn off pulse idle
  sudo gedit /etc/pulse/default.pa
  Add comments to ### load-module module-suspend-on-idle

 verify script runs at boot and sound works ..

[Kacper Michajłow (kasper93)]

@duke-c

> It must be that a certain detail has not been handled properly. Do you know what it is?

Nothing specific that I can think off, I'm running 5.8 kernel so there might be that, depending what you are running.

> I have to put this line in /etc/modprobe.d/alsa-base.conf, without it, the sound card driver refuses to install:

Again might be kernel version difference. There were a lot of related changes in few previous versions. I remember with certain version it didn't work at all and dmic_detect forced fallback.

[Kai-Heng Feng (kaihengfeng)]

This issue should be fixed after 5.4.0-49.53.

[jhubuntu20 (jhubuntu20)]

@kaihengfeng

Can you describe what fix was implemented? I updated to kernel 5.4.0-52-generic in Ubuntu 20.04 and it is not fixed. I still must run the script. Also, something has regressed with the latest updates because now I have to manually run "pulseaudio --start" after booting to get it all to work. Prior to running this command PulseAudio Volume Control just stays stuck on establishing connection. It did not do this before the last batch of pulse and alsa updates....

[Mike (draamses)]

@PowerKiKi
@terrymagnusdrever
@gannon1

I have the same problem on my Galaxy Book Flex 2020 (system id 0x144dc189).
The new kernel helped the earphone work, but there is still no sound from the speakers, even when I am trying the verbs and daemon suggested here. I assume these work for the ION, but not on the FLEX.
Is there any way to make the speakers work?
This is my RtHDDump.txt:
https://pastebin.com/m3xaE2DU

[jhubuntu20 (jhubuntu20)]

@draamses

I am surprised to hear it doesn't work, at least manually, on the flex. I obviously don't work for samsung and don't know the hardware internal details, but there is nothing in the script that is known to be explicitly model specific. I am also just running a standard ubuntu kernel now with none of the previously discussed kernel modifications, and the headphone jack and the speakers work with the script. It used to work automatically with the deamon before the last pulse and alsa update in ubuntu, but now I have an issue with pulse starting properly at boot. It is a real mystery why the flex is different given that the flex and ion were released at the same time, that both appear to have the same alc 298 sound devices, and that the script works on the always (released a few years earlier). Possibly there are two separate issues on the flex and both have to be resolved. Do you have pavucontrol installed and if so, do you see "sof-hda-dsp speaker + headphones" in the list of output devices? If not, you may also need to run "pulseaudio --start" before running the script. Also, have you completed the step to turn off the auto idle for pulse? If not, if you run the script before you have sound playing, then pulse will break the sound when it puts the sound card to sleep. To turn off the pulse power saving just run "sudo gedit /etc/pulse/default.pa" and comment out (add the ###) the line that reads "load-module module-suspend-on-idle". And reboot of course. You can easily revert if needed but just removing the ###.

[jhubuntu20 (jhubuntu20)]

Just FYI for anyone interested, The daemon is now working again. Looks like the last update of systemd caused the issue. Through another forum I found I was able to fix it by just running "sudo apt reinstall systemd" (which also fixed the broken battery indicator).

[Mike (draamses)]

Yeah, thanks a lot, it actually does work on the FLEX :)
I misread post #90 and tried only the verbs listed instead of the entire script.
Using the full attached script it works fine now, on MInt 20 (Kernel 5.4.0-52)
I tried the same verbs on the latest Manjaro, slightly newer Kernel 5.4.72. It works there too, however the sound is quite metallic.
Any way to fix the metallic sound?
When will this fix be implemented in linux out of the box, rather than having to perform all of these steps to get the speakers to work?

[Mike (draamses)]

Re: Metallic sound
Forgot to mention - it seems to happen only on the speakers, not on the headphones.

[Mike (draamses)]

One possibly important finding:
The metallic sound happens with Chrome but not with Firefox, running the same youtube video.
I googled and found that chrome is using ALSA, while FF is using Pulseaudio. Maybe that's the issue.
Got no idea how to solve this tho.

[Mike (draamses)]

PLease disregard my last comment (#112). It happens in FF too, but on other websites.

[Mike (draamses)]

Re: Metallic audio

Upgraded the kernel from 5.4.0-52 to 5.4.72 as I have on Manjaro.
Result: Metallic audio.

Booted again with 5.4.0-52
Result: Clean audio

Conclusion: quite likely a kernel issue.
How can we get this reported and fixed?

[Mike (draamses)]

Decided to do more trial and error tests.
I tried multiple amd64 kerels from https://kernel.ubuntu.com/~kernel-ppa/mainline/
It seems that all kernels I tried produce metallic audio, I believe you can easily reproduce this by trying them.
Even the 5.4.52-050452.202007160732 kernel produced metallic sound, while the official Mint 5.4.0-52 kernel produces clean audio.
Official Mint kernel 5.8.0-28 also produces clean audio.

Any thoughts?

[Mike (draamses)]

To answer my own question - I suppose the ubuntu kernels are more optimized and have multiple fixes and drivers that the mainline/upstream kernels do not and that's why I get the metallic audio...
I wonder what was fixed in Ubuntu's kernel to make this issue go away.

[Kai-Heng Feng (kaihengfeng)]

Please check if your system id is included:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/pci/hda/patch_realtek.c#n7917

[Mike (draamses)]

Yes, it is.
For some reason linux loads snd_hda_intel instead of snd_soc_skl_hda_dsp ALSA module and this causes the metallic audio.
How can I get it to load snd_soc_skl_hda_dsp ALSA module?

[jhubuntu20 (jhubuntu20)]

@kaihengfeng

Yes, my model is included :

SND_PCI_QUIRK(0x144d, 0xc18a, "Samsung Galaxy Book Ion (NP930XCJ-K01US)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),

However, the quirk called "ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET" is just the fix for the headphone jack only. So yes, that fix is now implemented, but what about fixing the actual speakers. Now that we have a sequence of verbs that enables speaker sound, can someone add those to another quirk so sound on the speakers works out of the box too?

[jhubuntu20 (jhubuntu20)]

@draamses

I never encountered the metallic sound on my ion, so I am probably not much help on that one. I do recall reading about it when I was researching the speaker issue, so I do agree it is a separate issue. If you google around a bit, it seems like there was a separate fix for metallic sound already identified.

[Mike (draamses)]

@jhubuntu20

I am pretty sure this is caused by snd_hda_intel being loaded instead of snd_soc_skl_hda_dsp
When I tested ubuntu kernel, the sound was clean and they all ladded snd_soc_skl_hda_dsp, however any mainline kernel produced metallic sound and those load snd_hda_intel
I have created a tutorial for Manjaro that may help people with other distors and similar laptops. It is largely based on your efforts, so thank you for that. :)
https://forum.manjaro.org/t/guide-how-to-set-up-the-audio-card-in-samsung-galaxy-book/37090

[jhubuntu20 (jhubuntu20)]

@draamses

I am glad to hear it works on the flex. Thanks for the kind words, but Mike Pozulp deserves most of the credit. He seems to have disappeared here, but he had the key process for how to do it. For what its worth, I don't recognize snd_soc_skl_hda_dsp (of course I am not using Manjaro). On my ion with standard ubuntu 20.04 it was never metallic. From "lspci -nnv" on my system :

00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device [8086:02c8]
 DeviceName: Onboard - Sound
 Subsystem: Samsung Electronics Co Ltd Device [144d:c18a]
 Flags: bus master, fast devsel, latency 32, IRQ 166
 Memory at 6023118000 (64-bit, non-prefetchable) [size=16K]
 Memory at 6023000000 (64-bit, non-prefetchable) [size=1M]
 Capabilities: <access denied>
 Kernel driver in use: sof-audio-pci
 Kernel modules: snd_hda_intel, snd_sof_pci

[Mike (draamses)]

Yes, if you check alsa-info (here is my output: http://alsa-project.org/db/?f=608b0585907cc0f959ebc2528e771f5260685382), you will find it:
!!Loaded ALSA modules
!!-------------------

snd_soc_skl_hda_dsp

snd_soc_skl_hda_dsp ALSAA module basically loads snd_sof_pci and that's why you don't have metallic audio...
Even if you launch alsamixer and press F6 you will see sof-hda-dsp and not HDA Intel PCH that those with metallic audio see.
You can easily get metallic audio by switching to a mainline kernel instead of ubuntu's.

[Mike (draamses)]

And to fix that metallic sound with the mainline kernel, you will probably need to perform steps 4 & 5 from my guide (https://forum.manjaro.org/t/guide-how-to-set-up-the-audio-card-in-samsung-galaxy-book/37090) and then reboot.

[Mike (draamses)]

Oh, one last thing, to hear the mettalic audio, simply launch a youtube video in Chrome (not Firefox)

[Kai-Heng Feng (kaihengfeng)]

Kailang, do you know how to power up the AMP?

[Kailiang Yang (kailang)]

I don't know.
This is none Realtek AMP.

[Kacper Michajłow (kasper93)]

I will ping you guys also here, since it seems to be more popular bug report. I've send a patch for speaker amp. You can find it here https://bugzilla.kernel.org/show_bug.cgi?id=207423#c40 and test if you'd like.

[Aurélien (titou829)]

Hi,

I have a Samsung galaxy book and encounter the same problem with my ALC298 sound card. I tried everything you did but it didn't work with mine. In fact I even cannot hear something with the earphones.
I also tried to check the verbs used under windows (throught qemu) and it seems they are quite different. Unfortunately even when i try to set these verbs it doesn't work...
I tried to send to you an email @gannon1 / @Mike pozulp but I'm not sure you received it.

If someone can help me trying to solve this problem it would be so good!
Thanks a lot

[PowerKiKi (adrien-crivelli)]

Aurélien, first thing to do is probably `sudo alsa-info --upload` to get and upload all your details. Then, we might compare it to mine: http://alsa-project.org/db/?f=f13c46c58bba7ed21035e65230899b18419cd337

[Duke Fong (duke-c)]

@PowerKiKi
The to912 script needs to be re-run after the audio sleeps. I have been running it manually for two years. Yesterday, I wrote a script that runs automatically after booting. It is much more convenient now. The script snippet:

LAST=0
while true; do
    #pacmd list-sink-inputs | grep -w state | grep -q RUNNING && CUR=1 || CUR=0
    cat /proc/asound/card0/pcm0p/sub0/status | grep -q RUNNING && CUR=1 || CUR=0

    sleep 1
    [ $LAST != $CUR ] && echo "audio state: $LAST -> $CUR @ $(date)"
    if [ $LAST == 0 ] && [ $CUR == 1 ]; then
        echo "run fix_audio ..."
        ./to912_fix_audio.sh &> /dev/null
    fi
    LAST=$CUR
done

[PowerKiKi (adrien-crivelli)]

Thanks for the news. I've been listening to a muted mp3 for two years now :-P

I am looking forward to Ubuntu 22.04 that should bring us the patched kernel we need...

[Aurélien (titou829)]

@PowerKiki

I'm really sorry for the delay. My computer crashed and I needed to repair it.. I just finished...
After a year I reinstalled the latest kernel but the problem seems to persist.
Here is the result of the alsa-info.sh:
http://alsa-project.org/db/?f=08a95ec89e5a0a02f38d7183cf9b2078fadff751

Do you have any clues?

[Drew R. (drew-rosoff)]

FYI - I have the NP950XEE (GalaxyBook2 Pro w/ Intel ARC graphics), have been struggling with the same problem and trying to fix for days now. I have perfect sound in headphones, no sound on speakers. I've implemented every fix discussed here, and haven't seen one single effect. I'm running 22.04. I tried upgrading kernels to 5.17 and 6.0 also, no effect. No matter what I try, headphones work, speakers not (and no metallic sound on headphones). Can anyone give any help/guidance, I'm stuck.

[PowerKiKi (adrien-crivelli)]

It's been a while. Since then I upgraded to Xubuntu 22.04 (not fresh install), and I am running kernel 5.15.0, which is supposed to contains my patch according to tags on https://github.com/torvalds/linux/commit/8bcea6cb2cbc1f749e574954569323dec5e2920e.

So I expect the issue to be solved, but unfortunately it is still not solved. I still use the manual script that runs a few hundreds `sudo hda-verb ...` to enable sound on my speakers.

I am afraid I cannot offer much guidance, neither to Aurélien, nor to Drew R. :-/

[Drew R. (drew-rosoff)]

Understood. I'd be super happy however if I could just get a manual script to work at least, and then I could call it a day...anything to just get any sound. But I've had no luck with that method, it seems to have no effect. (Assuming we are talking about the TO912.sh script. I tried to go down the whole road of setting up QEMU to record my own verbs, in case they're different, but couldn't get QEMU to compile. I have a windows partition, with latest drivers, and sound works in windows.

[jhubuntu20 (jhubuntu20)]

Hi Drew,

Since creating the TO912.sh script I have also upgraded to a GalaxyBook2 Pro (NP930XED) running 22.04 and the script was required (i.e. the latest kernels don't automatically fix issue), but the script continues to work fine for me on both headphones are speakers. Personally I would recommend upgrading from the 5.15 kernel because it doesn't work fully with the intel grpahics (im running 6.0.6-060006-generic now), but that is unrelated. Here are the full steps I did again that work for me ... I still have not figured out how to make the screen brightness control functional on the book 2 pro, but also a different story...

- placed TO912.sh script and set as 777 +x
- Create daemon for boot

  sudo gedit /etc/systemd/system/ionsound.service

                Add text in file
           [Unit]
           Description=Custom Sound

           [Service]
           Type=idle
          ExecStart={enter your path to script}/TO912.sh

          [Install]
           WantedBy=multi-user.target

  sudo chmod 664 /etc/systemd/system/ionsound.service

- Create daemon for sleep exit

  sudo gedit /etc/systemd/system/ionsoundsleep.service

                Add text in file
           [Unit]
           Description=Custom Sound Sleep Fix

           [Service]
           Type=idle
          ExecStart={enter your path to script}/TO912.sh

          [Install]
           WantedBy=suspend.target

  sudo chmod 664 /etc/systemd/system/ionsoundsleep.service

- Activate daemons

  sudo systemctl daemon-reload
  sudo systemctl enable ionsound.service
  sudo systemctl enable ionsoundsleep.service

Note, I left the names as Ion because I was too lazy to change, but nothing in here is ion specific and this does work on your model. You can change naming if you like as long as you change it everywhere...

For the kernel part, if you haven't already discovered the mainline tool for kernel mgmt then I would highly recommend trying it....

        sudo add-apt-repository ppa:cappelikan/ppa -y
 sudo apt install mainline -y
 Launch mainline GUI and pick kernel to install

[Drew R. (drew-rosoff)]

Hi jhubuntu20,

First, hopefully I can do you a solid and tell you how I fixed my brightness control at least (cause mine is a Galaxy Book2 Pro also, but with the ARC graphics).  What worked for me was:

    -Created /etc/modprobe.d/i915.conf with
        options i915 enable_dpcd_backlight=3
    - Regenerated the initramfs:
        sudo update-initramfs -u -k all

Hope that helps, unless you already tried.

On my side, I am running kernel 6.0.0-1006-oem (which I got from the linux-oem-22.04b package, as opposed to the mainline tool, which i may try though). I tried that in hopes it would help, in addition to many other things (disabling windows fast boot on my other drive, disabling secure boot and fast bios, setting probe_mask=1, iommu=off, and others).  Also tried playing with hdajackretask, because I'd be happy with retasking / giving up my working headphone jack for the speakers, but haven't figured that out.

Also, when I tried your TO912.sh script (the first thing I tried actually), I was doing it following the instructions  here -- https://forum.manjaro.org/t/howto-set-up-the-audio-card-in-samsung-galaxy-book/37090
This includes also blacklisting snd-hda-intel, removing alsa-conf, plus more.  Should I not be doing that?  (I've tried both ways though).

The problem is I just don't have the right mental model for what's going on, so trying everything too blindly... but I'm trying to understand more.  Most things have no effect (i.e., headphones work, speakers don't).  However, the one tweak that has made the most effect is:

    options snd-intel-dspcfg dsp_driver=##

    - When I set this to "3", or leave the setting out (i.e., as it was on fresh install), alsamixer shows "sof-hda-dsp" for "Card" and "Realtek ALC298" for "Chip".  When I use hdajackretask, it hangs completely when applying the retasking (and I've stopped pulseaudio, etc.), and the machine will hang on next shutdown.
    - But if I set it to "1", alsamixer then shows "HDA Intel PCH" for "Card", and still "Realtek..." for chip.  I can use hdajackretask without it hanging up.  And when I plug in headphones, I see a new "Headset or Headphone" GUI popup.  But my mic doesn't look like it's working. (Also, I need to not blacklist snd-hda-intel for this config to work, otherwise I only have "Dummy Output")

Do you happen to know which of those situations seems "more right"?  I fear that there's more than one problem going on at once, and I wonder which setting (3 vs 1) I should use as I experiment with the other possibilities (your script, etc.)

Lastly, I notice if I look in alsa-info, its reporting "line_outs=1", but "speaker_outs=0" in almost all configurations, and its not binding either line_out or speaker to anything in "/devices" (though it is binding the HDMIs, headphone, and sometimes the Mic).  I checked my older laptop, however, which has speaker sound, and it reports the same (though its running a 4.xx kernel and the ALC256).

I don't know if any of this gives any clues, and I apologize for my posts length and poor formatting.. I'm just trying to make sense of all this.

[jhubuntu20 (jhubuntu20)]

Thanks, I had tried a couple of things on the brightness, but it doesn't really bother me that much and I kind of forgot about it. I will try your approach.

So full disclaimer, I am usually an Angular architect and not a linux admin so try at your own risk, etc., etc., but here are my thoughts on your post... Back when I created the original script, the Ion and ubuntu 20.04 had several sound related issues. I had found fixes for the headphone jack and a few other issues initially, and then Mike Pozulp gave me a wonderful conceptual process and some key pointers for how to use qemu to get the verbs for the speakers. The process in that blog is the old, more complicated process. Fast forward to the galaxy book 2 and ubuntu 22.04, and on this laptop I didn't have to do most of the same steps because several of the issues were fixed in the base ubuntu version. So in general I would say you shouldn't need to do any of the hda retasking or alsmixer steps on your new laptop. In fact it was so easy on this laptop I didn't even install alsamixer or the other sound tools I had installed before to work on the ion. Here is the full entirety of everything I did on a fresh 22.04 install on the book 2 pro to get to working sound... perhaps one of these steps is the key...

1) Install pavucontrol. I don't think this was actually necessary, but I wanted the tool available just in case.

    sudo apt install pavucontrol

2) Install alsa-tools. This is absolutely required because it installs the hda verb utility. If you try to run the script without the verb tool then it won't work, but I would assume you would have seen the errors.

    sudo apt-get install alsa-tools

3) Kill the default alsa-base. Don't substitute or replace, just make sure this file is no longer present. I recommend rename instead of delete in case you ever want to back. This is likely the step your missing. Don't substitute a new file.

    Go into folder and just rename this file so it is not present

     /etc/modprobe.d/alsa-base.conf

4) Place the TO912.sh script and be sure to chmod the permissions to 777 and make it executable with +x

5) Create the two daemon files, making sure you did the chmod 664 step and making sure the paths to the TO912 script are updated.

6) Activate the daemons. be sure to do the reload before enabling.

    sudo systemctl daemon-reload
    sudo systemctl enable ionsound.service
    sudo systemctl enable ionsoundsleep.service

7) Turn off suspend on idle. This should not be needed to make it run, but keeps the change working through standby mode after it starts working

    sudo gedit /etc/pulse/default.pa
    Add comments to ### load-module module-suspend-on-idle

8) Reboot and verify

That's it, should be every thing you need to do from a fresh 22.04 to get full sound on headphones and speakers. I never actually tried running the TO script on this unit before doing these steps, so I can't say for sure if that works before removing alsa-base, but I have had to reload this laptop 3 times for other reasons and this process worked every time.

If it helps here is my output from sudo lspci -v | grep -i audio. you should seem someth...

[Drew R. (drew-rosoff)]

Ok... So, I had previously done those steps 1 through 8. On top of those however, since I had followed the instructions from that link (https://forum.manjaro.org/t/howto-set-up-the-audio-card-in-samsung-galaxy-book/37090), I had also added on top:
    options snd slots=snd_soc_skl_hda_dsp
    blacklist snd_hda_intel
as well as (for good measure, or in desperation rather):
    options snd-hda-intel model=alc298-samsung-headphone
    options snd-hda-intel model=alc298-spk-volume

So, I just removed those extras, to be sure I'm exactly as you. Also, to be sure the TO912.sh script is being called by those services, I put a 'touch' command at the end of the script, so it creates a file so I'm sure it ran. Still no go... but I am determined. I assume there is only one version of that TO912 script, right?

As far as your lspci output, thank you for that. It really helps to have something to compare it to.
My output was (changing the grep a little for more info):

     00:1f.3 Multimedia audio controller: Intel Corporation Alder Lake PCH-P High Definition Audio Controller (rev 01)
 Kernel driver in use: snd_hda_intel
 Kernel modules: snd_hda_intel, snd_sof_pci_intel_tgl

So that is different than yours, but that's when I had "dsp_driver=1". I took that option back out, to be 100% in line, and now it's the same as your output ("sof-audio-pci-intel-tgl"). (And, taking that dsp_driver=1 out also restores the microphone working) - But, still no go. This was all on kernel 6.0, but I also tried 5.17, same result (rebooting between all tests).

This is really strange, since we both have book2 pros. My only difference is the dedicated Arc graphics model (which I only got because I wanted 32gb ram). It comes with an HDMI port, does yours? (Part of me wonders if that plays a role in this).

In the beginning, I too went down the QEMU route. It seemed extreme, but hopefully full proof if I could get through it (since its gonna mimic whatever windows does). But, at least in the blog post I followed, it had me download a custom qemu build, which then wouldn't compile, and I got stuck in the rabbit hole of trying to figure out its compilation errors (maybe it was an old build).

[jhubuntu20 (jhubuntu20)]

That is odd. If its an option, you might consider a fresh install of 22.04 and then just the few steps. Its possible something else was changed or didn't reset fully as expected, but I know a full reload can be a ton of work and disruption. I don't know which script version they had in the blog, but attached is the very final one that I am using now that works. If you go the qemu route, I will warn you ahead of time it is not that simple even after you get the custom compile done because you have to catch the right sub part of the flow and it never seemed to be a single verb, only a combination in sequence that worked. i.e. even if you record all the verbs that make it work in windows then just playing them all back doesn't work because windows leaves it in an off condition and turns back on when needed. Anyway, it took a lot of trials to find a subset that worked consistently. Yes, mine has an hdmi, but just the intel graphics. Perhaps that could be involved, but I don't have access to the 15" laptop to try. Here is my output from pacmd list-cards. If there is any other output that would help you then let me know...

1 card(s) available.
    index: 0
 name: <alsa_card.pci-0000_00_1f.3-platform-skl_hda_dsp_generic>
 driver: <module-alsa-card.c>
 owner module: 21
 properties:
  alsa.card = "0"
  alsa.card_name = "sof-hda-dsp"
  alsa.long_card_name = "SAMSUNGELECTRONICSCO.LTD.-930XED-P07RGE-NP930XED_KB2US"
  alsa.driver_name = "snd_soc_skl_hda_dsp"
  device.bus_path = "pci-0000:00:1f.3-platform-skl_hda_dsp_generic"
  sysfs.path = "/devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0"
  device.bus = "pci"
  device.vendor.id = "8086"
  device.vendor.name = "Intel Corporation"
  device.product.id = "51c8"
  device.string = "0"
  device.description = "sof-hda-dsp"
  module-udev-detect.discovered = "1"
  device.icon_name = "audio-card-pci"
 profiles:
  HiFi: Play HiFi quality Music (priority 40768, available: unknown)
  off: Off (priority 0, available: unknown)
 active profile: <HiFi>
 sinks:
  alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_5__sink/#1: sof-hda-dsp HDMI / DisplayPort 3 Output
  alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_4__sink/#2: sof-hda-dsp HDMI / DisplayPort 2 Output
  alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_3__sink/#3: sof-hda-dsp HDMI / DisplayPort 1 Output
  alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp__sink/#4: sof-hda-dsp Speaker + Headphones
 sources:
  alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_5__sink.monitor/#1: Monitor of sof-hda-dsp HDMI / DisplayPort 3 Output
  alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_4__sink.monitor/#2: Monitor of sof-hda-dsp HDMI / DisplayPort 2 Output
  alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_3__sink.monitor/#3: Monitor of sof-hda-dsp HDMI / DisplayPort 1 Output
  alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp__sink.monitor/#4: Monitor of sof-hda-dsp Speaker + Headphones
  alsa_input.pci-0000_00_1f.3-platform-sk...

[jhubuntu20 (jhubuntu20)]

Latest TO912.sh

[Drew R. (drew-rosoff)]

Thank you for your latest script. I did a diff, crossing my fingers to find a difference, but it was only your commented out line starting pulse audio... so they're the same :/

And thanks for the pacmd output. At first when I compared yours and mine, they were the same... except my sinks, etc. were numbered starting at 0, while yours start at 1 (though the same devices were listed in the same order). But then in trying certain configurations, the outputs now show identical. (I am not positive, but I think it's when I went back to blacklisting snd-hda-intel for a moment that they became identical, so its possible that module just isn't loading for you, and maybe that's preferable).

I found the quirk 'alc298-samsung-amp' the other day, and also tried a lot of configurations with that (using "options snd-hda-intel model=alc298-samsung-amp"), but still no go. I was working on two theories: 1) There's some small difference that matters between your machine and mine, and trying to find it. Or alternatively, 2) There's no important difference between our machines, but because your machine reports as the "930XED", which is probably listed, while mine reports as the "950XEE", which probably isn't listed, there are just some quirks that are automatically getting activated for your machine but not for mine... So I was trying to find those quirks (I'd love if there was a way to 'spoof', and just make everything report that I had the "930XED" to see what happened, but don't know if thats possible).

I'm still collecting ideas, because I strangely refuse to give up. And I may start next down the whole qemu route. Two questions: 1) You say its fairly difficult, doing the subsetting during playback, cause it turns the card off shortly after turning it on... But you do hear sound at some point in the process, right? That's all I need to keep me going, just a little sound for a second ;). Also, 2) Do you happen to have a url of a good blogpost/set of instructions that you followed for that? I think the one I used pointed to an old version of the custom qemu to compile, because there were just way too many compilation problems. (I have my own windows partition, and I've downloaded the windows realtek driver, so I'd love to just use that, but I gather it has to be with a custom emulator to do the codec sniffing).

[jhubuntu20 (jhubuntu20)]

A few thoughts... Just based on my work before and the few people I helped later, in my experience Samsung reuses as much as possible in similar models and I don't think the laptops are that much different (if any) with regard to sound. So I don't think its option 1. Option 2 is a possibility and I would still consider a fresh install. I don't know about spoofing, but if you know the quirk you think is missing you can pretty easily just create a customized kernel that applies it. I did that originally on the Ion, again based on suggestions from Mike Polzup, before I actually went down the qemu path. It was needed back then just to get the headphones working on the Ion, but I believe that issue is now resolved in Ubunutu. Also, for what its worth, your brightness fix worked perfectly, so there is definitely some common aspects between these machines.

Its been a couple of years, but basically my qemu approach was
 -Install basic qemu
 -create a new windows virtual machine
 -Place a sound file on the desktop in the WM and ensure it played
 -Create the modified qemu version to get logging
 -Launch the previously verified VM
 -Play the sound, noting where in the log it was playing
 -Record the logging
 -Translate the verb formats
 -Play back sections to find some sort of sound
 -Reduce the verbs as much as possible after getting a section that made noise

I never needed to install the windows realtek driver as a separate step, the qemu vms always had working sound just with a default install of windows. It seemed like it would be easy once I got the modified qemu working, but it wasn't. Honestly if we hadn't been on covid lockdown I probably would have not had the time to finish it. I assumed, incorrectly, that if I just recorded the verbs during boot or the verbs up to the point where I heard sound on the VM it would be easy to just replay that bit and hear something, but that never really worked smoothly. I just assumed I did it wrong and it didn't work, but later in desperation I started just taking chunks and trying them and I happened to hit a working segment.
 I believe that was on Sept 12, thus the name of the script. I never really figured out why the bigger chunks didn't work.

Mike gave me the basic concept and pointed me at these two approaches for logging. He seems to have dropped away right after that, but his approach was absolutely correct. Because I didn't think it was working originally, I made both logging approaches work, but ultimately I used the bsd style approach for the final work because i found the output easier to work with as you can just copy and paste from stdout and the verbs needed less modification:

https://jcs.org/2018/11/12/vfio

https://github.com/Conmanx360/QemuHDADump/wiki/Setup-and-usage-of-the-program#start-of-content

If it helps, here are my very incomplete notes on making the modified qemu. I didn't write down what I changed in common.c, but I believe it was inline with the article...

Manual Install Qemu

 sudo apt-get build-dep qemu

 Download source https://www.qemu.org/download/#source
 tar -xvf {insert-qemu-version-here}.tar.xz
 go into folder

 modify common.c in hw/vfio (to o...

[Drew R. (drew-rosoff)]

1) I am so glad the brightness fix worked for you! At least I can feel like I've accomplished something ;)

2) Thanks so much for your detailed qemu information. I think I am going to tackle that next, and it should help (especially since compiling the pre-customized qemu was giving me trouble...your method sounds better, cause I can download what should be the latest qemu, and just patch it before compiling).

So, an update: A bit of very good news and very bad news. I was gearing up to do qemu last night, but decided to try "one last thing". I came across this post here:
    https://bugzilla.kernel.org/show_bug.cgi?id=216023

In it, someone else with a 950QED had done the whole Qemu thing, and came up with a different set of verbs. Very long (3500 verbs), not cut down very well. So I decided to try them. Boom, sound! Finally (It scared the hell out of me, after all this trying and failing). But: Sound in the left speaker, in the right speaker extremely loud static. Rebooted, same thing. Then, while the static was playing, I went to write myself a note about the results, and must have waited too long, because in the meantime, I smelled something very faint coming from the computer, then the static volume starts reducing slowly bit by bit to nothing. And from that point on, no sound in the right speaker in linux. In windows, even after shutdown, very faint volume from the right (It's almost like a blew an amp or something? ..maybe there is an amplified speaker that linux is calling, that's dead, and windows is calling the unamplified one, hence the quiet sound? ...but i don't know how this stuff works. Also, in certain configurations, I can in linux only get that loud static on the right to pop in for 1sec before going quiet again (by re-running the verbs)... so that cuts against the theory that I blew something, even though windows sound is still permanently affected, very weird)

So my computer is still within the return window for a few days, but I don't wanna get a new one and just repeat the same mistake. It's possible it's not that anything blew, but just i'm still missing some weird initialization/reset verbs or something? Hence why I think I will still see what happens on qemu, on a fresh windows install (and even better that you say it will use a different generic sound driver, so i can see what happens). This whole thing has made me realize, as I boot into linux/windows,reboot, etc., that the soundcard holds state between reboots much more than I ever thought possible I.e., once the verbs are sent, they don't need to be sent again unless I launch windows, or shutdown completely. And all this seems independent of whether I do those other steps (alsa.conf, etc.) or not, it just seems about getting those magic initialization verbs.

[jhubuntu20 (jhubuntu20)]

Yes, thank you for the brightness fix.

If it helps, I did remember the changes to make to the common.c file for logging. In that bsd article you can ignore most of the text, but somewhere in the middleish there is a hyper link that says something like my hack. If you click on it, it shows you in git hub the changes to make to common.c. Otherwise its just the instructions I sent.

Also, I could be wrong and its just my opinion, but I don't believe there is a verb that would burn out the amp and I believe it is one smart AKG amp for the entire laptop. You could easily have a bad speaker as its a new machine, but I doubt its from the verbs. Part of the struggle I had when finding the verbs was that some sequences would turn on just one speaker and sometimes the audio was garbled, so based on that experience, I would tend to believe you just don't have the right verb set. It was a challenge to get a small set of verbs that worked very consistently. If you are going to return the laptop anyway and have not tried it yet, I would also recommend just trying a completely fresh 22.04 install and the 8 steps we discussed above (with either set of verbs). I honestly think that might work and will be simpler than qemu.

[Drew R. (drew-rosoff)]

Great news!!! Got the new machine. Avoided booting into windows, ever, just in case. Executed your steps 1 through 8 (except for the default.pa part... I wasn't sure if that was crucial, and figured I'd save it until it seemed needed). Boot fresh machine, no sound. Apply the verbs - The other set, from that link I sent (the one that has 3600 verbs :/ ). Sound!!! On the left, good. On the right, about 10% quieter but well beyond good enough for me. (Other people using those verbs from that thread have noticed the slight volume difference as well... the verbs aren't perfect I guess). So I was very happy.

I shutdown. Verified no sound after startup. Ran the verbs again. Sound again, but this time right speaker is 50% quieter. So, I'm going to stop running the verbs, not install it as a service as I was about to, and only run it when needed (I shutdown my machine about once a year anyway, lol). Cause I think you are 100% right... It's all just about the verbs. My old machine probably didn't have a busted speaker, I had just ran so many different verbs through, and some had stuck, that the speaker was semi-permamently reduced. And its possible that these verbs from that link also aren't perfect, and are lowering the right volume a bit each time its run. It seems that some things aren't even reset on shutdown, while others are. People on that thread imply that after a day or so, things reset, but I can't imagine how that works or what its based on, but we'll see. So I'm going to leave well enough alone, for the time being, and hope that there's activity on that thread and they get the verbs better (cause yes, qemu seems to be a whole rabbit whole, so if someone else with a similar machine already has it all set up . . .).

[Aurélien (titou829)]

Hi all,

I finally got time to work on the soundcard of the Galaxy Book 12 (SM-W720). I finally found the solution in order to get it working under linux after a lot of work on the verbs I got from qemu two years ago.
I already can have sound from a script I'll send to you this weekend.
I'm also working on an ALSA patch.
Maybe it will work for you @drew-rosoff.

And since you spoke about brightness, please note that I worked on hardware brightness driver for the AMOLED display. It still have flickering problem on very low brightness state but it works pretty well.
For the moment the brightness is managed through a script which plays with /dev/drm_aux_dp device.
I'll try to develop a driver (but it's too dependant from the i915 driver and I don't want to integrate this code into the i915 driver..)

[Drew R. (drew-rosoff)]

@titou829 -

That would be great, thank you! As of now, I've used the script/verbs from this link (I think that's where I got them): https://github.com/thesofproject/linux/issues/4055 . And that managed to get my sound working, but with the right side at lower volume, and I believe ever lesser volume on the right each time I run the script. So therefore, in the meantime, I've just been afraid to shut off my computer lol, because I don't wanna have to run those verbs again and find out the hard way. So if you have a new set of verbs to send, that'd be great. I'm sure at some point, my computer will hard-crash, and I won't have a choice but to try something again.

[influenist (influenist)]

Hi All,

Running the xiaomi notebook x15 pro here. Which comes with 4 speakers. The front firing sound bad, like 25% and downward do not make any sound. Anyone can help me out where to start?

hdajackretask does not work / save upon reboot. Kinda struggeling with this one here...

http://alsa-project.org/db/?f=e4477f3727b1df458e1647d10a48cba2f94b2112

[Aurélien (titou829)]

Hi All,

I'm sorry i didn't found time to send my work but now it's done.
Please find the ALC298 python scripts and the brightness management of the Samsung galaxy book 12 on my github: https://github.com/Teetoow/SamsungGalaxyBook12

I'm not sure it will solve problem for other ALC298 soundcards but it works fine for me.

Sound difference between the windows driver and the linux one comes from software remixing (in particular to take into account the internal speaker response). You will find better results by using easyeffets.

I would be very interested in a solution to get this internal speaker response without costing materials, but i don't know how to do that.

The brightness has some flickering problems at low brightness. I'm not sure that it comes from the brightness management itself. I will check that in a near future.

[Marius Acniz (mayaru)]

Hi Eurelien,

any chance you might write a simplet step by step toturial how to apply your patch?
Thanks a lot.

Marius