Sorry, i forgot summary. "Sound muted after bootup" should be ok.

I confirm this bug for the upgrade of alsa-utils (1.0.27-5 -> 1.0.27.1-1). After automatic boot into X using the autologin service, the volume is set to 0. Running the command `/usr/bin/alsactl -n 19 -c rdaemon` as either normal or root user successfully restores the sound levels to those present at the previous shutdown. Also, user is member of the "audio" group.

Problem is solved by disabling the autologin@.service (suggested by the Arch wiki for automatic login to virtual console). The following is the autologin@.service that was originally enabled:

[Unit]
Description=Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
After=systemd-user-sessions.service plymouth-quit-wait.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

# On systems without virtual consoles, don't start any getty. (Note
# that serial gettys are covered by serial-getty@.service, not this
# unit
ConditionPathExists=/dev/tty0

[Service]
# the VT is cleared by TTYVTDisallocate
ExecStart=-/sbin/agetty --noclear --autologin [username] %I 38400 linux
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
KillMode=process
IgnoreSIGPIPE=no

# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION=

# Some login implementations ignore SIGTERM, so we send SIGHUP
# instead, to ensure that login terminates cleanly.
KillSignal=SIGHUP

[Install]
Alias=getty.target.wants/getty@tty1.service

EOF


This is the same as getty@.service with the "--autologin [username]" option added to ExecStart line. The autologin@.service had previously been enabled with the following commands:

# systemctl daemon-reload
# systemctl disable getty@tty1
# systemctl enable autologin@tty1

Running the commands in near-reverse order restores sound levels on reboots with alsa-lib and alsa-utils 1.0.27.1-1.

# systemctl daemon-reload
# systemctl disable autologin@tty1
# systemctl enable -f getty@tty1
# systemctl stop autologin@tty1
# systemctl reboot

Update: Sound levels were only restored after one reboot. Upon a second reboot, the sound levels are once again muted and at 0 volume. Sorry for the inundation.

I was using xorg-launch-helper and user-session-units, so no autologin@.service here. But that happened anyway!

I have two Arch Linux machines. On laptop everything is working just fine:

alsa-restore.service - Restore Sound Card State
Loaded: loaded (/usr/lib/systemd/system/alsa-restore.service; static)
Active: inactive (dead) since Fri 2013-05-24 17:04:35 MSK; 10min ago
Process: 275 ExecStart=/usr/bin/alsactl restore (code=exited, status=0/SUCCESS)

But on my main PC with Asus Xonar D1 soundcard I've got this:

alsa-restore.service - Restore Sound Card State
Loaded: loaded (/usr/lib/systemd/system/alsa-restore.service; static)
Active: inactive (dead) since Fri 2013-05-24 17:40:54 MSK; 4min 57s ago
Process: 280 ExecStart=/usr/bin/alsactl restore (code=exited, status=19)

No pulseaudio in both cases.

It appears I have the same issue as that in  FS#31163 . When I run `sudo journalctl -a | grep alsa`, I get:

May 23 22:25:47 arch alsactl[172]: /usr/bin/alsactl: load_state:1729: No soundcards found...

I think the problem is that alsa-{restore,state}.service are pulled in by basic.target, which might get started before the sound card becomes available. On my system, this bug disappeared when I made these units depend on sound.target instead:
# cd /usr/lib/systemd/system
# mkdir sound.target.wants
# mv basic.target.wants/alsa-{restore,state}.service sound.target.wants/
# reboot

EDIT: See my comment below.

Thanks Phil. That works for me.

I thought it was the problem, in fact I tried to add "After=sound.target" but probably i forgot to add a sound.target.wants dir (or what else?) and it didn't work.
So it will be fixed soon, great news!

OK, the more I think about it, the more I think my solution isn't quite right and just happens to work by accident.

sound.target is always reached the first time *any* sound hardware is detected. Adding those units to sound.target.wants normally would create a strict ordering which would start alsa-restore.service *before* sound.target, which obviously isn't what we want. However, the alsa services have DefaultDependencies=no set, which essentially removes the strict ordering and -- by happy accident -- systemd happens to start them right after sound.target is reached.

I moved the unit files back to basic.target.wants and added After=sound.target, which actually works on my system and seems more correct. @nierro, I'm not sure why it didn't work for you.

However, there is another problem if a system has more than one sound device. Since sound.target is reached when the *first* audio device is detected, we have no way of ordering alsa-restore.service after *all* audio devices are loaded. Looking through the commit history of alsa-utils, I see that in the past this was handled by having a udev rule that ran 'alsactl restore' every time a sound card was hotplugged (http://git.alsa-project.org/?p=alsa-utils.git;a=blob;f=alsactl/90-alsa-restore.rules.in;hb=HEAD). This was recently removed, for some reason. Maybe the maintainer could shed some light on this?

Yes this rule should be in the package, there was a bug in 1.0.27 with not generating it correct.
I have not the time to fix it right now, but if you would add it manually and report if everything is ok afterwards, we know that this is the issue.

Thanks.

@Phil Puryear: not working here after=sound.target... here is my systemctl status, and alsa-restore.servce; as you see, sound.target is reached after alsa-restore.service: http://pastie.org/7961494 .

Here gnome3 and pulseaudio.

Adding After=sound.target to either alsa-restore.service or alsa-state.service is not working for me.

I restored the missing udev rule by adding the following to the PKGBUILD:

prepare() {
cd $pkgname-$pkgver
echo 'udevrules_DATA=90-alsa-restore.rules' >> alsactl/Makefile.am
autoreconf -fi
}

After installing and rebooting, the rule appears to work fine.

Adding the above udev rule to the default PKGBUILD also fixes the bug for me.