Low audio at every boot - ALSA not restored?

Grant · 2023-01-21 15:02:57

Dear all,

Similarly to as reported in PipeWire#Low_Volume, every time I start up my system audio is very low. In the sense, I find

alsamixer

Headphone to 0%. Please have a look at the screenshot https://imgur.com/a/8gYAHqN

I have indeed done

# alsactl store

but it won't be restored. Is pipewire perhaps conflicting? Dunno, maybe the systemd alsa restore service isn't triggered.

Last edited by Grant (2023-01-21 15:05:13)

Head_on_a_Stick · 2023-01-21 17:08:32

Grant wrote:

Dunno, maybe the systemd alsa restore service isn't triggered.

If only there was some sort of logging system that could confirm or refute your hypothesis. What a wonderful thing that would be...

https://wiki.archlinux.org/title/Systemd/Journal

Do you actually need a sound server? I find pure ALSA works just fine for me, unless I need to do some video conferencing.

Grant · 2023-02-17 10:46:50

Yes, mainly because for bluetooth and all it's just more straighforward.

BTW, the curious thing is that:

# journalctl -xe --full -u alsa-restore.service
archlinux systemd[1]: Starting Save/Restore Sound Card State...
░░ Subject: A start job for unit alsa-restore.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit alsa-restore.service has begun execution.
░░ 
░░ The job identifier is 906.
archlinux systemd[1]: Finished Save/Restore Sound Card State.
░░ Subject: A start job for unit alsa-restore.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit alsa-restore.service has finished successfully.
░░ 
░░ The job identifier is 906.

But looking in full journalctl log (I'd like to know why it's not shown in previous command)

 archlinux systemd[1]: Manage Sound Card State (restore and store) was skipped because of an unmet condition check (ConditionPathExists=/etc/alsa/state-daemon.conf).
░░ Subject: A start job for unit alsa-state.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit alsa-state.service has finished successfully.
░░ 
░░ The job identifier is 829.

That is odd. There's no /etc/alsa/state-daemon.conf. Anyways, even removing the ! in ConditionPathExists makes no difference. It won't be restored for some reason even if it says it run successfully.

Last edited by Grant (2023-02-17 10:47:29)

V1del · 2023-02-17 10:57:51

This isn't odd this is normal. The daemon file and the restore mechanism are distinctly different and conflict with each other https://wiki.archlinux.org/title/Advanc … nd_systemd

In a general sense since you are using a sound server, do you just change the volumes in alsamixer and not on the pipewire side with e.g. pavucontrol? By definition of the matter the sound server will generally override the low level settings on an ALSA side and if you just change them on the ALSA side, the sound server never gets wind of this adjustment. Generally speaking you should not use ALSA to change volumes unless you have to (because it's a control not touched by pipewire e.g. Auto-Mute mode toggles are a common case that pipewire won't adjust and that you might want to change there), check in pavucontrol, do your adjustments there, they will get remembered for subsequent pipewire starts.

Last edited by V1del (2023-02-17 10:59:52)

Maniaxx · 2023-02-17 11:05:00

(Only if you really need Alsa):

Use the Alsa store/restore services (not 'alsactl' itself).

'alsactl' invoked as user probably has different save path (not /etc like root/systemd uses). Handle that manually if you do so.

Last edited by Maniaxx (2023-02-17 11:17:25)

Grant · 2023-02-17 11:19:52

V1del wrote:

This isn't odd this is normal. The daemon file and the restore mechanism are distinctly different and conflict with each other https://wiki.archlinux.org/title/Advanc … nd_systemd
In a general sense since you are using a sound server, do you just change the volumes in alsamixer and not on the pipewire side with e.g. pavucontrol? By definition of the matter the sound server will generally override the low level settings on an ALSA side and if you just change them on the ALSA side, the sound server never gets wind of this adjustment. Generally speaking you should not use ALSA to change volumes unless you have to (because it's a control not touched by pipewire e.g. Auto-Mute mode toggles are a common case that pipewire won't adjust and that you might want to change there), check in pavucontrol, do your adjustments there, they will get remembered for subsequent pipewire starts.

I guess there's indeed some conflict going on indeed -- the issue however is that there's no such setting in pavucontrol that does the alsamixer thing. In fact, as the wiki says (quoted from link in 1st post)

After replacing PulseAudio with Pipewire, sound may work fine, but after a reboot, the volume becomes intolerably low.
Open alsamixer, use F6 to select the proper soundcard, and make sure the ALSA volumes are at 100%. alsactl should maintain this setting after reboot.

It does point to using alsamixer. My issue is the last line: the settings are not restored at boot time.

Grant · 2023-02-17 11:21:19

Maniaxx wrote:

