Created attachment 296229 [details]
alsa-info output from 5.8.0-44
Since i installed KUbuntu 20.10 i have an issue with the audio system. Basically, the volume doesn't work as intended.
However, testing more things i found the issue is more complicated. My laptop (Asus Zenbook UM431DA, ALC294 Analog) have 4 speakers: 2 in front (in both sides of the keyboard) and 2 in the back. When i change the volume, between 1% to 100%, the front speakers are affected by the volume but the back speakers aren't. Between 100% and 150%, both are affected. Also with the volume at 100%, the front speakers are low compared to the back ones, but maybe is how is intended, because with 100% volume it doesn't sound bad, it's only when is below 100%.
All this is using the audio manager in KUbuntu (it's how i see the difference between every speaker), but bypassing PulseAudio (using "pasuspender -- aplay -Dplughw:1 example.wav") and using alsamixer to change volume, the audio do the same (however i haven't could test above 100% volume), the front speakers are labeled as "Speaker" and the back speakers as "Bass Speakers", but "Bass Speakers" is only a switch, not a slider.
This is happening since i installed KUbuntu 20.10 (It also happens in that LiveUSB with 5.8.0-25 kernel, not only for Kubuntu, also with Ubuntu and LUbuntu) until 5.8.0-44 which is the most recent official ubuntu kernel. Also i tried newer kernels with Ubuntu Mainline Kernel Installer, being the last one tested 5.12.0-051200rc5, without any difference with any of them.
Also i have an issue (maybe related) with pulseaudio about how is recognize the speakers profiles at boot, which was making harder to gather info about this. I reported that in their site and i will post the link here to have both aware.
I provide alsa-info and dmesg from 5.8.0-44. Also have some from others kernel from mainline, included the last one mentioned (5.12.0-051200rc5) that i will add to this bug too.
PD.: This bug is reposted from https://bugzilla.kernel.org/show_bug.cgi?id=209053 because that bug had much info non related and became very convoluted.
Created attachment 296231 [details]
alsa-info output from 5.12.0-051200rc5
*** Bug 209053 has been marked as a duplicate of this bug. ***
The pulseaudio issue is posted here https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1922543 (i will elevate to the main pulseaudio but tracked if requested)
I own the same laptop.
Another issue present is the combo jack (headphones audio output, mini jack, 3.5mm) does not work with any microphone, only as audio output.
I have screenshots from the same model with an AMD3500U (instead of the 3700U that I own) with pin config from Windows:
Also, a couple more info:
$ sudo alsactl init
alsa-lib parser.c:260:(error_node) UCM is not supported for this HDA model (HD-Audio Generic at 0xfe7c8000 irq 74)
alsa-lib main.c:1014:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -6
Found hardware: "HDA-Intel" "ATI R6xx HDMI" "HDA:1002aa01,00aa0100,00100700" "0x1002" "0x15de"
Hardware is initialized using a generic method
alsa-lib parser.c:260:(error_node) UCM is not supported for this HDA model (HD-Audio Generic at 0xfe7c0000 irq 75)
alsa-lib main.c:1014:(snd_use_case_mgr_open) error: failed to import hw:1 use case configuration -6
Found hardware: "HDA-Intel" "Realtek ALC294" "HDA:10ec0294,10431b11,00100004" "0x1043" "0x1b11"
Hardware is initialized using a generic method
(In reply to Lukas ThyWalls from comment #3)
> The pulseaudio issue is posted here
> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1922543 (i will
> elevate to the main pulseaudio but tracked if requested)
The pulseaudio related issue (about speakers profile) is about pipewire, and it should be fixed in the next version. So, no connection with this.
(In reply to Ícar Nin Solana from comment #4)
> Another issue present is the combo jack (headphones audio output, mini jack,
> 3.5mm) does not work with any microphone, only as audio output.
I did a quick test for this and for me the laptop mic works, but with a headphone with a mic plugged in, it also use the laptop mic, no the headphone mic. I used the command "pasuspender -- arecord -f S16_LE -d 10 -r 44100 -c 2 -D hw:1,0 test.wav" to override pulseaudio in the test. The capture volume and mic boost seems to work fine.
Also i want to mention about the original report, with the headphones there is no issue with the volume in the audio output, it's only with the speakers.
Wanted to post here that I have possibly the same issue but on a different Asus model. I created a new bug for the time being, as the computer and soundcard model are different, but the bug behaviour seems to be the same.
This bug report from 2018 could be about the same issues as well: https://bugzilla.kernel.org/show_bug.cgi?id=198495
(In reply to Rafael Linnankoski from comment #6)
> Wanted to post here that I have possibly the same issue but on a different
> Asus model. I created a new bug for the time being, as the computer and
> soundcard model are different, but the bug behaviour seems to be the same.
Only to point this out, for me it's not only with the FN Keys, the full volume (between 100% and 1%) or muted (0%) is with everything: Fn keys, alsamixer, master volume control in kde mixer...
Created attachment 296607 [details]
Yes, good clarification. For me the behaviour is the same: not only with Fn
pe 30. huhtik. 2021 klo 13.00 firstname.lastname@example.org kirjoitti:
> --- Comment #8 from Lukas ThyWalls (email@example.com) ---
> (In reply to Rafael Linnankoski from comment #6)
> > Hello!
> > Wanted to post here that I have possibly the same issue but on a
> > Asus model. I created a new bug for the time being, as the computer and
> > soundcard model are different, but the bug behaviour seems to be the
> > https://bugzilla.kernel.org/show_bug.cgi?id=212641
> Only to point this out, for me it's not only with the FN Keys, the full
> (between 100% and 1%) or muted (0%) is with everything: Fn keys, alsamixer,
> master volume control in kde mixer...
> You may reply to this email to add a comment.
> You are receiving this mail because:
> You are on the CC list for the bug.
Can you help me try all the available potential fixes from https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sound/hd-audio/models.rst ?
Create a file for modprobe-ing, such as I have:
And then add inside:
options snd-hda-intel model=$MODEL
$MODEL being one of the options in the first link. Then reboot.
So far, I've tested:
with no luck. Please help me try all of them :-)
None of them have made any difference, i don't know if did something wrong (i created the "/etc/modprobe.d/audio-fixups.conf", adding and editing with "options snd-hda-intel model=headset-mic" and changing the option each time before a reboot and testing the volume and the recording with a headset with mic in one jack. I'm using 5.12.0-051200rc8-generic from Mainline Ubuntu Kernels, i don't know if i need to change anything more to test the options, or maybe there is an option which do something to know if changing is doing something.
If not, i have not had any luck, and the only option is to test one by one in the list (i am looking only the section "ALC22x/23x/25x/269/27x/28x/29x (and vendor-specific ALC3xxx models)" because the audio is ALC294) but all the others don't have a description what fits with the issues.
Also, i don't know if it should be useful to put the loaded module list:
$ lsmod | grep "snd"
snd_hda_codec_realtek 139264 1
snd_hda_codec_generic 86016 1 snd_hda_codec_realtek
ledtrig_audio 16384 1 snd_hda_codec_generic
snd_hda_codec_hdmi 65536 1
snd_hda_intel 53248 4
snd_intel_dspcfg 28672 1 snd_hda_intel
snd_intel_sdw_acpi 20480 1 snd_intel_dspcfg
snd_hda_codec 147456 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
snd_hda_core 94208 5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realt
snd_hwdep 16384 1 snd_hda_codec
snd_pcm 118784 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
snd_seq_midi 20480 0
snd_seq_midi_event 16384 1 snd_seq_midi
snd_rawmidi 36864 1 snd_seq_midi
snd_seq 73728 2 snd_seq_midi,snd_seq_midi_event
snd_seq_device 16384 3 snd_seq,snd_seq_midi,snd_rawmidi
snd_timer 40960 2 snd_seq,snd_pcm
snd 94208 19 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel
snd_rn_pci_acp3x 20480 0
snd_pci_acp3x 20480 0
soundcore 16384 1 snd
Tested again with 5.13.0-051300rc4, this time in KUbuntu 21.04, no changes.
Also i tried the modprobe options:
And still i didn't find any difference with the default behaviour, wondering if i'm doing something or not.
Testing the options i also found with the headphones, the volume is not linear: With 15% the sound is almost imperceptible, with 20% you can barely hear it, but between 20% and 50% the volume grows to normal and before that the volume seems fine. But that first 15%-20% doesn't fit the same rise effect than the rest.
It's not a big issue (the main one is the not volume control in the built-in speakers), but shows it's something there.
Note that the machine has two HD-audio controllers, and the first one is only for AMD HDMI, while the second one is for Realtek. When you pass model option, you'd have to pass to the second entry, e.g.
(see the comma after the equal sign).
Thank you for the additional info, Takashi.
With that I tested some of the model options that had already been tried earlier in this thread, but with the comma added in order to target the second entry. (As an aside, for me the first option seems to be Intel Kabylake HDMI, not AMD HDMI, but I might have misunderstood what was being referred to here.)
Please note that my laptop is different from the one in this bug report (my device is Asus UX550VE & Realtek ALC295). However, based on the description of the bug behaviour, it seems like the same issue.
Default behaviour before commencing testing: changing the volume affects the sound only partly. As master volume goes up, it changes the sound like it's coming more from the center (higher frequencies); the affected channel seems to be the one labeled "Bass Speaker" and probably the two "extra" speakers, which are out the ordinary in this configuration. The channel labeled PCM is not affected by master volume control (except for when master volume goes to zero/muted, which is when PCM is also muted).
The alsa-info of the default situation (no options added to conf) can be viewed here: http://alsa-project.org/db/?f=6f037b91baf26bb0822f193ffc8998298c241d93
Tested options below (edited these directly into /etc/modprobe.d/alsa-base.conf). Rebooted after editing and confirmed by running alsa-info that the option from the alsa-base.conf was registered. Result as a comment after each line.
I tested only the speakers and their volume control, not with headphones or mic input/recording.
options snd-hda-intel model=,asus-zenbook // no effect
options snd-hda-intel model=,asus-zenbook-ux31a // no effect
options snd-hda-intel model=,headset-mic // no effect
options snd-hda-intel model=,alc294-lenovo-mic // no effect
options snd-hda-intel model=,dell-headset-multi // no effect
It seems this person was able to create a workaround for (probably) the same problem here: https://bugzilla.kernel.org/show_bug.cgi?id=198495
However, my skills/knowhow weren't up to the level to properly follow through on what that person had implemented for themselves. Anyone want to help trying to test this possible solution?
From what I understood, first some pin configurations need to be changed, then apply the hda-verbs. And finally, to persist the solution, add it to systemd. What I'm above all else unsure about is, if the pin config and hda-verb assignments are the same (i.e. can they simply be copied), and how to find out what they should be.
I was also testing the models in my laptop, thanks Takashi to point that out and take us to the right path.
I want also to focus this bug about the volume issue as i think it has more priority as it is more annoying. I'm testing too the mic thing but i will post the results of the Icar's original report https://bugzilla.kernel.org/show_bug.cgi?id=209921 as his laptop is the same as mine. I found also other report similar about the mic https://bugzilla.kernel.org/show_bug.cgi?id=201419 and other one reporting a similar issue with the volume in another ASUS Zenbook laptop with harman/kardon https://bugzilla.kernel.org/show_bug.cgi?id=203909.
Now with Takashi tip, the model option made some changes. I tested by far: asus-zenbook, asus-zenbook-ux31a, headset-mic, headset-mode, asus-g73jw, asus-x101, dell-headset-mic, alc283-sense-combo, alc294-lenovo-mic with no difference with the volume issue, except alc298-spk-volume, which disable the back speakers making the overall volume low for 100% as the sound only come from the front ones, so it's not a fix.
Like Rafael is saying the point here is the back speakers aren't affected with the volume, and, as like i said above, in alsamixer the bass/back speakers is only a switch, not a slider (and being a switch or a slider, those speakers should be affected by the master volume and they are not).
I will take a look at that workaround but i don't know if with my knowledge i can test it.
Also, i will update the alsa-info data if it could be useful (without any model option).
Created attachment 297475 [details]
alsa-info output from 5.13.0-rc4 (no model option set)
OK, then I guess there is no perfect solution for the bass volume problem.
The machine has three DACs, 0x02, 0x03 and 0x06. The first two DACs have the amp volume control while the last one has no volume control. And, since the machine has three outputs (front speaker pin 0x14, bass speaker pin 0x17 and headphone pin 0x21), and the connectivity is limited (e.g. headphone is connected only to either 0x02 or 0x03), the driver assigns the last 0x06 to the bass speaker in the end, which results in the lack of the volume control.
We may hook both pins 0x14 and 0x17 for front and bass speakers to share the same source DAC 0x02, which might be a bit better than the current situation (where bass has no volume control at all), but a single volume is tied for both speakers. This might work, but sometimes causes a problem if a vendor-specific thing is implemented there like the low-pass filter.
Created attachment 297479 [details]
Thank you, Takashi! That sounds like a good-enough approach.
I noticed you already created a test patch. I'm not sure how to test that, though, since I'm quite new to this level of troubleshooting (please forgive my ignorance)... Is my assumption correct that it requires building the kernel with the attached patch?
If yes, I can probably figure it out by myself, but would just need confirmation on how to proceed. :)
I am compiling the kernel 5.12.6 witb the attached patch. I'll report after the testing.
It does WORK!!!
What I tested:
- no audio devices plugged in: volume control works, internal mic works.
- mini jack headset with mic + audio: works (everything through mini jack).
- mini jack headphones (no mic through mini jack): works (audio through mini jack) and mic (through internal).
OK, I'm going to submit the patch to upstream and merge it for 5.14.
It'll be then backported to older stable kernels later on.
I also tested the patch (with 5.13.0-rc6) and the four speakers are now affected by the volume control.
The combo jack also works as it should, a now the sensor works.
I want to ask something about that: doing tests with models, i found using "dell-headset-multi" in this laptop didn't fix the volume thing, but could use the mic headset if you select it manually, because it change from speakers to headphone but not from internal mic to headset mic (As i explained here https://bugzilla.kernel.org/show_bug.cgi?id=209921#c3).
The question is that selection, for me (KUbuntu) when i plug the headphones with mic, in the Volume Control appears icons that shows menu, in both Speakers/Headphone and Internal Mic/Mic/Headset Mic (Yes, appears three, Mic records nothing). What make those menu appears? With this fix they didn't appear, but for sure can be done in this laptop because with "dell-headset-multi" model option they appear. Could it be done? Because i see that useful.
For me the patch doesn't seem to be working. I've tested building several different kernel versions with the patch applied (tested both mainline and Ubuntu versions) and the fix unfortunately doesn't seem to work for me.
Not 100% sure, if it's because of some mistake I made in building the kernel from source, or if it's because of slightly different hardware (ALC295 instead of ALC294). Funnily enough, on the mainline 5.12.13 (which was the stable at the time of testing) also my touchpad stopped working, so went back to 5.11.12, which has only this volume control issue.
A question: with a kernel that has the patch applied, do you still see the channels the same way in alsamixer (bass speaker + PCM) as before, or did the patch also fix the labeling?
Takashi, should the patch you attached work also for ALC295 on my hardware?
Details of my hardware can be found here: https://bugzilla.kernel.org/show_bug.cgi?id=212641
Any help is highly appreciated!:)
Tested with 5.14.0-rc4 from mainline and it's working for me with the OP setup (Asus Zenbook 14 UM431D, ALC294 Analog). It can be put as resolved if no one have a problem with that.
(In reply to Rafael Linnankoski from comment #24)
> A question: with a kernel that has the patch applied, do you still see the
> channels the same way in alsamixer (bass speaker + PCM) as before, or did
> the patch also fix the labeling?
For me, instead of the behaviour before noted, in alsamixer now the "Speaker" slider controls all four speakers. "Bass speakers" is still a switch (mute or unmute). And if they are muted anyone of both, there is no sound, so they have to be unmuted to work.
Thank you for your reply and information provided, Lukas! And sorry for the late reply. :)
I'm fine with marking this bug resolved, as it seems to have fixed the issue on the hardware detailed in the OP.
Still hoping the same issue with slightly different hardware would also get some love: https://bugzilla.kernel.org/show_bug.cgi?id=212641
(In reply to Rafael Linnankoski from comment #26)
> Still hoping the same issue with slightly different hardware would also get
> some love: https://bugzilla.kernel.org/show_bug.cgi?id=212641