Debian 12 Pipewire: Volume keeps resetting to 40%?

[IansMusical]

Hello All,

I've recently updated from Debian 10 (Cinnamon) via Debian 11 to Debian 12 (Cinnamon) back to back and I've noticed that it uses pipewire instead of pulseaudio but that also the volume defaults to 40% on every reboot. Previously on Debian 10 I set it to 100% and it never changed by itself.

I did find this thread: viewtopic.php?p=783850#p783850 on the forum which is very similar but it feels like there should be a config file setting somewhere rather than a command.

pactl info gives:

Server String: /run/user/1000/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 83
Tile Size: 65472
User Name: ian
Host Name: Ian-PC
Server Name: PulseAudio (on PipeWire 0.3.65)
Server Version: 15.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-0000_00_1f.3.analog-stereo
Default Source: alsa_input.usb-Sunplus_IT_Co_Full_HD_webcam_20200618-02.mono-fallback
Cookie: c7d9:e80f

Does anyone know why this is occurring and what has changed between the versions?

Thank you.

[peer]

perhaps the arch wiki page helps:

Code: Select all

https://wiki.archlinux.org/title/PipeWire

[IansMusical]

Thanks for the link which I've since bookmarked for future reference. Section 5.1.5 seemed relevant but sadly having tried it didn't work for me, i.e. I could adjust the volume to 100% in alsamixer but it didn't persist after reboot. Are there any more suggestions please? Could it be something to do with doing an upgrade from Debian 10 via 11 as opposed to installing Debian 12 from a live USB?

Thank you.

[NorthEast]

You could try and have the volume set to 100%, or any percentage, using the amixer command in a start up file like .xsession, or failing that, create a systemd unit to run the amixer command at start up or write a simple /etc/rc.local file. A command like the following can be used:

Code: Select all

amixer set Master 100%

[FreewheelinFrank]

Check the Debian Pipewire page. Obviously there has been a big change from PulseAudio to Pipewire, and it's a good idea to make sure the transition has gone correctly, everything that needs to be installed has been installed, and everything that needs to be uninstalled has been uninstalled,

For Debian 12 and newer, pipewire-audio-client-libraries is replaced by pipewire-alsa and pipewire-jack. It is recommended to install the metapackage pipewire-audio which depends on wireplumber (the recommended session manager), pipewire-pulse (to replace PulseAudio), pipewire-alsa (ALSA) and libspa-0.2-bluetooth (for Bluetooth support). Moreover, installing this metapackage will remove pulseaudio to prevent any conflicts between both sound server.

https://wiki.debian.org/PipeWire

[gusnan]

I have no solution, but also run into this problem myself.

viewtopic.php?t=156287

[IansMusical]

Thanks everyone for the suggestions. I will try amixer next but all these workarounds like for @gusnan seem to be going in the wrong direction. Clearly this worked in Debian 10 so something has changed. We know that pipewire was introduced in Debian 12(?) but there must be a config file somewhere that sets 40% volume as the default.

@FreewheelinFrank These are the packages currently installed for pipewire.

libpipewire-0.3-0/stable,now 0.3.65-3 amd64 [installed,automatic]
libpipewire-0.3-common/stable,now 0.3.65-3 all [installed,automatic]
libpipewire-0.3-modules/stable,now 0.3.65-3 amd64 [installed,automatic]
pipewire-bin/stable,now 0.3.65-3 amd64 [installed,automatic]
pipewire-pulse/stable,now 0.3.65-3 amd64 [installed,automatic]
pipewire/stable,now 0.3.65-3 amd64 [installed,automatic]

I can see that some of the ones you mentioned in the link are not present but I guess I was expecting the upgrade procedure to make everything Debian 12 compliant. There is pulseaudio 16.1 installed but not running. In fact I'm wondering if a straight install of Debian 12 exhibits this issue as compared to the Debian 10, 11 and 12 upgrade that I carried out?

I'm also seeing my NFS shares being auto mounted via a trigger from gvfs-udisks2-volume-monitor and/or pool in Debian 12 that used to work fine in Debian 10 where they mounted when accessed. Again I wonder if a straight install would not exhibit these issues. I didn't go that way because I would need to install all my software again and I assume their and other settings, which is a bit painful. Maybe it's possible to exclude /home from a reinstall and preserve the settings?

Many thanks.

[FreewheelinFrank]

I can see that some of the ones you mentioned in the link are not present but I guess I was expecting the upgrade procedure to make everything Debian 12 compliant. There is pulseaudio 16.1 installed but not running. In fact I'm wondering if a straight install of Debian 12 exhibits this issue as compared to the Debian 10, 11 and 12 upgrade that I carried out?

The situation in Debian 12 actually seems to be a bit confused, with the transition from PulseAudio to Pipewire, especially upgrades. You are in a half way house, as far as that goes.

