pipewire/wireplumber mutes headphones on boot

[Hammett]

Hi all,

On each boot I need to go to alsamixer and unmute and set volume for the headphones. Once done that, I save the state with

[netfab]

Hi,

Please post the output of :

[Hammett]

[netfab]

You should set the alsasound init script to the boot runlevel.
You must remove your user from the audio group.

[Hammett]

[Hammett]

Well, the plot thickens....

I confirmed that is pipewire who is muting the headphones. If I restart pipewire with gentoo-pipewire-launcher restart &, then heaphone is muted and at 0% volume.

So I thought that I can automatically unmute it with amixer on my .xprofile:

[Jimmy Jazz]

[Hammett]

[Hu]

The file is read top-to-bottom, yes, but think about exactly what you are telling it to do:

• Create gentoo-pipewire-launcher in the background. Do not wait for it to finish. Hope that the kernel schedules it in a timely manner, and that it finishes all its work quickly.
• Create dwmblocks in the background.
• Create unmute_headphone in the background.

Suppose that the logic of gentoo-pipewire-launcher is:

• Run some step that takes 3 seconds.
• Mute headphones
• Do other things

If your unmute_headphone can run to completion in less than 3 seconds, then you unmute before pipewire-launcher can mute it, so your unmute is overwritten seconds later, since mute status is just on/off, not a count of how many mute requests versus unmute requests the system has received. I think you need to find exactly why pipewire is muting your headphones, and either make it not do that, or find how to hook into it so that it runs your unmute script after it has finished muting your headphones. Merely adding a delay before unmute will seem to work until the pipewire launcher takes longer than the delay, at which point it won't work.

[Hammett]

[Hu]

I do not know how to make Pipewire behave as you desire. Perhaps someone else will have advice on that point.

I would just remove the & and let the shell run the launcher synchronously. Using && will also make it synchronous, and will only run the next command if the launcher exits with a success status code. Note that in both cases, running it synchronously assumes it will exit quickly, which may or may not be the case. I haven't looked at that launcher to know whether it blocks until Pipewire exits at the end of your session, or exits promptly on Pipewire confirming that it can start and background itself.

[Jimmy Jazz]

in my case .xprofile is sourced so should be yours. If it is not the last one it explain the behaviour.

why not do something like that ?

[Hammett]

[Hu]

Sleeping for 2 seconds would usually result in it running after /usr/bin/pipewire and /usr/bin/wireplumber are started. However, since gentoo-pipewire-launcher is in the background and asynchronous, it's possible (although unlikely) that the kernel would delay the execution of the entire shown script by an arbitrary amount of time, and not delay your hook script at all, rendering your sleep 2 insufficient. You're welcome to try it, and it may even work usually, but arbitrary sleeps are always the wrong solution for this type of sequencing problem.

[Hammett]

[Jimmy Jazz]

sleeping is not robust enough. The commande sleep is more useful to ease the ability to interrupt the program

waiting the pid file won't work either if it is create to early.

but if the program returns something after the audio initialisation has been done, scan the output