(Only if you really need Alsa):
Use the Alsa store/restore services (not 'alsactl' itself).
'alsactl' invoked as user probably has different save path (not /etc like root/systemd uses). Handle that manually if you do so.

I've just checked by lowering manually the setting in screenshot: restarting the alsa-restore service does work. It puts it back to 100%.

Thus, the issue is that this is not done at boot time because it believes the condition is not met -- but done manually there's no trouble?

Last edited by Grant (2023-02-17 11:22:35)

V1del · 2023-02-17 12:31:37

The alsa-restore service is triggered, as we can see from the journal output (the alsa-state service fails but that is expected). It will likely get lowered because pipewire starts and pipewire overrides the ALSA defintion. Whether it does do so in error or not isn't quite clear. From the "low volume" state what's your output for

amixer -c0
pactl list cards
pactl list sinks

? To make a definite statement whether the alsa-restore service is to blame you'd want to mask pipewire temporarily with e.g.

systemctl --user mask pipewire wireplumber pipewire-pulse

reboot and then check whether volume is not as expected and then whether starting pipewire brings back the "wrong" volume

systemctl --user unmask pipewire wireplumber pipewire-pulse --now

Last edited by V1del (2023-02-17 12:35:09)

Grant · 2023-02-17 13:52:45

V1del wrote:

The alsa-restore service is triggered, as we can see from the journal output (the alsa-state service fails but that is expected). It will likely get lowered because pipewire starts and pipewire overrides the ALSA defintion. Whether it does do so in error or not isn't quite clear. From the "low volume" state what's your output for
amixer -c0
pactl list cards
pactl list sinks
? To make a definite statement whether the alsa-restore service is to blame you'd want to mask pipewire temporarily with e.g.
systemctl --user mask pipewire wireplumber pipewire-pulse
reboot and then check whether volume is not as expected and then whether starting pipewire brings back the "wrong" volume
systemctl --user unmask pipewire wireplumber pipewire-pulse --now

If I mask off the pipewire services I get 'host is down' from alsa tools and no audio at all. Is this expected? Still, the amixer -c0 for the 'Headphone' (troublesome) setting is still 0%, but I wouldn't know whether we may trust it now.

Anyways, for the three commands the outputs are a bit lengthy so I'l paste them online if you don't mind.

1) https://pastebin.com/PGWFYPif
2) https://pastebin.com/wfN3DhsR
3) https://pastebin.com/JWZEqrPY

Last edited by Grant (2023-02-17 13:53:12)

V1del · 2023-02-17 14:40:41

Host is down is expected if you attempt to play to the default device instead of e.g.

speaker-test -Dhw:0

, you did explicitly reboot after attempting the mask right and then checking with amixer still showed headphone 0? It's possible restore simply fires too soon in that case. You could try adding some delay to the execution of the restore command by adjusting the alsa-restore.service and adding an ExecStartPre=/usr/bin/sleep 5 or so: https://wiki.archlinux.org/title/System … ided_units

Grant · 2023-02-22 15:12:16

V1del wrote:

t's possible restore simply fires too soon in that case. You could try adding some delay to the execution of the restore command by adjusting the alsa-restore.service and adding an ExecStartPre=/usr/bin/sleep 5 or so: https://wiki.archlinux.org/title/System … ided_units

I guess that is the case. Adding a sleep does the trick. But I wonder if there's a way to actually sort it out, that is why it's firing too soon and not allowing the correct restore.

V1del · 2023-02-22 15:34:55

That'd be somewhere down the kernel/firmware states. Maybe sound.target is reached too early, despite the devices not being fully ready yet, might also be a discrepancy between "old" HDA expectations and how sof/sof-firmware initializes the device.

Grant · 2023-02-24 10:32:18

V1del wrote:

That'd be somewhere down the kernel/firmware states. Maybe sound.target is reached too early, despite the devices not being fully ready yet, might also be a discrepancy between "old" HDA expectations and how sof/sof-firmware initializes the device.

So you're saying it's something to be "solved" in future updates? BTW, I was thinking maybe I could make the service trigger, say, after graphical.target or maybe have GNOME itself restore it through a script or something. Or I guess KISS applies.

BTW, what puzzles me is why systemd thinks that there's a conflict: that is, it "sees" a file that actually does not exist and hence won't match the condition (maybe fs is mounted too soon?). So this would say it's more of a systemd issue rather than ALSA/PipeWire conflict (regarding what, if it were? AFAIK, the former starts much earlier than the latter).

Actually I just thought I could make the service restart on its own if it fails rather than sleep before exec. I'll let you know.

V1del · 2023-02-24 10:42:51

