Let me start by saying that Manjaro with KDE Plasma is absolutely beautiful and a true work of art. Thank you for all the work that went into it - it shows.
Because of this, I’ve chosen it (after reviewing several Linux distros) to run on the Lenovo N23 Chromebooks we use at the school where I manage IT.
Said Chromebooks have hit their AUE and need to transition to something other than ChromeOS.
After searching around, I found your distro and it seems perfect: it stays within the 16GB hard drive limit, works reasonably quick, is easy to use thanks to it looking like Windows (but better), and ALMOST supports the hardware.
That brings me to the subject of this post.
EVERY Linux distro I’ve tried (and there have been many) fails to work with the microphone on the Lenovo N23 hardware. Manjaro also doesn’t work.
Now, if the language students at the school didn’t need the mic in order to speak back to their virtual Spanish teacher, I’d call it a day and live with no mic, but this is just not an option; the mic MUST work.
And I got it working…KIND OF…I just need someone to get me over one last hump.
Here’s where I am.
I read a post on another help site where someone said to export the “asound.state” file from ChromeOS, and then import it to the Linux distro where the mic is broken. Incidentally, this also fixes sound output issues on some systems, but on Manjaro the sound output works perfectly for me, I just need the mic working.
Well, using the “alsactl” command from a Terminal, I imported (alsactl restore -f asound.state) the ChromeOS sound state file and…viola…the microphone works!
Doing a quick diff between the default file and the one I imported it looks like certain volume/gain settings need to be somewhat nonstandard values in order for the mic to work (that’s my guess anyway).
But here’s the problem: log off and the imported settings go away!
And the next problem: any attempt I’ve made to execute the import command via startup script doesn’t work either.
It’s like the system changes the sound state AFTER all my automatic scripting attempts to correct it and by the time the user desktop springs to life, the broken mic settings are the ones active.
Is there any way to make the state changes absolutely permanent and/or default? I don’t know how.
Or if there’s no way to do that, how can I make sure my script to import the correct sound state runs at the right time.
I hope one of these options is feasible, preferably the first, as it’s cleaner.
Here’s where I drop it in the lap of those reading.
Thanks.
Hello and welcome!
Can you tell what you tried exactly?
Have you tried to create a file in ~/.config/autostart/ which would execute the command
alsactl restore -f /home/username/asound.state
Yes
I created a fix_sound script in my home directory and chmod-ed it to +x.
Running it in Terminal after login works.
Running it via autostart does not.
It’s timing.
So, I created a really, really ugly hack that fixes the early run timing via this diff
old
#!/bin/bash
alsactl restore -f ~/asound.state
new
#!/bin/bash
secs=${1:-10}
(sleep $secs ; alsactl restore -f ~/asound.state) &
I absolutely hate this, but it works.
It would be better to have my fix_sound script run via some method that fires at the proper time without using a sleep interval. Also, this is a per user fix, so that’s another weakness/complication.
The right solution is to fix the incorrect values in whatever base configuration file the sound system is using with the correct ones that are found in the ChromeOS sound state file.
The number of people who know how to do that is probably very small, and the number of those who may read this is even smaller, with the number of those who take pity on me and actually respond probably being 0; so I guess my hack will have to do.
It may be possible to reduce or remove the sleep delay from workaround script by disabling the systemd service that restores ALSA settings from /var/asound.state when system boots
systemctl mask alsa-restore.service
The optimal solution for this audio issue would be to get ALSA developers to create a patch in the kernel
I suggest:
-
Open a bug report at https://bugzilla.kernel.org in Sound(ALSA) category
-
Include audio codec (ALC269VC) and system model name (Lenovo N23) in report title and write a brief description based on comments in post #1
-
Attach a full ALSA diagnostic
sudo alsa-info.sh --stdout >> alsa-info.txt -
Attach alsactl settings files for non-working
/var/asound.state/var/lib/alsa/asound.state and working `~/asound.state’
Thank you very much for this useful information.
I will definitely file a bug report as per your instructions; hopefully it will aid many others, should a fix come out of it.
Now, a follow-up question regarding what you’ve said about systemd.
Why not just NOT disable that service, because it’s doing the very thing I want to happen - except it’s using the wrong settings; so if I can make the service use the correct settings, then my problem would be solved, wouldn’t it? Given that the service is restoring the settings from the /var/asound.state file (your statement), all I should need to do is replace that file with my working one, right?
The file path was incorrect in my last comment. alsactl manpage has the correct information
-f, --file
Select the configuration file to use. The default is /var/lib/alsa/asound.state.
all I should need to do is replace that file with my working one, right?
I assumed that since you had tried other distributions that you would have been suggested to try using alsactl commands init, store and restore with default asound .state file before using file from user home folder
If audio is working on system after restoring settings from ~/asound.state, settings should be saved with this command
sudo alsactl store
or this
sudo cp ~/asound.state /var/lib/alsa/asound.state
If either of those work you can cancel the bugzilla report