I would install

Code: Select all

pipewire-audio

which will uninstall PulseAudio and go the whole hog (to mix metaphores). Having PulseAudio still around seems to cause a lot of issues.

viewtopic.php?t=157688

[IansMusical]

One would hope that the good people behind Debian 12 would make sure it fully worked with pipewire before releasing speaking as a software engineer but I don't want to overly criticise as I know the game. So, I installed pipewire-audio which did indeed remove pulseaudio and pull in pipewire-alsa but sadly after a couple of reboots the volume is still reset to 40%.

I wonder if Debian 12.5 whenever it's released will sort it, otherwise with my NFS issues too I might find a spare hard drive and install Debian 12 from a live USB, as opposed to an upgrade to see if that works. I really don't want to have to reinstall everything... that's like the Windows days

[peer]

Have you tried another DE (like kde or gnome) in stead of cinnamon??

[Shamak]

This is likely a different problem but I'll mention it as the workaround is easy. On a fresh install of Bookworm the volume would often reset to about 40% after a logout/login. Not after a reboot. Sometimes it would show 100% and dummy output so no sound. This is on Gnome. Anyway the workaround was to remove my user from the audio group with

Code: Select all

# gpasswd -d <user> audio

https://github.com/canonical/lightdm/issues/213

I rebooted after that but I don't know if that was necessary.

[None1975]

Anyway the workaround was to remove my user from the audio group

Hello.

I don't think is good idea. Audio group is used for direct access to sound hardware, for all sessions. It is still required to make ALSA and OSS work in remote sessions. Also used in JACK to give users realtime processing permissions.

[IansMusical]

Ok so I've installed Debian 12.4 (same as I upgraded to) on an external hard drive so as not to upset the current install. I found that initially the volume was 40% but setting it to 100% and rebooting sees it stay at 100%, so as @FreewheelinFrank says upgrading from Debian 10 to 12 doesn't really work in that respect even with pipewire-audio installed. Otherwise audio works fine, even Bluetooth audio via the upgrade or install method.

When it comes to nfs I found the same behaviour via upgrade or install, in that my systemd automount units were being triggered by pool and/or gvfs-udisks2-volume-monitor several times at boot/login, then in nemo the share is shown under both "Network" and "Devices/Removable drives", which is strange. The behaviour under Debian 10.x is that the share was only triggered/auto-mounted via the nemo bookmark or CDing into the share mount point, then in nemo it was shown under "Devices".

In short automount units seem to be being triggered automatically at boot when they didn't use to be. A search in Google "gvfs-udisks2-volume-monitor autofs" shows historic issues where the udisks2-volume-monitor seems to incorrectly trigger mounts but it should have been fixed by now. Has anyone seen this behaviour?

[Shamak]

Hello.

I don't think is good idea. Audio group is used for direct access to sound hardware, for all sessions. It is still required to make ALSA and OSS work in remote sessions. Also used in JACK to give users realtime processing permissions.

Thanks. I probably should have mentioned the direct access thing as I found that when researching this so thanks for putting that in. I may still stay with the workaround as I haven't needed these things in 4 years of being on linux.

[None1975]

Thanks. I probably should have mentioned the direct access thing as I found that when researching this so thanks for putting that in. I may still stay with the workaround as I haven't needed these things in 4 years of being on linux.

If you care about my opinion, then I don't think it's a problem of audio group.

On my Arch box i don't have this problem even though the user belongs to the audio group. I think the problem lies somewhere else...
....

[Shamak]

If you care about my opinion, then I don't think it's a problem of audio group.

On my Arch box i don't have this problem even though the user belongs to the audio group. I think the problem lies somewhere else...
....

So some other problem besides the audio group. Thanks again!

[IansMusical]

Quick update: I've not managed to successfully use amixer or wpctl in a systemd unit or --user unit or .xsession file but each command will work fine from the command line. I did already prove that a live USB install of Debian 12.4 does resolve the always resetting to 40% volume though.

For nfs I have been able to resolve this issue. On Debian 10.x I've always used /media as the mount point in my systemd mount/automount units and it worked fine. For Debian 12 I found they always triggered during boot, i.e. not on demand when I clicked on the bookmark in nemo. Reading around it could be that gvfs-udisks2-volume-monitor has changed such that it now searches the /media directory, which looking at the journal seems to back this theory up. I note that this behaviour occurs on a live USB install or upgrade from Debian 10, via 11 to Debian 12.

Again reading around I had read that using /mnt as a mount point for nfs is not regarded as correct but funnily switching my units to use /mnt makes it all work again, i.e my nfs shares are only mounted on demand and not at boot For clarity there are no nfs entries in fstab.

Hope this is useful to someone else.