How to configure ALSA on ASUS ROG G752

[segmentation-fault]

Let's make this the "ALSA on ASUS ROG G752 laptop" thread!

I will post my solution here, please post yours.

I've spent the past 2-3 days exclusively on the topic of configuring ALSA for my ASUS G752VY laptop - and it was not easy to find a somewhat satisfactory solution! User-friendliness looks otherwise. But I don't blame it on the ALSA developers - it is the manufacturers' fault: they don't communicate their 'jack settings' for each new laptop, as if it is some kind of state secret...

General idea

The idea of configuring ALSA on this laptop is basically this: do all what is said in the Gentoo ALSA Wiki and load the snd_hda_intel kernel module with the 'right' parameters. The whole problem lies in finding what 'right' means...


Configuration

Normally, all you would have to do to load snd_hda_intel kernel module with the 'right' parameters would be to choose the right 'model' among the following

Code: Select all

ALC66x/67x/892
==============
  mario			Chromebook mario model fixup
  asus-mode1		ASUS
  asus-mode2		ASUS
  asus-mode3		ASUS
  asus-mode4		ASUS
  asus-mode5		ASUS
  asus-mode6		ASUS
  asus-mode7		ASUS
  asus-mode8		ASUS
  inv-dmic		Inverted internal mic workaround
  dell-headset-multi	Headset jack, which can also be used as mic-in

found in

https://www.mjmwired.net/kernel/Documen ... Models.txt

For ASUS G752VY, what came closest to a correct configuration was 'asus-mode5', so, as a first try, put

Code: Select all

options snd-hda-intel enable=1 index=0 enable_msi=1 model=asus-mode5

in your

/etc/modprobe.d/alsa.conf

