| View previous topic :: View next topic |
| Author |
Message |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
 Posted: Sun Jun 30, 2024 8:16 am Post subject: [Solved] pipewire and volume |
 |
|
It might be relevant to this question that I use pipewire[-pipewire-alsa], because I need pipewire only for google-chrome and discord as a pulseaudio-substitute.
Whenever I start pipewire/wireplumber (which I naturally do immediately after login), it lowers the volume level (to always the same amount, about 30%). However, I can change it back manually with alsamixer.
I also realized now that with bluez, it also lowers the default volume level. This is worse, because I cannot control this with alsamixer. Also using e.g. pavucontrol to change the volume has no effect. With bluealsa, there is the option --initial-volume=[0-100], but this effects the volume only if I output with alsa to the bluealsa device which is not happening when the sound output is to pulseaudio (that is, pipewire).
The files in ~/.local/state/wireplumber contain entries like "volume" or "channelVolume", but the values are all "1.000000", so this does not explain why the volume is not maximal.
So my question is two fold:
1. How to change volume for a connected bluetooth headphone with pipewire at all?
2. How to configure the startup volume level (for alsa and bluetooth, respectively) for pipewire? (It seems to be hardcoded at 30% or less.)
Last edited by mv on Sun Jun 30, 2024 3:24 pm; edited 1 time in total |
|
| Back to top |
|
 |
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sun Jun 30, 2024 9:45 am Post subject: |
|
|
| Code: | $ wpctl
Usage:
wpctl [OPTION…] COMMAND [COMMAND_OPTIONS] - WirePlumber Control CLI
Commands:
status
get-volume ID
inspect ID
set-default ID
set-volume ID VOL[%][-/+]
set-mute ID 1|0|toggle
set-profile ID INDEX
set-route ID INDEX
clear-default [ID]
settings [KEY] [VAL]
set-log-level [ID] LEVEL |
First run wpctl status,
| Code: | | * 52. ALC269VC [vol: 1.00] |
Find device, id in this case is 52
wpctl set-volume 52 50% (or 5+/5- or 0.5)
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
ormorph
n00b
Joined: 18 Jun 2024
Posts: 27
|
| Posted: Sun Jun 30, 2024 10:31 am Post subject: |
|
|
| Perhaps you used the wrong regulator in pavucontrol; for general sound you need to use the "Output Devices" option. By adjusting the volume in devices when the "Output Devices" option is selected, the sound will also change in alsamixer. In addition, then the volume level will be maintained after a reboot. The file .local/state/wireplumber/restore-stream is responsible for this. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Jun 30, 2024 11:56 am Post subject: |
|
|
| Anon-E-moose wrote: | [code]$ wpctl
[...]
First run wpctl status,
[code]* 52. ALC269VC [vol: 1.00][/code]
Find device, id in this case is 52
wpctl set-volume 52 50% (or 5+/5- or 0.5) |
Thank you very much! This worked! |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Jun 30, 2024 12:00 pm Post subject: |
|
|
| ormorph wrote: | | Perhaps you used the wrong regulator in pavucontrol; for general sound you need to use the "Output Devices" option. |
On Output Devices, I see "Line Out (plugged in)", and a greyed-out level which I can move but which has no effect at all and which is also reset when I restart pavucontrol.
Below that, I see my headset with a not-greyed-out level which I can move but which has also no effect at all and which is also reset when I restart pavucontrol.
Both are reset to the values I configured with wpctrl, so it seems that wpctrl works and can change the values while pavucontrol only reads the values but cannot change them for some reason. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sun Jun 30, 2024 12:05 pm Post subject: |
|
|
On my system, the id's seem pretty consistent, across boots.
When the headphones are plugged in, you can set them as the default device, and it will remember that for the next time you use them.
I have pipewire handle bluetooth as well as alsa, don't have either jack or pulse installed, so don't use that aspect of pipewire/wireplumber
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
ormorph
n00b
Joined: 18 Jun 2024
Posts: 27
|
| Posted: Sun Jun 30, 2024 12:27 pm Post subject: |
|
|
| mv wrote: | On Output Devices, I see "Line Out (plugged in)", and a greyed-out level which I can move but which has no effect at all and which is also reset when I restart pavucontrol.
Below that, I see my headset with a not-greyed-out level which I can move but which has also no effect at all and which is also reset when I restart pavucontrol.
Both are reset to the values I configured with wpctrl, so it seems that wpctrl works and can change the values while pavucontrol only reads the values but cannot change them for some reason. |
Do you happen to use settings with the PULSE_SERVER variable, or did you add the config to /etc/pipewire/pipewire-pulse.conf and edit it? This happened to me when tcp was selected, but when I replaced tcp with a unix socket, the sound adjustment worked. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Jun 30, 2024 12:56 pm Post subject: |
|
|
| ormorph wrote: | | Do you happen to use settings with the PULSE_SERVER variable, or did you add the config to /etc/pipewire/pipewire-pulse.conf and edit it? This happened to me when tcp was selected, but when I replaced tcp with a unix socket, the sound adjustment worked. |
I have PULSE_SERVER and /etc/pipewire/pipewire-pulse.conf both configured to a tcp. I do not want to use a unit socket, because I want to access pulse with several users from wayland. (I know that I could do permission hacks with sockets, but I do not want to do that.) |
|
| Back to top |
|
|
ormorph
n00b
Joined: 18 Jun 2024
Posts: 27
|
| Posted: Sun Jun 30, 2024 1:13 pm Post subject: |
|
|
| mv wrote: | | I have PULSE_SERVER and /etc/pipewire/pipewire-pulse.conf both configured to a tcp. I do not want to use a unit socket, because I want to access pulse with several users from wayland. (I know that I could do permission hacks with sockets, but I do not want to do that.) |
You looked at the topic where I posted links to the daemon for openrc. Several users can work via a unix socket. link1 link2.
Setting up with tcp is needed if you want to play sound from another computer, but for this you can register tcp in /etc/pipewire/pipewire-pulse.conf in addition to the unix socket. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Jun 30, 2024 1:20 pm Post subject: |
|
|
| ormorph wrote: | | mv wrote: | | I have PULSE_SERVER and /etc/pipewire/pipewire-pulse.conf both configured to a tcp. I do not want to use a unit socket, because I want to access pulse with several users from wayland. (I know that I could do permission hacks with sockets, but I do not want to do that.) |
You looked at the topic where I posted links to the daemon for openrc. Several users can work via a unix socket. |
Yes, as I said with permission hacks where everybody can write to a socket with a predictable file name in a public directory and/or other users need linking hacks at startup. Using tcp does sound more secure and simpler. As long as pavuctl is the only tool which breaks (and I have a working replacement for setting the volume) I do not care. |
|
| Back to top |
|
|
ormorph
n00b
Joined: 18 Jun 2024
Posts: 27
|
| Posted: Sun Jun 30, 2024 1:28 pm Post subject: |
|
|
| mv wrote: | | Yes, as I said with permission hacks where everybody can write to a socket with a predictable file name in a public directory and/or other users need linking hacks at startup. Using tcp does sound more secure. |
I don’t understand what then prevents everyone from writing to tcp? In Linux, no matter how everything is a file. You can ask the developers a question, I haven’t found a solution on how to regulate the sound using tcp. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Jun 30, 2024 1:40 pm Post subject: |
|
|
| ormorph wrote: | | I don’t understand what then prevents everyone from writing to tcp? |
iptables and/or nftables
| Quote: | | In Linux, no matter how everything is a file. |
What I mainly dislike for the approach is not the one public socket (I guess that this could probably be created also in a more restricted directory, e.g. in /run for which you can set more fine-grained permissions), but mainly the need to link the file at startup: There is no nice place for this linking. Doing it at every startup of an init-shell (or even of every shell?) is rather wrong, as using sound from some unprivileged user is logically not coupled to using a shell. |
|
| Back to top |
|
|
ormorph
n00b
Joined: 18 Jun 2024
Posts: 27
|
| Posted: Sun Jun 30, 2024 2:07 pm Post subject: |
|
|
| mv wrote: | | What I mainly dislike for the approach is not the one public socket (I guess that this could probably be created also in a more restricted directory, e.g. in /run for which you can set more fine-grained permissions), but mainly the need to link the file at startup: There is no nice place for this linking. Doing it at every startup of an init-shell (or even of every shell?) is rather wrong, as using sound from some unprivileged user is logically not coupled to using a shell. |
All rights can be configured in the same way, this can also be done in a script and in /etc/profile.d. By the way, the script in /etc/profile.d is launched only in a new session after entering the login; it does not apply to each bash shell. Here it's up to you to decide how to set it up. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sun Jun 30, 2024 3:14 pm Post subject: |
|
|
If you want to set/change volume from a script you could do the following in a script and set keys to raise/lower the volume.
wpctl set-volume @DEFAULT_AUDIO_SINK@ 10%+
wpctl get-volume @DEFAULT_AUDIO_SINK@
@DEFAULT_AUDIO_SINK@ is the current output audio device
My headphones report the battery level, but not by way of the kernel, but bluetoothctl shows it.
/usr/bin/bluetoothctl info B4:9A:95:51:E9:DA | awk '/Battery/ { gsub(/[()]/,""); print "Battery: " $NF }'
My bluetooth trackpad reports batt level in the /sys/ directories, but not in bluetoothctl. Every device is different. ~le sigh~
Edit to add: as usual arch wiki has helpful hints
https://wiki.archlinux.org/title/PipeWire
https://wiki.archlinux.org/title/WirePlumber
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Jun 30, 2024 3:23 pm Post subject: |
|
|
| ormorph wrote: | | All rights can be configured in the same way. |
You are right: You can just replace the tcpd by a socket in a directory /run/pipewire generated by /etc/tmpfiles.d, and the socket will be automatically generated with 777 permissions (and access can be configured by the parent directory's permissions setup in /etc/tmpfiles.d).
The linking stuff is not necessary at all if you just want to use the sound input/output for the unprivileged user.
I thought that I had tried this before I tried the tcp approach and it did not work, but apparently I had made a mistake then (or something was different at the time when I had tried).
So I agree that you can just replace the tcp by a fixed socket and have practically the same. And pavucontrol then works (even for the unprivileged user). |
|
| Back to top |
|
|
ormorph
n00b
Joined: 18 Jun 2024
Posts: 27
|
| Posted: Sun Jun 30, 2024 3:51 pm Post subject: |
|
|
Also pay attention to this line: link
This line is absolutely necessary if you need to listen to sound not only pulseaudio but also through alsa and jack. Actually, the PULSE_SERVER variable is most needed for adjusting the pulseaudio sound, and for playing, a link to pipewire-0 is enough. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun Jun 30, 2024 4:14 pm Post subject: |
|
|
| ormorph wrote: | | Also pay attention to this line: link |
This was exactly my point that I did not need this line for the the tcp approach, and it seems that it is also not needed for the socket approach.
| Quote: | | This line is absolutely necessary if you need to listen to sound not only pulseaudio but also through alsa and jack. |
It is not if you start pipewire as a user (instead of as a daemon with separate privileges). Moreover, alsa is not related with this at all with pipewire[-pipewire-alsa]. I do not use jack, so cannot tell anything about that.
| Quote: | | and for playing, a link to pipewire-0 is enough. |
Nope, it is not, at least for applications using pulse for output. The observation that just changing the permissions and adjusting XDG_RUNTIME_DIR was not enough to have sound output with the unprivileged user was my reason to be active in this thread (which eventually led me to use the tcp approach in the first place). |
|
| Back to top |
|
|
ormorph
n00b
Joined: 18 Jun 2024
Posts: 27
|
| Posted: Sun Jun 30, 2024 4:39 pm Post subject: |
|
|
| mv wrote: | | It is not if you start pipewire as a user (instead of as a daemon with separate privileges). Moreover, alsa is not related with this at all with pipewire[-pipewire-alsa]. I do not use jack, so cannot tell anything about that. |
I know this from the example of using docker, there it is enough to mount pipewire-0 to get sound, the main thing is that pipewire is installed. I absolutely do not need to use the PULSE_SERVER variable to play sound if I run the OS in docker. If pipewire is running under the current user, of course this link is not needed. |
|
| Back to top |
|
|
|
Multimedia
