alsa-utils: restore default card state handling

[dpapavas]

This is a first iteration of the PR regarding ALSA card state handling discussed here. The preexisting behavior, was to either restore a custom, ad-hoc state to each sound card, as it was loaded, or to restore a state saved by the user, if one existed.

The latter functionality did not work (at least not reliably; see forum thread for details) and, given the nature of the issue (briefly the udev rule runs the soundconfig script which then forks a background shell to do its work, but according to udev's manpage, any such background processes are killed once the main action finishes, so that the background shell is killed after doing whatever it managed to do, until the main script finished, which happens immediately), thefore I assume that the card resetting part of soundconfig, i.e. what it tries to do if no saved state file exists, probably doesn't work correctly either.

This PR restores the default functionality shipped with alsa-libs. Briefly this uses the alsa-restore systemd service to save the state on shutdown and restores it on next boot. The effect therefore is that the state is retained across boots. The user is then responsible for setting the mixer to the desired values, which are then retained.

This behavior works well on my setup and use-case. Nevertheless, assuming the existing functionality did work, to some extent at least and further assuming that the ad-hoc state set by the soundconfig script was in fact necessary in certain cases (where presumably the dafault state restored by ALSA on first encounter of the card, i.e. when no previously saved state exists, was not "correct" in some way), such cases may need to be fixed.

The PR is created against the 11.0 branch, as that is what I'm using. It can be rebased to other branches as needed.

[heitbaum]

Hi @dpapavas - can you please rebase this against :master as the update will be to master.

[dpapavas]

Done. Note that I haven't tried a build of this, as I'm currently using LE 11 on my device, but I don't see why it would work any differently than the version I've tried. If required, I can try to build and install it on a separate card, in order to try it out.

[chewitt]

If we embed alsamixer by default there also needs to be a change to remove it from the "Multimedia Tools" add-on.

[dpapavas]

Sorry, I forgot I had skipped removal of some utilities etc. Regarding alsamixer, I restored it, because I found it useful and, having no idea that it was available via multimedia tools, had resorted to using amixer, which is cumbersome. We can remove it again, but it is a basic tool for setting up the sound card that I imagine many users might need to use and think is not available. Again, it depends on how important minimization of used space on the device is.

[chewitt]

it depends on how important minimization of used space on the device is.

LE/OE has managed without alsamixer for 12+ years so I think we can safely continue without it; we do strive to minimise the growth of images and it's available from the tools add-on should people really need it.

[HiassofT]

Some general comments:

When I sait the sound configuration should be redone in the forum I didn't mean to nuke everything and completely switch over to alsa state handling etc, but to try to move away from soundconfig, where possible, and let alsactl restore/init and ucm handle that.

In particular: we will have soundcards that can't be initialized by alsactl / UCM yet and for those we need to maintain a way to manually configure them. One such example is the Cirrus Logic Audio Card on RPi, the routing capabilities are far too complex to be mapped to UCM - see it's config scripts and (to-be-rewritten) udev initialization here https://github.com/LibreELEC/LibreELEC.tv/tree/master/packages/audio/rpi-cirrus-config

This can be easily done with udev, order the soundcard specific rules before 90-alsa-restore, let them set a marker property (eg ENV{.le_soundcard_initialized}=1 and then perform restore/init in 90-alsa-restore only if the marker isn't set. This means we should not ship alsa's default udev rules but we have to use our own.

We also don't need the alsa state daemon and I think it's better to not install the alsa systemd service to automatically store the current settings on shutdown/reboot as well. This is something users can manually do if they really want to make their configuration persistent.

[dpapavas]

The desired direction was described in the forum as "completely nuking [the whole soundcard/soundconfig handling] and replacing it with the current ALSA default config/state handling", but from what I see I have misunderstood and this is neither feasible, nor desirable.

As far as I can see from the various comments, the current setup seems to suit us mostly fine. I understand there may be issues with some cards, but I cannot submit PRs for those, since I do not have the hardware in question. What I could do instead, is convert this PR to a simple change that would fix the current setup in the following respects:

• Fix the soundconfig script, by removing the & backgrounding the subshell, since that doesn't work.
• Fix the issues in the udev rule described in the forum thread (i.e. that invalid NAME action, adding perhaps SUBSYTEM="sound", etc.)

How does that sound?