systemd randomly resetting master ALSA volume [SOLVED]

speeddefrost · 2015-01-29 01:34:13

Occasionally the master volume is reset back to 34% from where it was before the last shutdown (100%). I'm pretty sure it's related to alsa-store.service but I have no idea where the actual problem is and it's driving me insane. I'm not using PulseAudio either.

Last edited by speeddefrost (2015-02-15 00:13:17)

berbae · 2015-01-29 15:39:35

Post the output of:
$ journalctl -b|grep -i -e alsa -e sound

speeddefrost · 2015-01-30 07:13:21

That command gave no output. There technically isn't any 'error' happening at all. The state for my soundcard just doesn't seem to be restored sometimes. The only relevant driver configurations I've made in modprobe.conf are:

options snd_usb_audio index=-2
options snd_hda_intel power_save=0 power_save_controller=N

But I doubt that these have anything to do with it at all.

I've modified alsa-restore.service so that alsactl uses the '-I' and '-P' options to see if it helps. It only seems to happen every few boots.

Last edited by speeddefrost (2015-01-30 07:17:36)

ooo · 2015-01-30 08:25:46

this may be too obvious, but did you try running

alsactl store

as root, after setting the desired master level?
or enabled alsa-store.service

berbae · 2015-01-30 13:20:01

If the command gave no output as a user, maybe you are not a member of the 'systemd-journal' group;
so either add your user to this group or run the command as root:

# journalctl -b|grep -i -e alsa -e sound -e snd
(I added 'snd' to be sure)

At least it should show the 'alsa-restore.service', and also what concerns your sound card.

speeddefrost · 2015-01-31 22:53:41

ooo wrote:

this may be too obvious, but did you try running
alsactl store
as root, after setting the desired master level?
or enabled alsa-store.service

ALSA-related service files can't be enabled/disabled. They're not like other ones. AFAIK they already run alsactl for me and that's where the problem seems to be.

berbae wrote:

If the command gave no output as a user, maybe you are not a member of the 'systemd-journal' group;
so either add your user to this group or run the command as root:
# journalctl -b|grep -i -e alsa -e sound -e snd
(I added 'snd' to be sure)
At least it should show the 'alsa-restore.service', and also what concerns your sound card.

I ran it as root:

Jan 31 13:50:26 origin kernel: snd_hda_intel 0000:00:1b.0: irq 28 for MSI/MSI-X
Jan 31 13:50:26 origin kernel: sound hdaudioC0D0: autoconfig: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line
Jan 31 13:50:26 origin kernel: sound hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
Jan 31 13:50:26 origin kernel: sound hdaudioC0D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
Jan 31 13:50:26 origin kernel: sound hdaudioC0D0:    mono: mono_out=0x0
Jan 31 13:50:26 origin kernel: sound hdaudioC0D0:    dig-out=0x11/0x1e
Jan 31 13:50:26 origin kernel: sound hdaudioC0D0:    inputs:
Jan 31 13:50:26 origin kernel: sound hdaudioC0D0:      Front Mic=0x19
Jan 31 13:50:26 origin kernel: sound hdaudioC0D0:      Rear Mic=0x18
Jan 31 13:50:26 origin kernel: sound hdaudioC0D0:      Line=0x1a
Jan 31 13:50:26 origin kernel: input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input8
Jan 31 13:50:26 origin kernel: input: HDA Intel Front Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9
Jan 31 13:50:26 origin kernel: input: HDA Intel Rear Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
Jan 31 13:50:26 origin kernel: input: HDA Intel Line as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
Jan 31 13:50:26 origin kernel: input: HDA Intel Line Out Front as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
Jan 31 13:50:26 origin kernel: input: HDA Intel Line Out Surround as /devices/pci0000:00/0000:00:1b.0/sound/card0/input13
Jan 31 13:50:26 origin kernel: input: HDA Intel Line Out CLFE as /devices/pci0000:00/0000:00:1b.0/sound/card0/input14
Jan 31 13:50:26 origin kernel: input: HDA Intel Line Out Side as /devices/pci0000:00/0000:00:1b.0/sound/card0/input15
Jan 31 13:50:26 origin kernel: input: HDA Intel Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input16
Jan 31 13:50:26 origin systemd[1]: Starting Sound Card.
Jan 31 13:50:26 origin systemd[1]: Reached target Sound Card.
Jan 31 13:50:27 origin systemd[1]: Started Manage Sound Card State (restore and store).
Jan 31 13:50:27 origin systemd[1]: Starting Restore Sound Card State...
Jan 31 13:50:27 origin systemd[1]: Started Restore Sound Card State.
Jan 31 13:44:05 origin kernel: usbcore: registered new interface driver snd-usb-audio

