[Armbian build PR] - armbian-audio-config: Fix muting and controls with spaces

[RSS Bot]

Description

In commit 0aa61abe7 (armbian-audio-config: Massively speed up script) this script was changed to not call amixer for each control, but just once for each card, feeding commands for many controls in one invocation with the --stdin option.

In that commit, two errors were introduced:

• Controls that were intended to be muted were turned on instead. This affects the "CD", "Mic" and "Internal Speaker" controls.

  This occured because there is a helper shell function whose arguments were renumbered, but the last argument kept the old numbering, keeping it always at the default value of "on", even when it should have been "mute".

• Controls with a space in their name would be ignored. In the original script, arguments (including these names) were quoted and passed separately to the amixer command. Now, they are quoted when passed to echo, but that produces an unstructured line with the quoting removed that can no longer be correctly parsed by amixer for names with spaces.

This commit fixes both problems be correctly numbering the arguments and adding an additional layer of quoting.

How Has This Been Tested?

On an Orange PI PC change some controls with alsamixer, run the script and verify the controls are correct. In particular, I changed the "Line Out" control to verify spaces now work and changed the "Mic1" control to verify muting works (with a small manual changes to the script, since it normally only mutes "Mic", not "Mic1".

Additionaly, run systemctl mask alsa-restore.service (to work around another issue, see below) and restart the system, see that these controls have the right value again directly after bootup.

Note that I've tested this with a slightly older and customized 23.02 version, I haven't gotten time yet to test with a clean master build, but the script itself is still the same, so the change should work the same there.

Issue with alsa-restore

I did run into an unrelated issue: On my customized image (but I suspect a clean master will behave the same), alsa-restore.service overwrites the settings set by armbian-audio-config. I believe this issue is orthogonal to the issues fixed by this PR and probably deserves its own issue after I verify it also occurs on a clean master build. However, it does mean that the fixes made by this PR might not be directly visible (which is why I tested with alsa-restore.service masked), so I wanted to mention this here.

Then, for some additional detail (to be moved to a separate issue later - just want to share this somewhere for now). The alsa-restore service might make sense once a system is in normal use (alsa-restore saves the mixer settings at shutdown and restores them on startup), but maybe armbian-audio-config would still want to supply the initial values for that process. What I've seen is that during image generation, a /var/lib/alsa/asound.state file is generated (presumably with mixer settings from the build system?), which is then restored on the first boot, overwriting some or maybe all of the settings from armbian-audio-config.

I tried removing the /var/lib/alsa/asound.state file so armbian-audio-config could maybe define the intitial settings, but it seems that it then still sets default settings (the manpage says:

restore loads driver state for the selected soundcard from the configuration file. If restoring fails (eventually partly), the init action is called.

The default settings used by alsactl seem to be set by config files, see the alsactl_init manpage.

I wonder if maybe this means that armbian-audio-config is actually redundant, and its function could be fulfilled by alsactl restore/init as well (though maybe the supplied init configs must be modified to achieve the same thing the script currently does)? One thought is that the script might be useful for systems that do not have the alsa-restore service or alsactl installed, but these come from the same package as the amixer command used by armbian-audio-config, so that's not a viable case either.

Checklist:

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas N/A
• [ ] I have made corresponding changes to the documentation N/A
• [ ] My changes generate no new warnings N/A
• [ ] Any dependent changes have been merged and published in downstream modules N/A

View the full article