unload and reload snd_hda_intel (with rmmod and modprobe respectively), start alsamixer (not alsamixergui, as this might be confused by an installed pulseaudio package and you don't need to start pulseaudio for all this - in fact, it is better to kill any pulse* process, until you get this right first) in an X terminal, unmute (by pressing 'M') any controls that are muted and play around to see what works and what not.

For me, even with model=asus-mode5, the alsamixer controls were not assigned correctly. For example, the headphone control in alsamixer does nothing, a speaker control controls the headphone, another speaker control seems to control (both?) speakers (or was it just the right one?) - and so on.

Other 'modes' got it even worse: after trying ALL asus-modeX 'models' (X=1,...,8 ) from the above list, I found that NONE of them provided a perfect solution:

Code: Select all

# This enables the headphones - but the subwoofer seems to be dead....
# ...and the speakers in alsamixer are certainly not correct!
# options snd-hda-intel model=asus-mode5 enable=1 index=0 enable_msi=1
# This seems to enable the subwoofer - but headphones are dead...
options snd-hda-intel model=asus-mode6 enable=1 index=0 enable_msi=1

I had to dig deeper...

Here are some posts that show how deep you have to dig:

The first one gives a lot of details - but is for ASUS ROG 751, not 752:

Asus G751 external mic not working. External headphones not working

What do we learn from the above? That we have to put code like the one given in the last post in a file named asus-g751-hda.fw and saved in /lib/firmware, then pass it to snd_hda_intel with

Code: Select all

options snd-hda-intel patch=asus-g751-hda.fw

in our

/etc/modprobe.d/alsa.conf

BUT - there is a caveat: the options are for ASUS ROG G751 - not G752VY... Fortunately, there is another post, with options that should fit G752VY exactly - or so claims its poster:

Sound configuration on ASUS G752VT

Now, here we have a 'workable configuration' for G752VT (hopefully not different in audio from G752VY...). Putting all this together, I created

/lib/firmware/asus-g752vy-hda.fw

with the content:

Code: Select all

[codec]
0x10ec0668 0x10431ced 0

[pincfg]
#Pin 12 is Internal Mic
0x12 0x90a60160
#Pin 14 is Internal "front" speakers
0x14 0x90170110
#Pin 15 is "Line Out" according to the manual, But Pin 15 won't let me pick that in HDA Jack Retask.
#Trying to use this as an output will have a constant tone too.
#Using this as an output breaks the front speakers working correctly with headphone detection.
0x15 0x40f000f0
#Pin 16 is the headphone jack.
0x16 0x0321403f
#Pin 18 is the external Microphone jack.
0x18 0x03a19020
#Pin 19 is nothing.
0x19 0x411111f0
#Pin 1a is the internal subwoofer.  (Set the sound system to Stereo 2.1)
0x1a 0x90170151
#Pin 1b is nothing.
0x1b 0x411111f0
#Pin 1d is nothing.
0x1d 0x40c6852d
#Pin 1e is the internal SPDIF out.
0x1e 0x014b1180
#Pin 1f is nothing.
0x1f 0x411111f0

Note that '0x10ec0668 0x10431ced' in the above matches "'Vendor Id' 'Subsystem Id'" in the output of:

Code: Select all

cat /proc/asound/card0/codec#0 | grep Id

which (on my ASUS G752VY) is:

Code: Select all

AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0668
Subsystem Id: 0x10431ced
Revision Id: 0x100003

I unloaded/reloaded snd_hda_intel - and got:

Code: Select all

snd_hda_intel: unknown parameter 'patch' ignored

And what does this mean now?

After hours of searching, here is what it means:

When CONFIG_SND_HDA_PATCH_LOADER=y is set, you can pass a "patch" as a firmware file for modifying the HD-audio setup before initializing the codec. This can work basically like the reconfiguration via sysfs in the above, but it does it before the first codec configuration.

(from: https://01.org/linuxgraphics/gfx-docs/d ... notes.html)

Since I had

Code: Select all

grep CONFIG_SND_HDA_PATCH_LOADER /usr/src/linux/.config
# CONFIG_SND_HDA_PATCH_LOADER is not set

this means that I had to compile yet another kernel, this time with CONFIG_SND_HDA_PATCH_LOADER set.

Why doesn't the error above give a hint? It gives you an error message and, although the solution is clear, it does not give you the slightest hint as to what you might need to do...

Here are the full details:

Early Patching


When CONFIG_SND_HDA_PATCH_LOADER=y is set, you can pass a "patch" as a firmware file for modifying the HD-audio setup before initializing the codec. This can work basically like the reconfiguration via sysfs in the above, but it does it before the first codec configuration.

A patch file is a plain text file which looks like below:

Code: Select all

[codec]
0x12345678 0xabcd1234 2

[model]
auto

[pincfg]
0x12 0x411111f0

[verb]
0x20 0x500 0x03
0x20 0x400 0xff

[hint]
jack_detect = no

The file needs to have a line [codec]. The next line should contain three numbers indicating the codec vendor-id (0x12345678 in the example), the codec subsystem-id (0xabcd1234) and the address (2) of the codec. The rest patch entries are applied to this specified codec until another codec entry is given. Passing 0 or a negative number to the first or the second value will make the check of the corresponding field be skipped. It'll be useful for really broken devices that don't initialize SSID properly.

The [model] line allows to change the model name of the each codec. In the example above, it will be changed to model=auto. Note that this overrides the module option.

After the [pincfg] line, the contents are parsed as the initial default pin-configurations just like user_pin_configs sysfs above. The values can be shown in user_pin_configs sysfs file, too.

Similarly, the lines after [verb] are parsed as init_verbs sysfs entries, and the lines after [hint] are parsed as hints sysfs entries, respectively.

Another example to override the codec vendor id from 0x12345678 to 0xdeadbeef is like below:

Code: Select all

[codec]
0x12345678 0xabcd1234 2

[vendor_id]
0xdeadbeef

In the similar way, you can override the codec subsystem_id via [subsystem_id], the revision id via [revision_id] line. Also, the codec chip name can be rewritten via [chip_name] line.

Code: Select all

[codec]
0x12345678 0xabcd1234 2

[subsystem_id]
0xffff1111

[revision_id]
0x10

[chip_name]
My-own NEWS-0002

The hd-audio driver reads the file via request_firmware(). Thus, a patch file has to be located on the appropriate firmware path, typically, /lib/firmware. For example, when you pass the option patch=hda-init.fw, the file /lib/firmware/hda-init.fw must be present.

The patch module option is specific to each card instance, and you need to give one file name for each instance, separated by commas. For example, if you have two cards, one for an on-board analog and one for an HDMI video board, you may pass patch option like below:

Code: Select all

options snd-hda-intel patch=on-board-patch,hdmi-patch

(from: https://01.org/linuxgraphics/gfx-docs/d ... notes.html)

After recompiling the kernel with

Code: Select all

CONFIG_SND_HDA_PATCH_LOADER=y

I was able to use patch=... as an option to snd_hda_intel and load the 'firmware' file asus-g752vy-hda.fw from /lib/firmware, as above. Now alsamixer shows the right controls:

• Headphones work.
• Speakers work.
• Subwoofer works.
• Line-Out does not work (is it a Line-In perhaps?), but I can use the headphones jack as line-in to my external stereo set.

Therefore, for my use cases, all is well now...YMMV.

Enjoy!

[segmentation-fault]

To make mixing of various sources possible (i.e. to be able to listen both the sound of a film running in smplayer and the music of a track playing in audacious), I have the following in my etc/asound.conf file:

Code: Select all

pcm.!default {
	type plug
	slave.pcm "plug:dmixer"
}


pcm.dmixer {
	type dmix
	ipc_key 2048
	slave {
		pcm "hw:0,0"
		period_time 0
		period_size 4096
		buffer_size 16384 # 4096 if you encounter problems
		periods 128
		rate 44100
	}
# 	bindings {
# 		0 0
# 		1 1
# 	}
}

I found it in some old Linux magazine article. I commented the bindings part, as I was not sure what it does. This is the only code in the asound.conf file - there are certainly more elaborate examples, but it works for me (TM)...

[segmentation-fault]

Also, what I see now is that I have

Code: Select all

options snd-hda-intel enable=1 index=0 enable_msi=1 model=asus-mode5 patch=asus-g752vy-hda.fw

and not just

Code: Select all

options snd-hda-intel enable=1 index=0 enable_msi=1 patch=asus-g752vy-hda.fw

in my /etc/modprobe.d/alsa.conf.

Whether this makes a difference...frankly, after days of trying, I don't even dare to change it - and (at least for the moment) I don't care. Again, it works for me (TM)...

[segmentation-fault]

Although the above worked, there still remained a problem: no sound in browsers! I had video, but NO audio in youtube videos, for example. This was the case with all three:

• Firefox 60.4.0
• Seamonkey 2.49.9.1_p0
• Palemoon 28.4.0

NOTE: You can install Palemoon 28.4.0 on Gentoo by adding the palemoon overlay to layman and merging with the ebuild that then becomes available. All-in-all, you can do it with three commands:

Code: Select all

layman -a palemoon
eix-update
emerge www-client/palemoon

I configured S/PDIF as instructed in the Gentoo ALSA Wiki, so that my /etc/asound.conf now looks like this:

Code: Select all

# Enable S/PDIF on the Intel card.
pcm.!spdif {
	type hw
	# Card and device. From the 'aplay -L' output above:
	# 
	# iec958:CARD=PCH,DEV=0
	#     HDA Intel PCH, ALC668 Digital
	#     IEC958 (S/PDIF) Digital Audio Output
	# 
	card PCH
	device 0
}

# To talk to S/PDIF without remixing (i.e. directly and exclusively).
# 
# pcm.!default {
#      type plug
#      slave {
#            pcm "spdif"
#      }
# }


pcm.!default {
	type plug
	slave.pcm "plug:dmixer"
}


pcm.dmixer {
	type dmix
	ipc_key 2048
	slave {
		# pcm "hw:0,0"
		pcm "hw:PCH,0"
		period_time 0
		period_size 4096
		buffer_size 16384 # 4096 if you encounter problems
		periods 128
		# To output everything at 96kHz, use 'rate 96000'.
		rate 44100
	}
# 	bindings {
# 		0 0
# 		1 1
# 	}
}

...but still no joy with the browsers. After days of searching and reading, I came to the conclusion that, for the versions above (and those that will follow them in the future) Pulseaudio is a prerequisite sine-qua-non. That is, you must have Pulseaudio installed, configured and running, in order to have audio in these three Mozilla-based browsers.

I have decided to configure PA as a "minimal unintrusive dumb pipe to ALSA", as described in:

https://wiki.archlinux.org/index.php/Pu ... pe_to_ALSA

I have followed the instruction exactly - and all is good now, in the browsers and elsewhere. For the sake of completeness, here are the instructions, taken from the Arch Linux Wiki above (maybe they should be added to the Gentoo Wiki too...):

PulseAudio as a minimal unintrusive dumb pipe to ALSA

Some people do not want to run PulseAudio all the time for various reasons. This example will turn the full fledged audio server into an unobstrusive dumb pipe to ALSA devices that automatically starts and stops itself when done, allowing applications that requires PulseAudio to fully function while not touching any ALSA setting nor setting itself as the default ALSA device.

This configuration tells native PA clients to autospawn the daemon when they need it, then the daemon is configured to autoexit as soon as all clients have disconnected. The daemon itself uses a plain simple static configuration that uses your configured pcm.!default ALSA devices and nothing more. No replacement of ALSA's default, no playing with mixer levels, nothing but record/playback.
...
Also make sure common frameworks like Xine, Gstreamer and Phonon are configured to use ALSA: by default if they detect PulseAudio is installed they will try to use it before ALSA.

/etc/pulse/daemon.conf

Code: Select all

# Replace these with the proper values
exit-idle-time = 0 # Exit as soon as unneeded
flat-volumes = yes # Prevent messing with the master volume

/etc/pulse/client.conf

Code: Select all

# Replace these with the proper values

# Applications that uses PulseAudio *directly* will spawn it,
# use it, and pulse will exit itself when done because of the
# exit-idle-time setting in daemon.conf
autospawn = yes

/etc/pulse/default.pa

Code: Select all

# Replace the *entire* content of this file with these few lines and
# read the comments

.fail
    # Set tsched=0 here if you experience glitchy playback. This will
    # revert back to interrupt-based scheduling and should fix it.
    #
    # Replace the device= part if you want pulse to use a specific device
    # such as "dmix" and "dsnoop" so it doesn't lock an hw: device.
    
    # INPUT/RECORD
    load-module module-alsa-source device="default" tsched=1
    
    # OUTPUT/PLAYBACK
    load-module module-alsa-sink device="default" tsched=1 
    
    # Accept clients -- very important
    load-module module-native-protocol-unix

.nofail
.ifexists module-x11-publish.so
    # Publish to X11 so the clients know how to connect to Pulse. Will
    # clear itself on unload.
    load-module module-x11-publish
.endif

[ladmental]

Wanted to contribute to this topic with info about ASUS ROG GL703GE because at the first glance it might seem there is no fix as of right now. Given that I have not referenced any manufacturer manuals or similar sources, this suggests the below approach is going to help for ASUS laptops in general - perhaps even other ones. Worth mentioning that once sound started working, touchpad stopped being available and Applications => Settings => Mouse and Touchpad menu now has way less items on the list of devices available for configuration.

After several hours-long research on the Web, I appear to have resolved the problem. Long story short, the machine had to completely shut down and booted up again (note that when I was doing it, shutdown happened via entering UEFI firmware menu in GRUB - apparently this makes the laptop power off). This does not 100% correlate well with what segmentation-fault wrote above, so I am attaching some of my troubleshooting efforts and configuration excerpts from different files that seem to have contributed one way or another to the fix of this problem. More experienced Gentoo users potentially will facepalm themselves while reading through this because of unnecessary actions and bloat, but I am new to Gentoo and mostly had to semi-blindly follow other people's suggestions.

I am putting items below in a chronological order, but if you do not follow it that might be fine as well.
1. Kernel configuration.
See https://wiki.gentoo.org/wiki/ALSA and follow the suggested guidelines. Note that my kernel was built via

Code: Select all

genkernel -lvm -luks --no-zfs all

during installation, so many items in PCI sound devices and HD-Audio have M set and this cannot be changed to * or void.
2. Kernel modules. See segmentation-fault's note about CONFIG_SND_HDA_PATCH_LOADER.

Code: Select all

localhost /home/user # history | grep modprobe
  382  modprobe snd_hda_intel
  383  modprobe snd-hda-intel

3. Packages. At some point, "alsa" USE flag was added, but not all of them were compiled with it. Note that this step might be interchangeable with the next one - USE flags.

Code: Select all

user@localhost ~ $ qlist -IRv | grep pulse
media-sound/pulseaudio-13.0-r1::gentoo
xfce-extra/xfce4-pulseaudio-plugin-0.4.3-r1::gentoo
user@localhost ~ $ qlist -IRv | grep alsa
dev-python/pyalsa-1.1.6-r1::gentoo
media-libs/alsa-lib-1.2.4::gentoo
media-libs/alsa-topology-conf-1.2.4::gentoo
media-libs/alsa-ucm-conf-1.2.4::gentoo
media-plugins/alsa-plugins-1.2.2::gentoo
media-sound/alsa-tools-1.2.2-r1::gentoo
media-sound/alsa-utils-1.2.4::gentoo

4. USE flags. Do not forget to

Code: Select all

emerge --ask --changed-use --deep @world

as well once you have added the USE flag.

Code: Select all

user@localhost ~ $ cat /etc/portage/make.conf | grep USE
USE="alsa"

5. Available soundcards.

Code: Select all

localhost /home/user # lspci | grep -i audio
00:1f.3 Audio device: Intel Corporation Cannon Lake PCH cAVS (rev 10)

localhost /home/user # cat /proc/asound/cards
 0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xa4518000 irq 149

6. Output of amixer while headphones are connected.

Code: Select all

user@localhost ~ $ amixer
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 65536
  Mono:
  Front Left: Playback 19662 [30%] [on]
  Front Right: Playback 19662 [30%] [on]
Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch cswitch-joined
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 65536
  Front Left: Capture 3381 [5%] [off]
  Front Right: Capture 3381 [5%] [off]

user@localhost ~ $ amixer set Master unmute
user@localhost ~ $ amixer set Capture unmute

6. Alsasound configuration in OpenRC plus suggestion from another topic.

Code: Select all

emerge alsa-utils
rc-update add alsasound boot
rc-update add alsasound default
rc-service alsasound start

7. ALSA configuration in /etc/modprobe.d/alsa.conf file. [/b]Note[/b] that 1) rest of the file was left intact and 2) usage of asus-g73jw is intentional and not a typo, see last two comments in bug thread.

Code: Select all

# Set this to the correct number of cards.
options snd cards_limit=1
options snd-hda-intel id=PCH index=0
options snd_hda_intel id=PCH index=0
options snd-hda-intel index=0 model=headset-mode,asus-g73jw
options snd_hda_intel index=0 model=headset-mode,asus-g73jw
#options snd-hda-intel enable=1 index=0 enable_msi=1 model=asus-mode5
#options snd_hda_intel enable=1 index=0 enable_msi=1 model=asus-mode5

That is it. No other manipulations were made, not even the one with asus-g752vy-hda.fw file. /etc/asound.conf does not exist, neither does ~/.asoundconf nor /etc/alsa/conf.d/alsa-base.conf.

Also, might be useful to other people: what segmentation-fault showed earlier when configuring /lib/firmware/asus-g752vy-hda.fw is more or less the same across several ASUS ROG models (difference will be pin locations(?)), you can verify yourself by playing with hdajackretask and monitoring what output it has.