...as I already said, nothing seems to be broken. The soundcard state sometimes just isn't restored (or maybe not even saved properly, I don't know).

Last edited by speeddefrost (2015-01-31 22:54:27)

Knute · 2015-02-01 06:54:30

So what happens if, after setting your audio levels the way that you want it, you issue the command:

systemctl restart alsa-store.service

?

Just because it's "handled" doesn't mean that it's being handled as you want. I'm not sure if you will have to try the above command as root or not, but am guessing that you may need to.

HTH

berbae · 2015-02-01 15:44:27

If you run:
# alsactl restore

Do you get the right sound levels?
If yes, that shows that the right levels were written in '/var/lib/alsa/asound.state';
if not, the 'alsa-store.service' either has not worked properly at shutdown, or has not seen the right values to keep in the file.

Other than that systemd does nothing to the level of the sound during a running system, only at boot time and at shutdown.
Why do you think it's systemd the culprit?
And what do you mean by 'Occasionally' in the OP?

speeddefrost · 2015-02-07 02:40:54

berbae wrote:

If you run:
# alsactl restore
Do you get the right sound levels?
If yes, that shows that the right levels were written in '/var/lib/alsa/asound.state';
if not, the 'alsa-store.service' either has not worked properly at shutdown, or has not seen the right values to keep in the file.
Other than that systemd does nothing to the level of the sound during a running system, only at boot time and at shutdown.
Why do you think it's systemd the culprit?
And what do you mean by 'Occasionally' in the OP?

By 'ocassionally' I mean that the volume only sometimes gets messed up. It's a flakey and annoying issue. I'm pretty sure systemd or or the service files are to blame because this never happened back when Arch was still using SysV. It happened again today and manually running 'alsactl restore' didn't restore the correct volume, so I'm fairly sure now that the state is intermittently not being stored, for whatever reason.

berbae · 2015-02-07 09:47:17

When you say "it happened again today", are you saying the volume is wrong just after the boot, or this happens at a random time after that?
If it is just after the boot, and with the fact that the volume is wrong when you manually run 'alsactl restore', that means the right volume is not correctly stored.
If you run this:
# journalctl -b -1|grep -i -e alsa -e sound -e snd

do you have at the end:

févr. 07 00:08:37 arch64 systemd[1]: Starting Store Sound Card State...
févr. 07 00:08:37 arch64 systemd[1]: Started Store Sound Card State.

Do you (or some program) change the sound level when the machine is running?
Because if it doesn't stay at 100%, this will be saved at shutdown, and restored at next boot.
If you don't want that, you can run

# alsactl store
when the sound level is good, then disable the alsa-store service:

# systemctl disable alsa-store.service
# systemctl daemon-reload

So the level restored at boot will always be the one you want.

In the case that the volume changes randomly during running time, I don't think that systemd could be the source of this, if nothing has changed the default configuration.
You say "this never happened back when Arch was still using SysV", but since then not only systemd has changed, so this not logically implies that it obligatorily is systemd fault; I'm just saying...

speeddefrost · 2015-02-10 08:29:12

berbae wrote:

When you say "it happened again today", are you saying the volume is wrong just after the boot, or this happens at a random time after that?

It happens during boot. It's not completely random.

berbae wrote:

Do you (or some program) change the sound level when the machine is running?

I always try to keep it at 100%.

berbae wrote:

# journalctl -b -1|grep -i -e alsa -e sound -e snd

It happened again today and this time the issue made itself obvious. alsa-restore.service was starting before the kernel even found the sound card.