Again the the file conflict is from alsa-state.service, which is normal and expected and you do not want to change that fact when you are using pipewire in the end and not cause for concern. alsa-restore.service triggers properly and correctly but apparently too soon for the sound device. Changing/additionally depending on graphical.target could work and logically delay the process enough, something else I only thought of now, you can make the service explicitly wait for the sof sound card like we did for example in this thread: https://bbs.archlinux.org/viewtopic.php?id=213751

jlindgren · 2023-03-01 17:00:48

V1del wrote:

alsa-restore.service triggers properly and correctly but apparently too soon for the sound device.

alsa-restore.service has always loaded too early on my system as well (as long as I can remember).
I use the following drop-in to solve the issue:

/etc/systemd/system/alsa-restore.service.d/override.conf

[Unit]
Requires=dev-snd-controlC0.device
After=dev-snd-controlC0.device

V1del · 2023-03-01 18:05:33

Yeah because afaik it will be reached when any sound card is available, so it will likely trigger when the hdmi card is ready and before the other card is up.

Grant · 2023-03-02 11:46:14

V1del wrote:

Yeah because afaik it will be reached when any sound card is available, so it will likely trigger when the hdmi card is ready and before the other card is up.

Yeah I do believe that's the culprit.

I've been playing around with it. To decouple any issue I could think of I made alsactl to restore from a different config file -- indeed, since it stores at the end, if volume is lowered down by any means, at next boot it will mess up my alsamixer settings.

Using sound.target/graphical made no difference though. It won't work. But as soon as I manually restart the service, it correctly brings up the volume. Let me say again however, the sleep thing did work instead. Uhm.

Grant · 2023-03-02 11:47:37

jlindgren wrote:

V1del wrote:
alsa-restore.service triggers properly and correctly but apparently too soon for the sound device.
alsa-restore.service has always loaded too early on my system as well (as long as I can remember).
I use the following drop-in to solve the issue:
/etc/systemd/system/alsa-restore.service.d/override.conf
[Unit]
Requires=dev-snd-controlC0.device
After=dev-snd-controlC0.device

Thanks for bringing it up!

I edited the .service to make it behave as that -- sadly it didn't work. Am I missing something?

V1del · 2023-03-02 11:51:53

Is the problematic card the one designated as card 0? you need to specify the SoF card there

Grant · 2023-03-02 12:50:08

AFAIK it is

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sofessx8336 [sof-essx8336], device 0: ES8336 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofessx8336 [sof-essx8336], device 5: HDMI 1 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofessx8336 [sof-essx8336], device 6: HDMI 2 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofessx8336 [sof-essx8336], device 7: HDMI 3 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

and

$ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
default
    Default ALSA Output (currently PipeWire Media Server)
sysdefault:CARD=sofessx8336
    sof-essx8336, 
    Default Audio Device

as far I can see it should match the alsamixer config for that card (https://imgur.com/a/8gYAHqN). Ofc when alsamixer is opened, pipewire is listed first and then I switch to the default:0 sof.

Last edited by Grant (2023-03-02 12:51:15)

Arch Linux

#1 2023-01-21 15:02:57

Low audio at every boot - ALSA not restored?

#2 2023-01-21 17:08:32

Re: Low audio at every boot - ALSA not restored?

#3 2023-02-17 10:46:50

Re: Low audio at every boot - ALSA not restored?

#4 2023-02-17 10:57:51

Re: Low audio at every boot - ALSA not restored?

#5 2023-02-17 11:05:00

Re: Low audio at every boot - ALSA not restored?

#6 2023-02-17 11:19:52

Re: Low audio at every boot - ALSA not restored?

#7 2023-02-17 11:21:19

Re: Low audio at every boot - ALSA not restored?

#8 2023-02-17 12:31:37

Re: Low audio at every boot - ALSA not restored?

#9 2023-02-17 13:52:45

Re: Low audio at every boot - ALSA not restored?

#10 2023-02-17 14:40:41

Re: Low audio at every boot - ALSA not restored?

#11 2023-02-22 15:12:16

Re: Low audio at every boot - ALSA not restored?

#12 2023-02-22 15:34:55

Re: Low audio at every boot - ALSA not restored?

#13 2023-02-24 10:32:18

Re: Low audio at every boot - ALSA not restored?

#14 2023-02-24 10:42:51

Re: Low audio at every boot - ALSA not restored?

#15 2023-03-01 17:00:48

Re: Low audio at every boot - ALSA not restored?

#16 2023-03-01 18:05:33

Re: Low audio at every boot - ALSA not restored?

#17 2023-03-02 11:46:14

Re: Low audio at every boot - ALSA not restored?

#18 2023-03-02 11:47:37

Re: Low audio at every boot - ALSA not restored?

#19 2023-03-02 11:51:53

Re: Low audio at every boot - ALSA not restored?

#20 2023-03-02 12:50:08

Re: Low audio at every boot - ALSA not restored?

Board footer