[gentoo-user] asound.state bug? Can anyone else reproduce this, please?

[Stroller]

Can anyone reproduce this, please?

The following steps conclude with a reboot:

1) `aplay -vv SomeFile.wav` - listen to some banging new tunes and satisfy yourself that your speakers and ears are working. Skip this step if you're already satisfied that your speakers are audible and that sound issues from them ok. 

2) Backup current alsa state - `/etc/init.d/alsasound save && cp /var/lib/alsa/asound.state ~/asound.state.bu`

3) Stop /etc/init.d/alsasound and remove it from the default run-level - `/etc/init.d/alsasound stop && rc-update del alsasound default`

4) Sound is still working, right? Now open `alsamixer` and mute it; ideal is to mute all channels thoroughly (use the left and right arrow keys to navigate channels, the M key to mute, the escape key to exit).

5) Run `/etc/init.d/alsasound save`

6) Reboot the system.

Afte the reboot, is the sound muted, please? 

Here it is, and I don't think it should be, because I think that should be restored by the /etc/init.d/alsasound script, which has a RESTORE_ON_START option in its conf.d file and which was removed from the default runlevel in step (3). We can establish that it's not running with `/etc/init.d/alsasound status`

I'm also seeing that maybe alsa's default state is muted, so that the muted state would be correct even if the sound state is not being restored. That's fine - restore the previous backup of sound from when audio was playing (`cp ~/asound.state.bu /var/lib/alsa/asound.state`) and reboot the system. Now the unmuted state is restored and you can listen to your music without starting /etc/init.d/alsasound.

I'm happy to elaborate on the little more I know about this stuff, if there's someone who can tell me that yes, they're seeing this, too, and yes, this is *not* the expected behaviour. Right now I'm still wondering if I'm doing something wrong.

This system is ~amd64, baselayout 2.1.

Stroller.