Feb 09 14:46:27 origin206 systemd[1]: Starting Restore Sound Card State...
Feb 09 14:46:27 origin206 systemd[1]: Started Restore Sound Card State.
Feb 09 14:46:27 origin206 alsactl[114]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Feb 09 14:46:29 origin206 kernel: snd_hda_intel 0000:00:1b.0: irq 28 for MSI/MSI-X
Feb 09 14:46:29 origin206 kernel: sound hdaudioC0D0: autoconfig: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line
Feb 09 14:46:29 origin206 kernel: sound hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
Feb 09 14:46:29 origin206 kernel: sound hdaudioC0D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
Feb 09 14:46:29 origin206 kernel: sound hdaudioC0D0:    mono: mono_out=0x0
Feb 09 14:46:29 origin206 kernel: sound hdaudioC0D0:    dig-out=0x11/0x1e
Feb 09 14:46:29 origin206 kernel: sound hdaudioC0D0:    inputs:
Feb 09 14:46:29 origin206 kernel: sound hdaudioC0D0:      Front Mic=0x19
Feb 09 14:46:29 origin206 kernel: sound hdaudioC0D0:      Rear Mic=0x18
Feb 09 14:46:29 origin206 kernel: sound hdaudioC0D0:      Line=0x1a
Feb 09 14:46:29 origin206 kernel: input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input8
Feb 09 14:46:29 origin206 kernel: input: HDA Intel Front Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9
Feb 09 14:46:29 origin206 kernel: input: HDA Intel Rear Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
Feb 09 14:46:29 origin206 kernel: input: HDA Intel Line as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
Feb 09 14:46:29 origin206 kernel: input: HDA Intel Line Out Front as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
Feb 09 14:46:29 origin206 kernel: input: HDA Intel Line Out Surround as /devices/pci0000:00/0000:00:1b.0/sound/card0/input13
Feb 09 14:46:29 origin206 kernel: input: HDA Intel Line Out CLFE as /devices/pci0000:00/0000:00:1b.0/sound/card0/input14
Feb 09 14:46:29 origin206 kernel: input: HDA Intel Line Out Side as /devices/pci0000:00/0000:00:1b.0/sound/card0/input15
Feb 09 14:46:29 origin206 kernel: input: HDA Intel Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input16
Feb 09 14:46:29 origin206 systemd[1]: Starting Sound Card.
Feb 09 14:46:29 origin206 systemd[1]: Reached target Sound Card.
Feb 09 14:46:29 origin206 systemd[1]: Started Manage Sound Card State (restore and store).
Feb 09 14:39:46 origin206 kernel: usbcore: registered new interface driver snd-usb-audio

Bingo... but now what?

berbae · 2015-02-10 17:08:41

I think there are two problems in your case:

1) you don't have the right volume stored in '/var/lib/alsa/asound.state', because when you run
# alsactl restore
you don't get the right values.

To solve this, you can do what I mentioned in my post #10
or if you are sure nothing will change the volume in the running system, you can leave the alsa-store.service enabled, and run only:
# alsactl store
once, with the good values.

2) There is a problem in the default systemd configuration of the sound with alsa installed.
In fact I have the same problem, but the title of your thread leads me to think it was not the same issue.
For me, I get:

LANG=C journalctl|grep "No soundcards found"
Jan 24 10:49:44 arch64 alsactl[223]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Jan 25 10:14:24 arch64 alsactl[223]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Jan 27 10:40:36 arch64 alsactl[223]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Jan 27 17:15:38 arch64 alsactl[221]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Jan 28 10:11:21 arch64 alsactl[221]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Jan 29 10:16:34 arch64 alsactl[224]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Jan 29 12:00:24 arch64 alsactl[226]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Jan 31 10:38:31 arch64 alsactl[224]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Feb 01 10:22:06 arch64 alsactl[225]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Feb 03 10:39:31 arch64 alsactl[225]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Feb 03 16:46:00 arch64 alsactl[227]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Feb 06 14:01:56 arch64 alsactl[227]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Feb 07 09:57:32 arch64 alsactl[224]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Feb 08 10:33:16 arch64 alsactl[233]: /usr/bin/alsactl: load_state:1729: No soundcards found...
Feb 09 10:26:32 arch64 alsactl[223]: /usr/bin/alsactl: load_state:1729: No soundcards found...

My machine is booted every day, but the 'No soundcards found' message doesn't appear every day, so there is a randomness in the occurence.
When it happens, the alsa-restore service is started before the sound target is reached.
Until today, the workaround I used was to re-run the alsa-restore service 2 minutes after boot with a timer.
But studying the problem again, I tried something else, based on:

$ man systemd.special
...
       sound.target
           This target is started automatically as soon as a sound card is plugged in or becomes available at boot.

           This may be used to pull in audio management daemons dynamically when audio hardware is found.
