FS#35438 - [alsa-utils] Sound muted after bootup

Attached to Project: Arch Linux
Opened by Federico (nierro) - Thursday, 23 May 2013, 12:25 GMT
Last edited by Tobias Powalowski (tpowa) - Monday, 27 May 2013, 07:06 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No


Description: Since alsa-restore.service fails during bootup, and my sound volume is set to 0. It won't fail if executed after startup (eg: in my x session).
journalctl show nothing, while systemctl status: http://pastie.org/7947550 .
I have two laptops, one with pulseaudio and one without. The same problem is happening in both.
alsa-store.service works instead, because if i manually change my sound volume, after a reboot it is set to 0, but after a "systemctl restart alsa-restore.service" , previous level is restored.

Additional info:
* alsa-utils

Steps to reproduce:
Reboot. Sound volume will be set to 0.
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Monday, 27 May 2013, 07:06 GMT
Reason for closing:  Fixed
Additional comments about closing:
Comment by Federico (nierro) - Thursday, 23 May 2013, 12:39 GMT
Sorry, i forgot summary. "Sound muted after bootup" should be ok.
Comment by Bijan Camp (Abstracity) - Friday, 24 May 2013, 02:58 GMT
I confirm this bug for the upgrade of alsa-utils (1.0.27-5 -> 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.
Comment by Bijan Camp (Abstracity) - Friday, 24 May 2013, 03:20 GMT
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:

Description=Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
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.

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

# the VT is cleared by TTYVTDisallocate
ExecStart=-/sbin/agetty --noclear --autologin [username] %I 38400 linux

# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.

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



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

# systemctl daemon-reload
# systemctl disable autologin@tty1
# systemctl enable -f getty@tty1
# systemctl stop autologin@tty1
# systemctl reboot
Comment by Bijan Camp (Abstracity) - Friday, 24 May 2013, 03:28 GMT
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.
Comment by Federico (nierro) - Friday, 24 May 2013, 08:48 GMT
I was using xorg-launch-helper and user-session-units, so no autologin@.service here. But that happened anyway!
Comment by Ivan (ATIpro) - Friday, 24 May 2013, 13:53 GMT
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.
Comment by Bijan Camp (Abstracity) - Friday, 24 May 2013, 20:39 GMT
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...
Comment by Phil Puryear (philpuryear) - Saturday, 25 May 2013, 07:07 GMT
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.
Comment by Bijan Camp (Abstracity) - Saturday, 25 May 2013, 07:20 GMT
Thanks Phil. That works for me.
Comment by Federico (nierro) - Saturday, 25 May 2013, 08:29 GMT
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!
Comment by Phil Puryear (philpuryear) - Saturday, 25 May 2013, 20:19 GMT
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?
Comment by Tobias Powalowski (tpowa) - Sunday, 26 May 2013, 08:27 GMT
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.

Comment by Federico (nierro) - Sunday, 26 May 2013, 08:57 GMT
@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.
Comment by Bijan Camp (Abstracity) - Sunday, 26 May 2013, 16:52 GMT
Adding After=sound.target to either alsa-restore.service or alsa-state.service is not working for me.
Comment by Phil Puryear (philpuryear) - Sunday, 26 May 2013, 18:59 GMT
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.
Comment by Bijan Camp (Abstracity) - Monday, 27 May 2013, 00:32 GMT
Adding the above udev rule to the default PKGBUILD also fixes the bug for me.