pipewire issueshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues2022-03-16T11:21:34Zhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2207general protection fault in libpipewire-module-protocol-pulse.so2022-03-16T11:21:34ZJakub Buriánekgeneral protection fault in libpipewire-module-protocol-pulse.so<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): pipewire
Compiled with libpipewire 0.3.47
Linked with libpipewire 0.3.47
- Distribut...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): pipewire
Compiled with libpipewire 0.3.47
Linked with libpipewire 0.3.47
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): openSUSE Leap 15.3
- Desktop Environment: KDE Plasma 5.18.6
- Kernel version (`uname -r`): 5.17.0-rc7-lp153.2.g04b7727-default (happened also on 5.16)
## Description of Problem:
Pipewire crashes when changing audio volume, killing all audio.
## How Reproducible:
Keep changing audio volume
# Additional Info (as attachments):
- dmesg:
```
[16930.385734] show_signal_msg: 7 callbacks suppressed
[16930.385738] pipewire-pulse[1781]: segfault at 64692e6e6f91 ip 00007f392f4fdf78 sp 00007ffd0a160750 error 4 in libpipewire-module-protocol-pulse.so[7f392f4d4000+77000]
[16930.385746] Code: ff e9 29 ff ff ff e8 87 f8 fd ff 0f 1f 80 00 00 00 00 41 55 41 54 55 48 89 f5 53 48 89 fb 48 83 ec 08 48 8b 47 18 48 8b 7d 58 <8b> 70 28 e8 d0 23 fe ff 41 89 c5 48 8d 05 3e 16 25 00 48 8b 30 48
[16930.960550] traps: pipewire-pulse[25561] general protection fault ip:7fdedf70df78 sp:7fff894652e0 error:0 in libpipewire-module-protocol-pulse.so[7fdedf6e4000+77000]
```
- `pw-dump > pw-dump.log`: [pwdump.txt](/uploads/ada3710809a37bad9acc44150b82579f/pwdump.txt)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2205No LFE output without Center channel2022-08-10T15:05:50ZzerfixNo LFE output without Center channel- PipeWire version: `pipewire 0.3.48, Compiled with libpipewire 0.3.48, Linked with libpipewire 0.3.48`
- OS: `EndeavourOS` (Archlinux)
- Desktop Environment: `Sway 1.7`
- Kernel version: `5.16.13`
- Sound card: `Asus Strix Raid DLX`
##...- PipeWire version: `pipewire 0.3.48, Compiled with libpipewire 0.3.48, Linked with libpipewire 0.3.48`
- OS: `EndeavourOS` (Archlinux)
- Desktop Environment: `Sway 1.7`
- Kernel version: `5.16.13`
- Sound card: `Asus Strix Raid DLX`
#### Procedures:
- Output profiles are configured in `pavucontrol`
- Test sounds are made with `speaker-test -c 6`
### Description of Problem:
I have a 4.1 setup using 3 minijac outputs from my soundcard. The center/sub output is connected directly to my sub with both L and R.
If i set profile to 4.1 or 2.1, Center is correctly heard from the front speakers but LFE is nowhere to be heard.\
But if i set profile to 5.1 or 7.1, both Center and LFE can be heard from the subwoffer.
### Speculation:
It might be that my soundcard expects only the setups exposed in windows, where you can only chose 2.0, 4.0, 5.1 or 7.1. But in windows you can disable the Center speaker after selecting 5.1, so every program thinks the system has 5.1 but windows moves the Center output to the front speakers. Is there perhaps a way to configure a 6 channel 4.1 where pipewire is configured to 4.1, but adds a silent Center channel before sending it to the sound card?
### Additional Info (as attachments):
[pw-dump.log](/uploads/34e6f97b99e5769e822694ee11d92797/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2204pipewire without systemd2022-03-11T18:02:23ZElimar Riesebieterpipewire without systemdIs it possible to run pipewire on a non systemd system like Devuan?Is it possible to run pipewire on a non systemd system like Devuan?https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2203Audio dropouts and GUI popups due to output auto switching2022-10-02T12:17:46ZNikos ChantziarasAudio dropouts and GUI popups due to output auto switching<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
pipewire
Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
pipewire
Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
Gentoo Linux
- Desktop Environment:
KDE Plasma 5.24.3
- Kernel version (`uname -r`):
5.15.27-gentoo
## Description of Problem:
Today I went through the procedure and switched my system from pulseaudio to pipewire. Unfortunately, I have random audio dropouts accompanied by a KDE popup showing the audio output name in the middle of the screen. This is due to jack auto-sensing. I have one of those mainboards with either a buggy BIOS or other issue, where the integrated audio reports phantom jack connection events. Like it reports that headphones have been connected, only to report a headphone jack disconnect a few milliseconds later.
This seems to be a somewhat common problem many other people have as well. The solution I found is to edit `/etc/pulse/default.pa` and comment out this line:
```
load-module module-switch-on-port-available
```
This completely fixed the problem and finally I was able to get nice, clean audio.
Now that I switched to pipewire, the problem is back. There doesn't seem to be any option anywhere to disable automatic switching of ports so my audio is broken again. There needs to be a setting to disable automatic port switching.
## How Reproducible:
100%.
### Steps to Reproduce:
1. Get one of the mainboards that has this problem. In my case, an MSI B550-A Pro.
2. Play audio.
3. Get annoyed by audio dropouts and GUI popups.
### Actual Results:
Audio dropouts and GUI popups.
### Expected Results:
No audio dropouts and no GUI popups.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/fc89edcc7102524cb8227c0dd1d1b3a5/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2201module-ladspa-sink, module-roc-sink: Cannot set device.description with pactl2022-03-11T08:59:07ZJan Sieber-Taegertmodule-ladspa-sink, module-roc-sink: Cannot set device.description with pactl<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48
- Distribution and ...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
"Debian GNU/Linux 11 (bullseye)"
- Desktop Environment:
Gnome Shell 3.38.5
- Kernel version (`uname -r`):
5.10.0-11-amd64
## Description of Problem:
If I try to set my own devices description with pactl, I always get something which seems to be derived from the given sink name (ladspa-sink) or hardcoded (roc-sink).
The issue is similar to [2166](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2166) and affects probably other virtual sinks too.
## How Reproducible:
Try something like:
`pactl load-module module-ladspa-sink sink_name=audioanlage.trx+sc4 master=audioanlage.trx plugin=/usr/lib/ladspa/sc4_1882.so label=sc4 control=0.5,20,500,-25,5,1,5 device.description="'Audioanlage (TRX) + Kompr.'"`
Resulting description = `"audioanlage.trx+sc4 Sink"`
`pactl load-module module-roc-sink remote_ip=192.168.2.102 sink_name=audioanlage.roc device.description="'Audioanlage (ROC) + Kompr.'" `
Resulting description = `"ROC Sink"`
### Expected Results:
Result should be that given in the pactl - command.
Thanks,
Jan.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2200Pipewire resetting to stereo output after device change.2022-05-12T20:32:07ZSojiro84Pipewire resetting to stereo output after device change.- PipeWire version: Compiled with libpipewire 0.3.48 | Linked with libpipewire 0.3.48
- Distribution: EndeavourOS (Arch)
- Desktop Environment: KDE Plasma 5.24.3
- Kernel version: 5.16.10-zen1-1-zen
## Description of Problem:
Audio prof...- PipeWire version: Compiled with libpipewire 0.3.48 | Linked with libpipewire 0.3.48
- Distribution: EndeavourOS (Arch)
- Desktop Environment: KDE Plasma 5.24.3
- Kernel version: 5.16.10-zen1-1-zen
## Description of Problem:
Audio profile gets reset to stereo (from 5.1) after a device change.
## How Reproducible:
In my situation, I have a TV that is connected to a receiver. That receiver is then connected to my PC.
Whenever I turn my TV on or off, the audio profile gets reset from whatever it was to stereo.
### Steps to Reproduce:
1. Turn TV on or off.
2. Wait for desktop to notice the device status change.
3. See your selected 5.1 profile reset back to stereo.
# Additional Info (as attachments):
- [pw-dump.log](/uploads/e940e82bd453a962bc712d813df87195/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2199clock.allowed-rates and clock.force-rate not working2023-08-15T01:17:20ZFilip K.clock.allowed-rates and clock.force-rate not working<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.48
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.48
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Ubuntu 20.04.4 LTS
- Desktop Environment: Regolith Linux
- Kernel version (`uname -r`): 5.4.0-104-generic
## Description of Problem:
Trying to change the sample rate for my Schiit ES9028 DAC using `clock.allowed-rates` or `clock.force-rate` does not work. Changing `default.clock.rate` does work.
## How Reproducible:
Always.
### Steps to Reproduce:
1. Stage local pipewire.conf such that
```
diff /usr/share/pipewire/pipewire.conf ~/.config/pipewire/pipewire.conf
30c30
< #default.clock.allowed-rates = [ 48000 ]
---
> default.clock.allowed-rates = [ 48000 96000 ]
```
2. Restart `pipewire{,-pulse}.{socket,service}`, verify that the setting is read,
```
pw-metadata -n settings
Found "settings" metadata 30
update: id:0 key:'log.level' value:'2' type:''
update: id:0 key:'clock.rate' value:'48000' type:''
update: id:0 key:'clock.allowed-rates' value:'[ 48000, 96000 ]' type:''
...
```
3. Start VLC and play a 96kHz file. See that the sample rate is not adjusted
```
cat /proc/asound/card1/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 512
buffer_size: 131072
```
I also tried `pw-metadata -n settings 0 clock.force-rate 96000` and the result is the same: 48kHz. Setting `default.clock.rate` to 96kHz in `pipewire.conf` works as expected.
### Expected Results:
Adjusting the sample rate using `clock.allowed-rates` or `clock.force-rate` should work.
# Additional Info (as attachments):
- [pw-dump.log](/uploads/c34c0e032d908b19bd169b6b5d434159/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2198Surround sound upmix not working correctly after latest update2022-04-13T11:06:15ZMagnus LarsenSurround sound upmix not working correctly after latest update<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
Starters: this seem very related too https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2083
- PipeWire version (`pipewi...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
Starters: this seem very related too https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2083
- PipeWire version (`pipewire --version`):
```
pipewire
Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48
```
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Ubuntu 21.10
- Desktop Environment: KDE Plasma
- Kernel version (`uname -r`): 5.16.11-051611-generic
- Speaker setup: 5.1
- Session manager: Wireplumber 0.4.8.r20.gb95da33-1~ubuntu21.10
## Description of Problem:
Upmixing of 2.0 audio (through Firefox) is "clipping" in rear speakers, and LFE channel is enabled, but only when using the "Digital Surround 5.1" profile in `pavucontrol` - selecting the "Digital Surround 7.1" fixes the clipping in rear channels, but still leaves LFE channel active (I assume because my AVR is upmixing).
With "clipping" I specifically mean that only treble is going through to the rear speakers, and voices clip/break constantly - they sound like the sound is going through a can.
Playing 5.1/7.1 content through Kodi (or the likes of VLC) correctly plays with no clipping. Testing channels in pavucontrol also correctly plays on all speakers
Here is the relevant settings (I believe):
```
{ name = libpipewire-module-protocol-pulse
args = {
pulse.default.position = [ FL FR RL RR FC LFE ]
...
stream.properties = {
resample.quality = 10
channelmix.mix-lfe = false
channelmix.upmix = true
}
```
## How Reproducible:
### Steps to Reproduce:
1. Select "Digital Surround 5.1" audio profile in pavucontrol
2. Play 2.0 audio content through Firefox (I used youtube.com and open.spotify.com) (clipping)
3. Play 5.1/7.1 audio content through Kodi/VLC (no clipping)
### Actual Results:
No "clipping" in rear channels, and the LFE to stay disabled (as the channelmix option is set)
### Expected Results:
"Clipping" in rear channels, and LFE is active
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:
[2-0-audio.log](/uploads/88a0ab7418703f4d342e719096ed7cca/2-0-audio.log)
[7-1-audio.log](/uploads/afae6844e4c5d47fdb24c846437ecf54/7-1-audio.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2197No audio for notifications (call, message, etc) while using Discord2022-12-14T09:41:41ZRandallNo audio for notifications (call, message, etc) while using Discord<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.48
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.48
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Gentoo/Linux
- Desktop Environment: KDE
- Kernel version (`uname -r`): 5.15.26-gentoo
## Description of Problem:
Discord notifications (incoming call, outgoing call, messages, etc) don't have audio while using Pipewire. Call audio still works, however, though you don't hear the ringing.
## How Reproducible:
Apparently, it's a known issue, and there are a few places to find a fix. The best resource I found was: https://www.reddit.com/r/archlinux/comments/t45chj/discord_pipewire_no_notification_sounds/, which basically states to fix, you need to...
### Steps to Reproduce:
1: Update `pulse.min.quantum` in `/etc/pipewire/pipewire-pulse.conf` (which needs to be copied there in Gentoo), mine is [here](https://834687.bugs.gentoo.org/attachment.cgi?id=766441).
2: Restart Pipewire (which I'm doing with systemd via `systemctl --user restart pipewire`)
### Actual Results:
That does fix the issue with the audio for notifications, however, it causes another issue with WebRTC and Discord; in which, Discord will not connect to calls anymore and be stuck on "WebRTC Connecting" essentially breaking the most important functionality. However, this can be fixed with quitting Discord fully, and relaunching. Audio notifications will now work; but will stop working again if you log out or restart, which at that point Step #2 would need to be repeated.
### Expected Results:
Working audio notifications
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/19850509ba84a97de1f3347a6958b3b0/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2196Pipewire as system service with PA tunnel needs clear documentation2022-05-19T07:20:53ZJasper MackenziePipewire as system service with PA tunnel needs clear documentation- PipeWire version (`pipewire --version`):
```
pipewire
Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48
```
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): `Ubuntu Jammy Jellyfish (develop...- PipeWire version (`pipewire --version`):
```
pipewire
Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48
```
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): `Ubuntu Jammy Jellyfish (development branch)`
- Desktop Environment: `kodi`
- Kernel version (`uname -r`): `5.15.0-18-generic`
## Description of Problem:
I have not been able to successfully configure Pipewire in a _system mode_ similar to that of Pulseaudio. There are hints that this should be possible, but nothing I have tried succeeds.
I am happy to update the documentation and wiki with support received here and otherwise.
### What I am trying to achieve
I have a _server_ running Kodi, a Bluetooth receiver, and I wish to stream audio from laptops on the local network using the Pulseaudio Tunnel. Ideally I would like to do this in a Pipewire native manner so I can use the patchbays etc so I can add delays and eq.
## How Reproducible:
I have had no success playing audio using Pipewire from fresh install.
### Steps to Reproduce:
1. Install Ubuntu Jammy with minimal packages
2. Ensure Pipewire is installed `sudo apt install pipewire pipewire-pulse wireplumber`
3. Add the `pipewire` group and user:
```bash
sudo addgroup --gid 901 pipewire
sudo adduser --system --uid 091 --gid 901 pipewire
```
5. Create `pipewire` directory in `/etc`:
```bash
sudo mkdir /etc/pipewire
```
4. Copy the system wide profiles from into `/etc/systemd/system` and
```bash
# clone pipewire somewhere
sudo cp -a ~/src/pipewire/src/daemon/systemd/system/pipewire.service.in /etc/systemd/system/pipewire.service
sudo cp -a ~/src/pipewire/src/daemon/systemd/system/pipewire.socket /etc/systemd/system/
```
5. Edit to be:
```
[Unit]
Description=PipeWire Multimedia Service
# We require pipewire.socket to be active before starting the daemon, because
# while it is possible to use the service without the socket, it is not clear
# why it would be desirable.
#
# Installing pipewire and doing `systemctl start pipewire` will not get the
# socket started, which might be confusing and problematic if the server is to
# be restarted later on, as the client autospawn feature might kick in. Also, a
# start of the socket unit will fail, adding to the confusion.
#
# After=pipewire.socket is not needed, as it is already implicit in the
# socket-service relationship, see systemd.socket(5).
Requires=pipewire.socket
[Service]
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
RestrictNamespaces=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
Type=simple
AmbientCapabilities=CAP_SYS_NICE
#ExecStart=@PW_BINARY@
ExecStart=/usr/bin/pipewire
Restart=on-failure
RuntimeDirectory=pipewire
RuntimeDirectoryPreserve=yes
User=pipewire
Environment=PIPEWIRE_RUNTIME_DIR=%t/pipewire
# Added for debugging
Environment=PIPEWIRE_DEBUG=4
[Install]
Also=pipewire.socket
WantedBy=default.target
```
6. Disable user services and enable system services:
```bash
sudo systemctl daemon-reload
systemctl --user disable --now pipewire-pulse.socket pipewire-pulse.service pipewire.service wireplumber.service
sudo systemctl enable pipewire.socket pipewire.service # wireplumber?
sudo systemctl start pipewire.socket pipewire.service
sudo systemctl status pipewire.socket
● pipewire.socket - PipeWire Multimedia System Socket
Loaded: loaded (/etc/systemd/system/pipewire.socket; disabled; vendor preset: enabled)
Active: active (running) since Tue 2022-03-08 19:52:13 NZDT; 2min 11s ago
Triggers: ● pipewire.service
Listen: /run/pipewire/pipewire-0 (Stream)
Tasks: 0 (limit: 9350)
Memory: 0B
CPU: 1ms
CGroup: /system.slice/pipewire.socket
Mar 08 19:52:13 nuliayuk systemd[1]: Starting PipeWire Multimedia System Socket...
Mar 08 19:52:13 nuliayuk systemd[1]: Listening on PipeWire Multimedia System Socket.
systemctl status pipewire.service
● pipewire.service - PipeWire Multimedia Service
Loaded: loaded (/etc/systemd/system/pipewire.service; disabled; vendor preset: enabled)
Active: active (running) since Tue 2022-03-08 19:54:58 NZDT; 19s ago
TriggeredBy: ● pipewire.socket
Main PID: 2928 (pipewire)
Tasks: 2 (limit: 9350)
Memory: 1.1M
CPU: 13ms
CGroup: /system.slice/pipewire.service
└─2928 /usr/bin/pipewire
Mar 08 19:54:58 nuliayuk pipewire[2867]: spa.system: 0x5610450d2368: close fd:8
Mar 08 19:54:58 nuliayuk pipewire[2867]: spa.system: 0x5610450d2368: close fd:6
Mar 08 19:54:58 nuliayuk pipewire[2867]: spa.system: 0x5610450d2368: close fd:7
Mar 08 19:54:58 nuliayuk pipewire[2867]: spa.system: 0x5610450d2368: close fd:5
Mar 08 19:54:58 nuliayuk pipewire[2867]: pw.context: clear handle 'support.system'
Mar 08 19:54:58 nuliayuk systemd[1]: pipewire.service: Deactivated successfully.
Mar 08 19:54:58 nuliayuk systemd[1]: Stopped PipeWire Multimedia Service.
Mar 08 19:54:58 nuliayuk systemd[1]: Started PipeWire Multimedia Service.
Mar 08 19:54:58 nuliayuk pipewire[2928]: spa.dbus: Failed to connect to session bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 08 19:54:58 nuliayuk pipewire[2928]: mod.portal: Failed to connect to session bus: Input/output error
```
7. Try to add TCP tunnel etc and see if anything improves:
```
sudo cp -a /usr/share/pipewire/pipewire.conf /etc/pipewire/
sudo vim /etc/pipewire/pipewire.conf
```
add
```
context.modules = [
...
{ name = libpipewire-module-protocol-pulse
args = {
# the addresses this server listens on
server.address = [
"unix:native"
#"unix:/tmp/something" # absolute paths may be used
"tcp:4713" # IPv4 and IPv6 on all addresses
#"tcp:[::]:9999" # IPv6 on all addresses
#"tcp:127.0.0.1:8888" # IPv4 on a single address
#
#{ address = "tcp:4713" # address
# max-clients = 64 # maximum number of clients
# listen-backlog = 32 # backlog in the server listen queue
# client.access = "restricted" # permissions for clients
#}
]
#pulse.min.req = 256/48000 # 5ms
#pulse.default.req = 960/48000 # 20 milliseconds
#pulse.min.frag = 256/48000 # 5ms
#pulse.default.frag = 96000/48000 # 2 seconds
#pulse.default.tlength = 96000/48000 # 2 seconds
#pulse.min.quantum = 256/48000 # 5ms
#pulse.default.format = F32
#pulse.default.position = [ FL FR ]
# These overrides are only applied when running in a vm.
vm.overrides = {
pulse.min.quantum = 1024/48000 # 22ms
}
}
}
{ name = libpipewire-module-zeroconf-discover }
```
restart pipewire
```bash
sudo systemctl restart pipewire.service
systemctl status pipewire.service
● pipewire.service - PipeWire Multimedia Service
Loaded: loaded (/etc/systemd/system/pipewire.service; disabled; vendor preset: enabled)
Active: active (running) since Tue 2022-03-08 20:05:52 NZDT; 17s ago
TriggeredBy: ● pipewire.socket
Main PID: 3122 (pipewire)
Tasks: 3 (limit: 9350)
Memory: 2.6M
CPU: 27ms
CGroup: /system.slice/pipewire.service
└─3122 /usr/bin/pipewire
Mar 08 20:05:52 nuliayuk systemd[1]: Started PipeWire Multimedia Service.
Mar 08 20:05:52 nuliayuk pipewire[3122]: spa.dbus: Failed to connect to session bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 08 20:05:52 nuliayuk pipewire[3122]: mod.portal: Failed to connect to session bus: Input/output error
Mar 08 20:05:52 nuliayuk pipewire[3122]: mod.protocol-pulse: could not find a suitable runtime directory in$PULSE_RUNTIME_PATH and $XDG_RUNTIME_DIR
Mar 08 20:05:52 nuliayuk pipewire[3122]: mod.protocol-pulse: pulse-server 0x5570c66cf500: failed to parse address 'unix:native': No such file or directory
Mar 08 20:05:52 nuliayuk pipewire[3122]: mod.protocol-pulse: could not find a suitable runtime directory in$PULSE_RUNTIME_PATH and $XDG_RUNTIME_DIR
Mar 08 20:05:52 nuliayuk pipewire[3122]: mod.protocol-pulse: 0x5570c66cf500: can't create pid file: No such file or directory
Mar 08 20:05:52 nuliayuk pipewire[3122]: spa.dbus: Failed to connect to session bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 08 20:05:52 nuliayuk pipewire[3122]: mod.pulse-tunnel: failed to connect: Access denied
Mar 08 20:05:52 nuliayuk pipewire[3122]: mod.zeroconf-discover: Can't load module: Operation not permitted
```
### Actual Results:
```bash
pactl info | grep '^Server Name'
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
```
### Expected Results:
I would expect that _everything just works_.
# Additional Info (as attachments):
- `[pw-dump.log](/uploads/f33b3a424ef158e1a23bcbee45b38b93/pw-dump.log)`:
*note:* that despite being disabled, the user socket and service start anyway. My bad for not understanding systemd properly 8(https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2195"Curtaining" audio for remote connection2022-05-12T18:45:24ZErik Jensen"Curtaining" audio for remote connectionLet me know if there's a better discussion forum for this kind of question.
I'm on a team working on a remote access tool, and we're looking for a way to forward all audio to the client machine without it being audible on the remote mac...Let me know if there's a better discussion forum for this kind of question.
I'm on a team working on a remote access tool, and we're looking for a way to forward all audio to the client machine without it being audible on the remote machine itself.
In the near term, I imagine this would involve creating a virtual output device and forcing all streams to go to that virtual output device while a remote user is connected, including streams that have been explicitly moved to a specific physical output in the past. However, I'm not sure how exactly to accomplish this, as merely setting the default output device is not always sufficient. This seems like the kind of logic a session manager is designed to handle, and indeed the high-level overview of WirePlumber makes it sounds like it could be used to accomplish what I'm looking for, but it's not obvious to me from the API reference documentation how I would accomplish this, and I haven't been able to find any higher-level API tutorials to get me started. Can the WirePlumber API be used to accomplish what I'm looking for, and if not, is there a better way to go about it?
Longer term, we've had a couple of preliminary discussions with some Wayland and GNOME folks about having first-class support for graphical session curtaining, where a single graphical session can be transition from a local console session to a headless session (if the user connects to the session remotely) and back to a console session (if the user logs in on the console again later). In that case, I imagine it would make sense for PipeWire to integrate into the same system, curtaining audio when the session is running headless, and playing on the local speakers when it is attached to the console. What's the best way to start planning out how this will look architecturally?
Thanks!https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2194Wrong default sample rate on CA0132 (SoundBlaster Z)2022-03-25T12:36:08ZArturo CasalWrong default sample rate on CA0132 (SoundBlaster Z)<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.48
- PipeWire session manager: wireplumber at [master](https://gitlab.freedeskto...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.48
- PipeWire session manager: wireplumber at [master](https://gitlab.freedesktop.org/pipewire/wireplumber/-/commit/b95da3393c0573a31b51e6e8f8f06f059abf206a)
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Manjaro Linux
- Desktop Environment: KDE Plasma 5.24.1
- Kernel version (`uname -r`): 5.16.11-2-MANJARO
## Description of Problem:
The audio channels sent to the CA0132 Analog should be at 96Khz, otherwise the card's DSP can't process the sound correctly. Listen to attached file.
## How Reproducible:
100% of the time. It happens even with pulseaudio when the sample rate is not 96Khz.
If I change the default sample rate (default.clock.rate) to 96000, sound works perfect.
### Steps to Reproduce:
1. Use a SoundBlaster Z (I think other CA0132 devices are affected, but could not try it)
2. Configure it in pulseaudio as "Analog Stereo Duplex"
3. Play some music
### Actual Results:
Audio played sounds kind of "metallic". Listen to attached file.
If I change the card configuration from "Analog Stereo Duplex" to "Analog Surround 2.1 Output" the sound improves, but has some "metallic" noise too. In the attached file I change between "Analog Surround 2.1 Output" (best sound) and "Analog Stereo Duplex" (worst sound).
### Expected Results:
Audio is played correctly.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:[pw-dump.json](/uploads/d9ffad0a0990fd6d7923af7cbfe4502c/pw-dump.json)
- ![ca0132_at_48Khz.ogg](/uploads/e71662ff8d1b030f731a9c37a08cb474/ca0132_at_48Khz.ogg)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2193Lisa: the painful cant open OpenAL device2022-03-07T20:29:46ZNiki TurkinLisa: the painful cant open OpenAL device<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.48
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.48
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment:KDE Plasma
- Kernel version (`uname -r`): 5.16.12-arch1-1
## Description of Problem:
When starting the game Lisa: The Painful on steam it will try to access an OpenAL device which it fails to giving the error "Error opening OpenAL device",
after that it crashes the game.
## How Reproducible:
100% reproducible of the time
### Steps to Reproduce:
1. Start Lisa the painful on steam
2. wait sometime for it to load
3. get error "Error opening openAL device"
### Actual Results:
game crashes because its unable to open OpenAL device
### Expected Results:
game starts normally
# Additional Info (as attachments):
i have tested it and Lisa: the painful does work on 0.3.47.
- `pw-dump > pw-dump.log`:[pw-dump.log](/uploads/5e7db52b88ad147ae4d066a8faf7b9ee/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2191Improve troubleshooting docs for VMs2022-04-01T08:37:16ZshoffmeisterImprove troubleshooting docs for VMsIt might be helpful to amend the troubleshooting documentation at https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting on two points:
a) Existing "Stuttering Audio in Virtual Machine"
The current docs link to a foru...It might be helpful to amend the troubleshooting documentation at https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting on two points:
a) Existing "Stuttering Audio in Virtual Machine"
The current docs link to a forum comment implying configuring pipewire. The current operating model, though, seems to be configuration through wireplumber.
Working wireplumber configuration steps on Fedora 35 are
```
mkdir -p ~/.config/wireplumber/main.lua.d
cd ~/.config/wireplumber/main.lua.d
cp /usr/share/wireplumber/main.lua.d/50-alsa-config.lua .
```
then open `~/.config/wireplumber/main.lua.d/50-alsa-config.lua` in an editor and tweak the configuration at the very bottom of the file to suit the needs; for me
```
["api.alsa.period-size"] = 1024,
["api.alsa.headroom"] = 8192,
```
works. Afterwards, restart everything via `systemctl --user restart wireplumber pipewire pipewire-pulse`
b) New for "Firefox - speech dispatcher"
Firefox ships with Reader enabled, which is enabled for speech synthesis (read text aloud). Alas, with this merely enabled, Firefox will make pipewire hog CPU resources inside the VM.
To compensate, turn off relevant settings in Firefox by opening the `about:config` URL in Firefox, configure the settings as found below, then restart Firefox.
```
reader.parse-on-load.enabled false
media.webspeech.synth.enabled false
```https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2189No sound after update to 0.3.482022-07-15T07:18:16ZJordan LowranceNo sound after update to 0.3.48<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.48, just updated from 0.3.43
- Distribution and distribution version (`PRETTY_NA...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.48, just updated from 0.3.43
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):Pop!_OS 21.10
- Desktop Environment:KDE5
- Kernel version (`uname -r`):5.16.11-76051611-generic
## Description of Problem:
After building and installing the new pipewire version 0.3.48, I no longer have any sound or audio settings at all.
pipewire and wireplumber services are both running.
Software such as easyeffects and pavucontrol fail to open.
## How Reproducible:
Unsure
# Additional Info (as attachments):
[pw_dump.txt](/uploads/d267746377e4b72bee0f867d7d46aa75/pw_dump.txt)
![image](/uploads/e533dc8887505e78b818b248fcbf2a5e/image.png)
(empty audio settings panel)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2188Momentary muting at start of playback2022-05-07T11:37:41ZD JMomentary muting at start of playbackHi,
I'm using pipewire 0.3.47 with ArchLinux 5.16.11-arch1-1 and SwayWM 1.7.
When I start audio, I find there is a short (normally << 1second and sometimes about 1s) period during which the sound from the speakers is heavily suppressed...Hi,
I'm using pipewire 0.3.47 with ArchLinux 5.16.11-arch1-1 and SwayWM 1.7.
When I start audio, I find there is a short (normally << 1second and sometimes about 1s) period during which the sound from the speakers is heavily suppressed (as if I were hearing it through headphones lying on my desk). Obviously there are no headphones connected by wire or bluetooth. This is most noticeable when listening to Zoom conversations where, after a period of silence, it's frequent to hear the muting/suppression effect for the first ~1s of speech.
What information can I collect to help with debugging this?
Thanks in advance!https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2187Low volume on media players on 0.3.472022-03-04T14:18:43ZJuan PiñeiroLow volume on media players on 0.3.47<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.47
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.47
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Fedora Linux 35.20220302.0 (Silverblue)
- Desktop Environment: GNOME
- Kernel version (`uname -r`): 5.16.11-200.fc35.x86_64
## Description of Problem:
Similar to #2121 but problem persists after trying given solution.
Low volume output playing E-AC-3 videos through Jellyfin on Firefox and VLC, mpv as well
Streaming sites like Youtube or Netflix are not affected by this volume bug.
This has only been tested using standard stereo audio equipment (laptop speakers and headphones).
## How Reproducible:
Playing videos on Jellyfin on a browser, or using VLC and other media players, the volume output is very low.
### Proposed solution
Changing `channelmix.normalize = true` to `false` on `client.conf` and `client-rt.conf` then restarting pipewire with `systemctl --user restart pipewire pipewire-pulse`.
The low output volume still persists.
### Current solution
Downgrade to `0.3.38`https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2186Chrome unable to see microphone (bluetooth headset) unless restarted2022-04-12T06:30:16ZreubenfirminChrome unable to see microphone (bluetooth headset) unless restarted<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
Compiled with libpipewire 0.3.47
Linked with libpipewire 0.3.47
- Distribution and ...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
Compiled with libpipewire 0.3.47
Linked with libpipewire 0.3.47
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
Ubuntu 21.10
- Desktop Environment:
KDE
- Kernel version (`uname -r`):
5.13.0-30-generic
## Description of Problem:
This started happening on 0.3.47. When I join a google meet with Chrome, the microphone icon is often crossed out, and Chrome claims it cannot see the device. When I restart Chrome, it's then able to see my mic.
This _might_ be associated with the device turning itself off (and subsequently being powered back on and reconnecting) - I'll watch for this and update.
## How Reproducible:
Happens multiple times a day.
### Steps to Reproduce:
1. Take multiple google meet meetings throughout the day with chrome and a bluetooth headset(?)
2.
3.
# Additional Info (as attachments):
- `[pw-dump.log](/uploads/fbec09e1b7eb2b0897a880d7fb04c98f/pw-dump.log)`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2185Only Dummy Output device shown in pavucontrol2022-07-15T07:18:16ZJacob BeardOnly Dummy Output device shown in pavucontrol * PipeWire version (pipewire --version): 0.3.47
* Distribution and distribution version (PRETTY_NAME from /etc/os-release): Pop!_OS 21.10
* Desktop Environment: Gnome
* Kernel version (uname -r): 5.15.15-76051515-generic
... * PipeWire version (pipewire --version): 0.3.47
* Distribution and distribution version (PRETTY_NAME from /etc/os-release): Pop!_OS 21.10
* Desktop Environment: Gnome
* Kernel version (uname -r): 5.15.15-76051515-generic
## Description of Problem:
pavucontrol shows only dummy device.
## How Reproducible:
On my hardware (System76 Lemur Pro) it happens all the time.
### Steps to Reproduce:
1. Start pipewire with `systemctl --user start pipewire.service pipewire.socket`
2. Start pavucontrol
### Actual Results:
The only device shown in pavucontrol is the Dummy Ouput.
### Expected Results:
Input and output devices should be listed.![Screenshot_from_2022-03-02_12-38-12](/uploads/52162b471bb9954ca9d6ddf7f5932606/Screenshot_from_2022-03-02_12-38-12.png)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2184PULSE_LATENCY_MSEC inconsistent?2022-03-03T21:45:03ZAntonio OreficePULSE_LATENCY_MSEC inconsistent?
- PipeWire version (`pipewire --version`):
pipewire
Compiled with libpipewire 0.3.45
Linked with libpipewire 0.3.45
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
Archlinux
- Desktop Environment:
kde ...
- PipeWire version (`pipewire --version`):
pipewire
Compiled with libpipewire 0.3.45
Linked with libpipewire 0.3.45
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
Archlinux
- Desktop Environment:
kde plasma
- Kernel version (`uname -r`):
5.16.8-arch1-1
## How Reproducible:
Since some day i switched to pipewire and I'm using kde plasma.
It produces a "click" when you press a key combination to chenge the volume.
Immediately after installing pipewire i noticed an higher lag between the keypress and the audible notification.
inspecting with pw-top revealed that the quantum used ny libcanberra (pulse) and the alsa device is 1024.
If i do my math correctly, 1024 should be around 21ms at 48khz: 1000/(48000/1024)=21.33
But to get comparable results,by ear, i need to lower it to around 256, which seems overkill to me!
Experimenting with PULSE_LATENCY_MSEC=xx paplay sound.wav and pw-top, I also discovered that to reach 20msecs
PULSE_LATENCY_MSEC=23 : 254-256
PULSE_LATENCY_MSEC=46 : 507-512
PULSE_LATENCY_MSEC=86 ; 1014-1024 #<--- which is consistent with my experience with sound applet notification!
So, if I'm reading things right, setting a quantum of 1024 translates to a default latency of about 86milliseconds which is about 4 times what it should be (1000/(48000/1024)*4=85.33), which is suspicoius to me.
Is it using 4 buffers? Is this expected?
Isn't better to have less larger buffers?
Apologies if what i wrote is all wrong, i'm just exploring pipewire.
attached pw-dump while doing PULSE_LATENCY_MSEC=86 paplay
[pw-dump.txt](/uploads/eb8f1873745e369c73854107fa8b0e43/pw-dump.txt)