...

I ran:
# systemctl add-wants sound.target alsa-restore.service
# systemctl daemon-reload

At the next boot, it works:

LANG=C journalctl -b|grep -i -e alsa -e sound -e snd
Feb 10 16:47:03 arch64 kernel: snd_hda_intel 0000:00:09.0: Disabling MSI
Feb 10 16:47:04 arch64 kernel: sound hdaudioC0D0: autoconfig: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line
Feb 10 16:47:04 arch64 kernel: sound hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
Feb 10 16:47:04 arch64 kernel: sound hdaudioC0D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
Feb 10 16:47:04 arch64 kernel: sound hdaudioC0D0:    mono: mono_out=0x0
Feb 10 16:47:04 arch64 kernel: sound hdaudioC0D0:    dig-out=0x1e/0x0
Feb 10 16:47:04 arch64 kernel: sound hdaudioC0D0:    inputs:
Feb 10 16:47:04 arch64 kernel: sound hdaudioC0D0:      Rear Mic=0x18
Feb 10 16:47:04 arch64 kernel: sound hdaudioC0D0:      Front Mic=0x19
Feb 10 16:47:04 arch64 kernel: sound hdaudioC0D0:      Line=0x1a
Feb 10 16:47:04 arch64 kernel: sound hdaudioC0D0:      CD=0x1c
Feb 10 16:47:04 arch64 kernel: sound hdaudioC0D0:    dig-in=0x1f
Feb 10 16:47:06 arch64 kernel: input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:09.0/sound/card0/hdaudioC0D0/input6
Feb 10 16:47:06 arch64 kernel: input: HDA NVidia Rear Mic as /devices/pci0000:00/0000:00:09.0/sound/card0/input7
Feb 10 16:47:06 arch64 kernel: input: HDA NVidia Front Mic as /devices/pci0000:00/0000:00:09.0/sound/card0/input8
Feb 10 16:47:06 arch64 kernel: input: HDA NVidia Line as /devices/pci0000:00/0000:00:09.0/sound/card0/input9
Feb 10 16:47:06 arch64 kernel: input: HDA NVidia Line Out Front as /devices/pci0000:00/0000:00:09.0/sound/card0/input10
Feb 10 16:47:06 arch64 kernel: input: HDA NVidia Line Out Surround as /devices/pci0000:00/0000:00:09.0/sound/card0/input11
Feb 10 16:47:06 arch64 kernel: input: HDA NVidia Line Out CLFE as /devices/pci0000:00/0000:00:09.0/sound/card0/input12
Feb 10 16:47:06 arch64 kernel: input: HDA NVidia Line Out Side as /devices/pci0000:00/0000:00:09.0/sound/card0/input13
Feb 10 16:47:06 arch64 kernel: input: HDA NVidia HDMI/DP,pcm=3 Phantom as /devices/pci0000:00/0000:00:09.0/sound/card0/input14
Feb 10 16:47:06 arch64 systemd[1]: Starting Sound Card.
Feb 10 16:47:06 arch64 systemd[1]: Reached target Sound Card.
Feb 10 16:47:13 arch64 systemd[1]: Started Manage Sound Card State (restore and store).
Feb 10 16:47:13 arch64 systemd[1]: Starting Restore Sound Card State...
Feb 10 16:47:14 arch64 systemd[1]: Started Restore Sound Card State.

But it needs to be confirmed in the next days.
I will post again about that...

Last edited by berbae (2015-02-10 17:09:25)

speeddefrost · 2015-02-10 20:28:25

berbae wrote:

In fact I have the same problem, but the title of your thread leads me to think it was not the same issue.

I assumed that that having systemd in the title implied it happened during boot. Sorry for the confusion.

berbae wrote:

# systemctl add-wants sound.target alsa-restore.service
# systemctl daemon-reload

I suppose I'll try this as well. Thanks for the help.

Sn1PeR · 2015-02-14 23:48:57

I've had similar issues (volume refuses to stay down - will always turn up to ~80%) for years and basically don't use speakers while in linux because if it. I thought it was a gnome issue, but it's happening in KDE now so I'm starting to think it's a pulseaudio issue. I can issue alsactl restore and it goes back to where I want it, but then it will turn itself back up and blow my ears out less than 30-seconds later. I've tried flat-volumes yes/no, deleting my .config/pulse folder, etc.

