http://bugzilla.novell.com/show_bug.cgi?id=929619 Takashi Iwai changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jslaby@suse.com Flags| |needinfo?(jslaby@suse.com) --- Comment #1 from Takashi Iwai --- I don't see this on my machine... Does it happen without PulseAudio running? The only calls I can think of are alsa-store.service and alsa-restore.service, which basically just call "/usr/sbin/alsactl store" and "/usr/sbin/alsactl restore". Could you try to call these two commands manually and see whether the same problem appears? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=929619 --- Comment #3 from Takashi Iwai --- (In reply to Jiri Slaby from comment #2)

(In reply to Takashi Iwai from comment #1)

...

I don't see this on my machine... Does it happen without PulseAudio running?

How can I test. Whenever I kill pulseaudio, it restarts...

You need to modify /etc/pulse/client.conf (or equivalent) and set "autospawn = no". -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=929619 --- Comment #5 from Takashi Iwai --- Does this happen even if you don't run any application in background? Also, try to run "alsactl monitor" and run "systemctl daemon-reload" while running it. It should catch the events if the mixer value is changed by anyone. Then the next step would be to figure out who actually changes the mixer. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=929619 Jiri Slaby changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jslaby@suse.com) | --- Comment #6 from Jiri Slaby --- The same it occurred, it dismissed -- I no longer encounter this bug :/. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=929619 http://bugzilla.novell.com/show_bug.cgi?id=929619#c8 Jiri Slaby changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #8 from Jiri Slaby --- Hm, I see it again. The only difference is the volume goes down :(. journalctl upon daemon-reload says: Aug 18 11:40:23 anemoi systemd[1]: Starting Activation of LVM2 logical volumes... Aug 18 11:40:23 anemoi systemd[1]: Listening on Journal Audit Socket. Aug 18 11:40:23 anemoi alsactl[7438]: Found hardware: "HDA-Intel" "Intel PantherPoint HDMI" "HDA:10ec0269,17aa21fa,00100203 HDA:80862806,80860101,00100000" "0x17aa" "0x21fa" Aug 18 11:40:23 anemoi alsactl[7438]: Hardware is initialized using a generic method Aug 18 11:40:23 anemoi systemd[1]: Started Restore Sound Card State. Aug 18 11:40:23 anemoi systemd[1]: Started Activation of LVM2 logical volumes. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=929619 http://bugzilla.novell.com/show_bug.cgi?id=929619#c10 --- Comment #10 from Jiri Slaby --- (In reply to Takashi Iwai from comment #9)

What if running only "alsactl restore"? This should restore the saved state, and this might be different from the state you had.

If systemctl daemon-reload doesn't invoke alsa-store.service, the current state won't be saved. Then it invokes alsa-restore.service and it restores the formerly saved state that can be different from the latest state.

This seems to be the case. "alsactl restore" sets the low-volume state set by some previous alsactl store.

Note that the above is the story in the system level. In the user-level, each application may do store and restore the mixer state by itself. PA does it, too, and kmix used to do it.

So, we need to isolate which does it. That is, reproduce this in runlevel 3 without PA. Then the culprit is likely "alsactl restore" call.

I cannot reproduce after reboot, i.e. ATM. I don't know what precedes the state. Maybe update of some package? But netiher PA, alsa-utils, nor systemd was updated recently. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=929619 http://bugzilla.novell.com/show_bug.cgi?id=929619#c12 Jiri Slaby changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jslaby@suse.com) | --- Comment #12 from Jiri Slaby --- Yes, "alsactl restore" without "alsactl store" is really the culprit. While the former is repeatedly called: ● alsa-restore.service - Restore Sound Card State Loaded: loaded (/usr/lib/systemd/system/alsa-restore.service; static; vendor preset: disabled) Active: inactive (dead) since Út 2015-09-29 16:41:19 CEST; 8min ago Main PID: 10363 (code=exited, status=0/SUCCESS) zář 29 16:41:19 anemoi systemd[1]: Starting Restore Sound Card State... zář 29 16:41:19 anemoi systemd[1]: Started Restore Sound Card State. The latter is never invoked: ● alsa-store.service - Store Sound Card State Loaded: loaded (/usr/lib/systemd/system/alsa-store.service; static; vendor preset: disabled) Active: inactive (dead) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=929619 http://bugzilla.novell.com/show_bug.cgi?id=929619#c14 Jiri Slaby changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #14 from Jiri Slaby --- I think this is gone. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.