After one of recent updates, unfortunately, I didn’t notice it right away and can’t say which one exactly, volume controls stopped working on my ASUS Zephyrus G14, but only for speakers, headphones work fine. The volume seems to be stuck at maximum. The problem with speakers is explicitly mentioned on Arch wiki’s ASUS GA401 page (sorry, it seems like i’m not allowed to post links here) , but the patch suggested there doesn’t seem to do anything.
The laptop has tweeters and woofers. The problem is that by default the volume controls will adjust the volume of the tweeters but not the woofers. This causing the sound to get “muddier” but not quieter at lower volumes.
The solution proposed here enables control of the woofers, but also completely disables the tweeters. this causes you to lose lots of detail in the sound, which is a shame because the speakers on this device are pretty nice!
You can verify this by playing a high pitched sound (search youtube for 15khz), and checking if sound comes out of the tweeters (located under the two small grilles on the palm rest).
I’ve been hunting around for a solution for a couple days now without much luck. I’m running Ubuntu rather manjaro, but I have tried similar fixes for PopOS and arch with the same unsatisfactory results.
The tone is still audible with only the woofers working, but much quieter.
Since my last reply I’ve also found accounts suggesting that the update to 13.99.1 a few months ago might have caused this issue, so backdating may also help in my case.
Either way, thanks for the replies and helping me narrow in on a solution!
Hmm. I’m not sure about tweeters, but there’s definitely a problem of different sort: volume controls work only until the system is rebooted. After a reboot volume controls don’t function at first and only start working after pulseaudio -k and up again.
[x@y ~]$ systemctl --user -l --no-pager status pulseaudio*
● pulseaudio.socket - Sound System
Loaded: loaded (/usr/lib/systemd/user/pulseaudio.socket; enabled; vendor preset: enabled)
Active: active (running) since Sat 2020-12-05 12:29:18 MSK; 18min ago
Triggers: ● pulseaudio.service
Listen: /run/user/1000/pulse/native (Stream)
Dec 05 12:29:18 y systemd: Listening on Sound System.
● pulseaudio.service - Sound Service
Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; vendor preset: enabled)
Active: active (running) since Sat 2020-12-05 12:29:19 MSK; 18min ago
TriggeredBy: ● pulseaudio.socket
Main PID: 1477 (pulseaudio)
├─1477 /usr/bin/pulseaudio --daemonize=no --log-target=journal
Dec 05 12:29:18 y systemd: Starting Sound Service...
Dec 05 12:29:19 y systemd: Started Sound Service.
Dec 05 12:44:23 y pulseaudio: ALSA woke us up to write new data to the device, but there was actually nothing to write.
Dec 05 12:44:23 y pulseaudio: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
Dec 05 12:44:23 y pulseaudio: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
systemctl --user restart pulseaudio ultimately has the same effect as pulseaudio -k, i. e. volume controls start working. systemctl --user -l --no-pager status pulseaudio* output afterwards is the same