speeddefrost · 2015-02-15 00:12:28

Sn1PeR wrote:

I've had similar issues (volume refuses to stay down - will always turn up to ~80%) for years and basically don't use speakers while in linux because if it. I thought it was a gnome issue, but it's happening in KDE now so I'm starting to think it's a pulseaudio issue. I can issue alsactl restore and it goes back to where I want it, but then it will turn itself back up and blow my ears out less than 30-seconds later. I've tried flat-volumes yes/no, deleting my .config/pulse folder, etc.

If it's really the same problem then it's not at all related to PulseAudio, just ALSA. Luckily it's fixed now with the commands berbae posted.

berbae · 2015-02-19 16:14:13

My tests with the commands shown in my post #12 are not satisfying:
it doesn't work as expected at each boot, and the volume is not reliably restored.

This is due to the links created by the alsa-utils package:

$ cd /usr/lib/systemd/system/basic.target.wants
$ ls -l
lrwxrwxrwx 1 root root 23 18 juin   2014 alsa-restore.service -> ../alsa-restore.service
lrwxrwxrwx 1 root root 21 18 juin   2014 alsa-state.service -> ../alsa-state.service

These links are hard coded in the source tree of alsa-utils and cannot be changed without modifying the package.
When I add the links in /etc/systemd/system/sound.target.wants:

alsa-restore.service -> /usr/lib/systemd/system/alsa-restore.service
alsa-state.service -> /usr/lib/systemd/system/alsa-state.service

the two link pairs don't work well and reliably together; the second alsa-restore can be started before the first one is ended.
Sometimes this works and sometimes not.

So I am now using again my first workaround, ie to re-run a modified alsa-restore service 2 minutes after boot with a systemd timer:

$ cd /etc/systemd/system
$ cat alsa-restore-again.timer
# The original alsa-restore service is ineffective
# So run the command again with alsa-restore-again
#

[Unit]
Description=Timer for Restore Again Sound Card State

[Timer]
OnBootSec=2min

$ cat alsa-restore-again.service
# Started by alsa-restore-again.timer
#
[Unit]
Description=Restore Again Sound Card State
ConditionPathExists=!/etc/alsa/state-daemon.conf
DefaultDependencies=no

[Service]                                                                                                                               
Type=oneshot                                                                                                                            
ExecStart=-/usr/bin/alsactl restore                                                                                                     
StandardOutput=syslog

The timer is added to the multi-user.target.

This is more reliable on my machine to restore the sound volume at each boot.

Arch Linux

#1 2015-01-29 01:34:13

systemd randomly resetting master ALSA volume [SOLVED]

#2 2015-01-29 15:39:35

Re: systemd randomly resetting master ALSA volume [SOLVED]

#3 2015-01-30 07:13:21

Re: systemd randomly resetting master ALSA volume [SOLVED]

#4 2015-01-30 08:25:46

Re: systemd randomly resetting master ALSA volume [SOLVED]

#5 2015-01-30 13:20:01

Re: systemd randomly resetting master ALSA volume [SOLVED]

#6 2015-01-31 22:53:41

Re: systemd randomly resetting master ALSA volume [SOLVED]

#7 2015-02-01 06:54:30

Re: systemd randomly resetting master ALSA volume [SOLVED]

#8 2015-02-01 15:44:27

Re: systemd randomly resetting master ALSA volume [SOLVED]

#9 2015-02-07 02:40:54

Re: systemd randomly resetting master ALSA volume [SOLVED]

#10 2015-02-07 09:47:17

Re: systemd randomly resetting master ALSA volume [SOLVED]

#11 2015-02-10 08:29:12

Re: systemd randomly resetting master ALSA volume [SOLVED]

#12 2015-02-10 17:08:41

Re: systemd randomly resetting master ALSA volume [SOLVED]

#13 2015-02-10 20:28:25

Re: systemd randomly resetting master ALSA volume [SOLVED]

#14 2015-02-14 23:48:57

Re: systemd randomly resetting master ALSA volume [SOLVED]

#15 2015-02-15 00:12:28

Re: systemd randomly resetting master ALSA volume [SOLVED]

#16 2015-02-19 16:14:13

Re: systemd randomly resetting master ALSA volume [SOLVED]

Board footer