pipewire issueshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues2023-05-15T13:55:02Zhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3216Sound only on headphone port while line out also plugged in2023-05-15T13:55:02ZDaniel BolingSound only on headphone port while line out also plugged in- PipeWire version (`pipewire --version`): 0.3.70
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): EndeavorOS
- Desktop Environment: KDE Plasma 5.27.5
- Kernel version (`uname -r`): 6.3.1-arch2-1
## Descri...- PipeWire version (`pipewire --version`): 0.3.70
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): EndeavorOS
- Desktop Environment: KDE Plasma 5.27.5
- Kernel version (`uname -r`): 6.3.1-arch2-1
## Description of Problem:
When an output (headphones, in my case) is plugged into LineOut on the back of Mobo and the front headphone out on the PC case, no matter changing the sound output to "Line Out" or "Headphone", sound only works when "Headphone" is selected, and that device is used. No sound works in "Line Out" under any circumstances. One "Headphone" is unplugged and "Line Out" is selected, it works as expected.
## How Reproducible:
Have any sound device plugged into several outputs on the same sound card and attempt getting sound from either individually.
### Actual Results:
Sound only works on "Headphone", not on "Line Out" unless "Line Out" is the only plugged-in device on that sound card.
### Expected Results:
Sound should work on whichever selected port, regardless of the devices plugged into the sound card.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/91372fefd11952499d5f259b1aba542b/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1133xrdp sound redirection2023-05-15T13:05:05ZRalph Bacolodxrdp sound redirectionI have installed Fedora 34 as a VM in Proxmox. I am unable to get any sound working.
Server String: /run/user/1000/pulse/native
Library Protocol Version: 34
Server Protocol Version: 35
Is Local: yes
Client Index: 38
Tile Size: 65472
Use...I have installed Fedora 34 as a VM in Proxmox. I am unable to get any sound working.
Server String: /run/user/1000/pulse/native
Library Protocol Version: 34
Server Protocol Version: 35
Is Local: yes
Client Index: 38
Tile Size: 65472
User Name: rab
Host Name: fedora
Server Name: PulseAudio (on PipeWire 0.3.26)
Server Version: 14.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: @DEFAULT_SINK@
Default Source: @DEFAULT_SOURCE@
Cookie: 9fe6:63de
I was going to follow this process https://github.com/neutrinolabs/pulseaudio-module-xrdp/wiki/README
, but I just found that PulseAudio is being replaced with Pipewire.
Can this functionality be implemented in Pipewire instead?
thanks,
Ralphhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2274Sound unbalanced to the left with pipewiresink2023-05-15T13:02:58Zlegacychimera247Sound unbalanced to the left with pipewiresinkHello, i'm using Clapper as media player which is a gtk4 media player aimed at gnome, and it has an experimental option to use for the audio, pipewiresink instead of pipewire-pulse
Now, when it uses pipewire-pulse everything is good, bu...Hello, i'm using Clapper as media player which is a gtk4 media player aimed at gnome, and it has an experimental option to use for the audio, pipewiresink instead of pipewire-pulse
Now, when it uses pipewire-pulse everything is good, but when it uses pipewiresink directly, sound is clearly unbalanced coming more from the left
Reported to clapper dev but said to report on here
In case, i'm on fedora 35 workstation and haven't changed anything from default sound configuration
And this is a link to the original thread
https://github.com/Rafostar/clapper/issues/244
Thank youhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2532pipewire-pulse: Keep connections alive during pipewire restart.2023-05-15T13:02:11ZJulian Orthpipewire-pulse: Keep connections alive during pipewire restart.<!-- 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.52
- 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.52
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch
- Desktop Environment: None
- Kernel version (`uname -r`): 5.18.0
## Description of Problem:
After having the system running for several days (with suspend in between), sound played via pipewire always starts crackling. The only solution is to restart the pipewire service. (I believe this is initially triggered by high CPU usage, e.g. compiling, but that's not what this issue is about.)
This appears to sever all connections between applications and the pipewire-pulse service. Applications usually need to be restarted to start functioning again.
pipewire-pulse should keep all connections alive until a certain timeout. During this time pipewire-pulse will try to reconnect to pipewire.
## How Reproducible:
Always.
### Steps to Reproduce:
1. Run a pulse application.
2. Restart pipewire.service.
### Actual Results:
Applications stop playing audio.
### Expected Results:
Applications resume playing audio after the restart.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2208Delays and "too many open files" errors when playing multiple sounds with sox2023-05-15T12:59:10ZJohn O'HaganDelays and "too many open files" errors when playing multiple sounds with sox<!-- 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`): Debian testing
- Desktop Environment: XFCE
- Kernel version (`uname -r`):5.16.0-3-amd64
## Description of Problem:
When multiple sox processes are launched (using the python subprocess module) to play multiple samples or synth notes simultaneously and in rapid succession, many of the sounds do not play when the sox process is launched, but instead are played several seconds later or not at all. This is accompanied by high memory use. The following errors typically appear in systemctl --user status pipewire-pulse.service:
```
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: mod.adapter: usage: node.name=<string>
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.resource: usage: node.name=<string>
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.stream: 0x5649119edeb0: can't make node: Invalid argument
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.mem: 0x564910af5790: Failed to create memfd: Too many open files
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.stream: 0x564924b70750: can't make node: Too many open files
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.mem: 0x564910af5790: Failed to create memfd: Too many open files
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.stream: 0x564913ebdae0: can't make node: Too many open files
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.mem: 0x564910af5790: Failed to create memfd: Too many open files
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.stream: 0x564912ba25d0: can't make node: Too many open files
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: mod.client-node: link 0x5649267f64c0: write failed Bad file descriptor
...
Mar 14 17:23:45 e7240 pipewire-pulse[174646]: mod.protocol-pulse: server 0x564910b05e60: failed to create client: Connection refused
Mar 14 17:23:45 e7240 pipewire-pulse[174646]: mod.protocol-pulse: server 0x564910b05e60: failed to create client: Connection refused
```
Occasionally this error also appears in dmesg:
```
[241285.570440] wireplumber[167574]: segfault at 68 ip 00007f4b5372aa70 sp 00007ffe99878308 error 4 in libpipewire-0.3.so.0.348.0[7f4b536d6000+69000]
[241285.570460] Code: 66 2e 0f 1f 84 00 00 00 00 00 48 8b 47 70 c3 66 66 2e 0f 1f 84 00 00 00 00 00 48 8b 47 60 c3 66 66 2e 0f 1f 84 00 00 00 00 00 <48> 8b 47 68 c3 66 66 2e 0f 1f 84 00 00 00 00 00 41 54 55 48 89 fd
```
Sox itself also gives the following errors multiple times:
```
play WARN alsa: can't encode 0-bit Unknown or not applicable
play FAIL formats: can't open output file `default': can not open audio device: Timeout
```
When these errors occur, the process monitor (XFCE Task manager) shows multiple residual sox processes in 'S' state. If too many samples are attempted to be played, system memory runs out.
The pavucontrol "Playback" tab shows many sox application streams, one for each sample. Many of these remain after the program playing the samples has exited, and do not disappear until pipewire is restarted.
If `-t alsa` is passed to sox to make it use the alsa device (Linux only) rather than the pulseaudio default, the issue is less severe (i.e, more samples must be played in rapid succession to trigger it), but still appears.
This used to work without problems with pulseaudio.
(BTW I am otherwise very impressed with pipewire, it solves many long-standing Linux audio issues and works well)
## How Reproducible:
100% on my system if the python snippet below is run. Less demanding code (e.g, fewer simultaneous samples or less frequently run) may not trigger the issue.
### Steps to Reproduce:
1. Run this python 3.9 snippet using a path to an audio file playable by sox:
```
import subprocess, time
for __ in range(32):
for _ in range(4):
subprocess.Popen(['play', '-q', '/path/to/audio_file'])
time.sleep(.2)
```
The issue also appears if sox synth is used, e.g. by passing ```['play', '-q', '-n', 'synth', '1', 'sine', '220']``` to Popen instead.
### Actual Results:
Sounds are initially played correctly at the scheduled time but become increasingly delayed, with errors and high memory use as set out above, until they do not play at all.
### Expected Results:
Sounds should play as soon as the sox process is launched.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:[pw_dump](/uploads/282ba776ef1dbfe312d58457a36dbb64/pw_dump)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2623Jack clients break unsless there is other audio playing2023-05-15T12:57:26ZGustawJack clients break unsless there is other audio playing<!-- 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.56, Linked with libpipewire 0.3.56
- 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.56, Linked with libpipewire 0.3.56
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: AwesomeWM wiht xfce elements
- Kernel version (`uname -r`): 5.18.16-arch1-1
## Description of Problem:
After some update - not sure which - I started having problem with launching jack applications. I discovered that I need to have some other sound application playing (like firefox, or mpv). Otherwise I get ERR in pw-top rising to crazy amounts (like 10-50 per second), WAIT, BUSY, W/Q and B/Q are +++:
```
S ID QUANT RATE WAIT BUSY W/Q B/Q ERR NAME
28 1024 96000 10,2ms 0,1µs 0,96 0,00 0 Dummy-Driver
! 77 0 0 +++ +++ +++ +++ 562 + Carla
```
```
S ID QUANT RATE WAIT BUSY W/Q B/Q ERR NAME
! 28 0 0 0,0µs 0,0µs 0,00 0,00 0 Dummy-Driver
! 29 0 0 0,0µs 0,0µs 0,00 0,00 0 Freewheel-Driver
! 39 0 0 0,0µs 0,0µs 0,00 0,00 0 Midi-Bridge
57 1024 96000 10,7ms 7,7µs 1,00 0,00 0 alsa_output.usb-PreSonus_PreSonus_AudioBo
! 77 1024 96000 +++ +++ +++ +++ 51448 + Carla
! 55 0 0 0,0µs 0,0µs 0,00 0,00 0 alsa_input.usb-PreSonus_PreSonus_AudioBo
! 87 0 0 0,0µs 0,0µs 0,00 0,00 0 Surge XT
```
Those +++ persist even when it switches to actual alsa device from Dummy Driver.
when I add some plugin like Surge XT - it shows "Audio Output Unavailable" and doesn't play any sound. Carla and Ardour also show DSP load 100%.
There seem to be ALSA lib errors (Attached below) when I try to use Ardour, for Carla there is no output after `
libjack.so.0 loaded successfully!`
My workaround for now is this script:
```
#!/bin/sh
samples=96000;
mpv --volume=0 ~/Music/Terraria/Terraria_Soundtrack_01-Overworld-Day.mp3 &
pw-metadata -n settings 0 clock.rate $samples;
sleep 2;
PIPEWIRE_LATENCY="256/$samples" pw-jack /usr/bin/carla ~/carla-test.carxp &
sleep 1;
kill %1
```
With that script it works good usually. It will still break in Carla sometimes when mpv closes and I don't add any plugin making sound before mpv closes. Or if I remove all plugins after mpv closed, WAIT a few seconds (if I don't wait, it won't break) and than add one back again.
For Ardour kill %1 actually needs to be just before launching it... Dunno why, but it works usually.
## How Reproducible:
I have no idea. I get that consistently on one of my computers. I have very similar setup on my laptop and it works fine there even with the same audio interface. Please let me know about any additional information that I could attach and could be useful.
### Actual Results:
jack aplications don't produce sound, Ardour won't even play the timeline.
### Expected Results:
jack aplications working normally.
```
S ID QUANT RATE WAIT BUSY W/Q B/Q ERR NAME
! 28 0 0 0,0µs 0,0µs 0,00 0,00 0 Dummy-Driver
! 29 0 0 0,0µs 0,0µs 0,00 0,00 0 Freewheel-Driver
! 40 0 0 0,0µs 0,0µs 0,00 0,00 0 Midi-Bridge
59 256 96000 52,1µs 3,5µs 0,02 0,00 0 alsa_output.usb-PreSonus_PreSonus_AudioB
83 256 96000 10,0µs 1,0µs 0,00 0,00 0 + Carla
81 256 96000 9,5µs 35,2µs 0,00 0,01 27 + Surge XT
! 60 0 0 0,0µs 0,0µs 0,00 0,00 0 alsa_input.usb-PreSonus_PreSonus_AudioBo
```
# Additional Info (as attachments):
- `pw-dump > broken-carla.log`: [broken-carla.log](/uploads/6fb5a87036952c581ea7814c6e44f1a6/broken-carla.log)
- I tried switching wireplumber to pipewire-media-session (with a reboot in between), but the result was the same.
- `pw-jack /usr/bin/ardour6 > broken-ardour.log`: [broken-ardour.log](/uploads/65c530f4183370d7b228cc5dcd38f4f1/broken-ardour.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2741Pipewire service is always masked after upgrade of packages2023-05-15T12:51:49ZChad SmykayPipewire service is always masked after upgrade of packages<!-- 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.59
Linked with libpipewire 0.3.59
- Distri...<!-- 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.59
Linked with libpipewire 0.3.59
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
- Desktop Environment:
Gnome
- Kernel version (`uname -r`):
5.19.0-76051900-generic
## Description of Problem:
Everytime the pipewire packages are upgrades the service becomes masked by systemctl
## How Reproducible:
Not sure how to reproduce as I followed these instructions to install originally
https://askubuntu.com/questions/1339765/replacing-pulseaudio-with-pipewire-in-ubuntu-20-04
### Steps to Reproduce:
1. Use snap or apt to upgrade to latest Pipewire
2. systemctl --user status pipe-media-session.service
3. Once I reenable it and unmask it my bluetooth services start to work again.
### Actual Results:
After an upgrade pipewire services in systemctl are masked.
### Expected Results:
They should not be masked after an upgrade.
# Additional Info (as attachments):
- `[pw-dump.log](/uploads/10f9f7ed595a266ff89d06a461e1d9c2/pw-dump.log)`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2484High CPU Usage - Fedora 362023-05-15T12:50:43ZAlekHigh CPU Usage - Fedora 36VMWare Workstation 15/16
Fedora 36
Pipewire 0.3.52
Kernel: 5.18.6
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2101952
It seems that since Fedora 36 the pipewire process appears to consume nearly all my CPU usage. M...VMWare Workstation 15/16
Fedora 36
Pipewire 0.3.52
Kernel: 5.18.6
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2101952
It seems that since Fedora 36 the pipewire process appears to consume nearly all my CPU usage. My environment is VMWare Workstation 15, and 16 (separate physical machines). I don't know what pipewire does, but it's become such an issue that I'm considering changing my Linux distro. I saw the other issue (#1968), and my issue occurs when I start almost any application - not just Firefox.
![pipewire](/uploads/1ba997bfd271d154c8d6ababdfbc2ee9/pipewire.png)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2705echo-cancel not working at 80002023-05-15T12:49:12ZAaron Briceecho-cancel not working at 8000I have echo-cancel configured between alsa_input (2 mics connected to stereo line-in) and alsa_ouput (2 channel) both running at 48000 rate. I play music through echo-cancel-sink and record my voice through echo-cancel-source with pw-re...I have echo-cancel configured between alsa_input (2 mics connected to stereo line-in) and alsa_ouput (2 channel) both running at 48000 rate. I play music through echo-cancel-sink and record my voice through echo-cancel-source with pw-record and it works great, can not hear the music. But with the same configuration if I run `pw-record --rate 8000 --channels 1 test.wav` then it doesn't sound as if there's any echo cancellation at all. The purpose is to be able to record voice from the line in to send over bluetooth HFP.
/usr/share/pipewire/pipewire.conf.d/20-echo-cancel.conf:
```
context.modules = [
{
name = libpipewire-module-echo-cancel
args = {
library.name = aec/libspa-aec-webrtc
# node.latency = 1024/48000
aec.args = {
webrtc.extended_filter = true
webrtc.delay_agnostic = true
webrtc.high_pass_filter = true
webrtc.noise_suppression = true
webrtc.voice_detection = true
webrtc.gain_control = false
webrtc.experimental_agc = false
webrtc.experimental_ns = false
}
audio.channels = 2
source.props = {
node.name = "echo-cancel-source"
}
sink.props = {
node.name = "echo-cancel-sink"
}
}
}
]
```https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2884pw-cat/pw-play/pw-record target not working2023-05-15T11:44:03Zbgkillaspw-cat/pw-play/pw-record target not workingpw-cat/pw-play/pw-record with --target seems to change nothing and just selects the default device i tried with the name of the device and the id and even if i type a non existent target it still just selects the default onepw-cat/pw-play/pw-record with --target seems to change nothing and just selects the default device i tried with the name of the device and the id and even if i type a non existent target it still just selects the default onehttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2985Fade-in for the first second or two at each playback/file2023-05-15T11:19:17ZAndoru EkkusuFade-in for the first second or two at each playback/file<!-- 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.63
- 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.63
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Manjaro Linux
- Desktop Environment: XFCE
- Kernel version (`uname -r`): 5.15.85-1-MANJARO
## Description of Problem:
Having this issue with PipeWire, where it would skip the first one or two second(s) of the playback, then immediately fade in.
Looked into this problem, was suggested that this might be an issue with power saving being used on on Intel HDA/integrated sound module. However, I’m using a USB headphone DAC/amplifier.
So in that case I disable that power saving feature for the device through modprobe:
```
$ inxi -A
Audio:
Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor HD Audio
driver: snd_hda_intel
Device-2: Intel 8 Series/C220 Series High Definition Audio
driver: snd_hda_intel
Device-3: FiiO K3 type: USB driver: snd-usb-audio
Sound API: ALSA v: k5.15.85-1-MANJARO running: yes
Sound Server-1: PipeWire v: 0.3.63 running: yes
```
```
$ cat /etc/modprobe.d/snd-usb-audio.conf
options snd-usb-audio power_save=0
```
Did the same for snd_hda_intel for good measure.
Both of these did not fix my issue.
This happens with all apps, including VLC, Firefox, Tenacity, sound notifications for other apps. System sounds and Wine apps seem unaffected weirdly enough.
## How Reproducible:
Happens 75% of the time. Sometimes when I seek to the beginning of the track/video, I get to hear the first few seconds, but not always.
### Steps to Reproduce:
1. Play audio/video in the aforementioned apps
### Actual Results:
2. 1-2 seconds of silence
3. Audio fades in and plays as normal
### Expected Results:
2. Play audio as normal, from beginning to end
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/5f2299cd6747d0294c2efb4997e3f09d/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3061pipewire-alsa leaks memory on losing connection2023-05-15T11:17:26ZPrathampipewire-alsa leaks memory on losing connection<!-- 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.66
- 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.66
- Distribution and distribution version (PRETTY_NAME from /etc/os-release): -
- Desktop Environment: sway
- Kernel version (uname -r): 6.2.1
## Description of Problem:
If a running program using pipewire-alsa loses connection to the pipewire socket, it constantly leaks memory in a loop. The flow goes like this, eventually leading to spa_pod_copy calls:
```c
snd_pcm_recover(snd_pcm_t *pcm, int err, int silent) {
if (err == -EPIPE) {
/* ... */
if (snd_pcm_prepare(pcm) < 0) {
/* not reached */
}
return 0
/* ... */
}
}
while ((f = snd_pcm_avail_update(alsa_handle)) < 0) {
if (snd_pcm_recover(alsa_handle, f, 0) < 0) {
/* not reached, infinite loop */
}
}
```
## How Reproducible:
Always
### Steps to Reproduce:
1. Launch a program using pipewire-alsa, say cmus
2. Start a stream (eg start playing a file in cmus)
3. Kill the pipewire server
4. Memory usage explodes
### Actual Results:
Constantly increasing memory leak
```c
#0 0x00007fc54cf0d990 in malloc () from /usr/lib/libc.so.6
#1 0x00007fc5499734db in spa_pod_copy (pod=0x7fc5490d24b8) at ../spa/include/spa/pod/builder.h:688
#2 0x00007fc549975224 in add_node_update (data=0x55d76dcb7a28, change_mask=3, info_mask=5)
at ../src/modules/module-client-node/remote-node.c:327
#3 0x00007fc549978d9d in node_info_changed (data=0x55d76dcb7a28, info=0x55d76dcb6b78)
at ../src/modules/module-client-node/remote-node.c:1062
#4 0x00007fc547fa4ae2 in emit_info_changed (node=0x55d76dcb6b20, flags_changed=false) at ../src/pipewire/impl-node.c:292
#5 0x00007fc547fab0cb in node_info (data=0x55d76dcb6b20, info=0x55d76dc993b0) at ../src/pipewire/impl-node.c:1465
#6 0x00007fc545e35bc8 in emit_node_info (this=0x55d76dc99048, full=false) at ../spa/plugins/audioconvert/audioadapter.c:313
#7 0x00007fc545e3dd0e in follower_port_info (data=0x55d76dc99048, direction=SPA_DIRECTION_OUTPUT, port_id=0,
info=0x55d76dc92998) at ../spa/plugins/audioconvert/audioadapter.c:1157
#8 0x00007fc547fd4842 in emit_port_info (d=0x55d76dc92760, full=false) at ../src/pipewire/stream.c:692
#9 0x00007fc547fda7eb in pw_stream_update_params (stream=0x55d76dc92760, params=0x7fc5490d39d8, n_params=1)
at ../src/pipewire/stream.c:2101
#10 0x00007fc5498f59ee in snd_pcm_pipewire_prepare (io=0x55d76dc0b930) at ../pipewire-alsa/alsa-plugins/pcm_pipewire.c:600
#11 0x00007fc549b1ca22 in ?? () from /usr/lib/libasound.so.2
#12 0x00007fc549ad7ee8 in snd_pcm_prepare () from /usr/lib/libasound.so.2
#13 0x00007fc549adf79b in snd_pcm_recover () from /usr/lib/libasound.so.2
#14 0x00007fc549b78acd in op_alsa_buffer_space () at op/alsa.c:283
#15 0x000055d76c42469d in op_buffer_space () at output.c:299
#16 0x000055d76c42721f in consumer_loop (arg=0x0) at player.c:872
#17 0x00007fc54cefe22c in ?? () from /usr/lib/libc.so.6
#18 0x00007fc54cf7e16c in ?? () from /usr/lib/libc.so.6
```
### Expected Results:
No leakshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3111Can't seem to get DAC rate over 44100?2023-05-15T11:12:11ZJames LewisCan't seem to get DAC rate over 44100?Maybe not software bug? But I'm struggling to understand the distinction between RATE and FORMAT in "pw-top", as it pertains to the bitrate that pipewire is connecting to the audio hardware, and I think it's sticking at 44100... Can some...Maybe not software bug? But I'm struggling to understand the distinction between RATE and FORMAT in "pw-top", as it pertains to the bitrate that pipewire is connecting to the audio hardware, and I think it's sticking at 44100... Can someone clarify the meaning if the fields here:-
```
S ID QUANT RATE WAIT BUSY W/Q B/Q ERR FORMAT NAME
I 28 0 0 0.0us 0.0us 0.00 0.00 0 Dummy-Driver
S 29 0 0 --- --- --- --- 0 Freewheel-Driver
S 41 0 0 --- --- --- --- 0 Midi-Bridge
S 47 0 0 --- --- --- --- 0 alsa_output.pci-0000_00_1f.3.iec958-stereo
S 38 0 0 --- --- --- --- 0 alsa_output.pci-0000_01_00.1.hdmi-stereo
R 128 512 44100 257.7us 273.0us 0.02 0.02 0 S32LE 2 96000 alsa_output.usb-BEHRINGER_UMC202HD_192k-00.iec958-stereo
R 64 2048 44100 77.1us 8.9us 0.01 0.00 0 S16LE 2 44100 + ALSA Playback
R 89 8192 96000 79.3us 93.4us 0.01 0.01 0 S24LE 2 96000 + Lollypop
S 98 0 0 --- --- --- --- 0 alsa_input.usb-BEHRINGER_UMC202HD_192k-00.iec958-stereo
```
If I'm reading this right, Pipewire is doing internal processing at 96khz, Lollypop (Audio player) is outputting 96Khz, but pipewire is still connecting to the audio hardware at 44.1Khz... I'm struggling to understand the documentation regarding what the FORMAT vs RATE means for source and sink, particularly when they are different.
I added the following to /etc/pipewire/media-session.d/alsa-monitor.conf, but I cannot get the "RATE" to go above 44100.
```
matches = [
{
node.name = "alsa_output.usb-BEHRINGER_UMC202HD_192k.*"
}
]
actions = {
update-props = {
audio.format = "S32_LE"
audio.rate = 96000
# Following value should be doubled until audio doesn't cut out or other issues stop occurring
api.alsa.period-size = 256
api.alsa.headroom = 1024
}
```
I'm hoping someone can point me in the right direction, or even just to a forum where every question isn't "how do I install pipewire on Ubuntu"...
But also, it would be really great to improve documentation in this area.... and, hell... it would be absolutely amazing to have a GUI like pavucontrol for pipewire which could do these things, and adjust the other settings.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3119How to measure and reduce end to end latency2023-05-15T11:09:21ZNicolas GoyHow to measure and reduce end to end latencyThis is more a question than an issue, but I think it might be good for future reference.
I have the following configuration:
MOTU M2 -> ardour -> MOTU M2
When I loopback the sound of my headset I have about 200ms latency, I filmed th...This is more a question than an issue, but I think it might be good for future reference.
I have the following configuration:
MOTU M2 -> ardour -> MOTU M2
When I loopback the sound of my headset I have about 200ms latency, I filmed the screen of my M2 while taping my hands and counted frames in the video where the input bar is high and the output bar is still low.
Is it possible to measure this latency properly and also I am trying to find what is adding so much latency.
In ardour, it says "20ms" next to latency, running pw-top says 48kHz and 1024 quantum and in the wait column nothing is above 1ms.
[pw-dump.log.gz](/uploads/4460d1c0f67e01792b85bc9e9392f2b1/pw-dump.log.gz)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3170Documentation unclear on how to use 'actions' in configuration2023-05-15T11:08:10ZJonathan WattDocumentation unclear on how to use 'actions' in configurationAt a high level, my issue is that when using libpipewire-module-raop-discover, in GNOME settings the Device Output dropdown shows two copies of the AirPlay device I want to play to. One works and the other does not.
A recent PipeWire up...At a high level, my issue is that when using libpipewire-module-raop-discover, in GNOME settings the Device Output dropdown shows two copies of the AirPlay device I want to play to. One works and the other does not.
A recent PipeWire update renamed these (thanks!) to clarify that the reason there are two copies is because one is IPv4 (works), the other is IPv6 (does not work).
I would like to somehow remove the IPv6 output device from GNOME settings, and perhaps the cleanest way is to prevent PipeWire from creating a stream for it(?). So was hoping to be able to do something like:
```
{ name = libpipewire-raop-discover
args = {
stream.rules = [
{ matches = [
{ raop.ip.version = 6
}
]
}
]
actions = {
DO-NOT-CREATE-A-STREAM
}
}
flags = [ ifexists ]
}
```
Unfortunately I'm having some trouble figuring out from the documentation what the valid contents of `actions` are, or if this is possible some other way.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2909Could not load mandatory module "libpipewire-module-protocol-native" resource...2023-05-15T11:04:08ZAlkarisCould not load mandatory module "libpipewire-module-protocol-native" resource unavailableI went to install pipewire and pipewire-pulse and I cannot get it to start, it just keeps failing to start and it's giving me this error;
```
[E][00297.758591] mod.protocol-native | [module-protocol-: 731 lock_socket()] server 0x564567...I went to install pipewire and pipewire-pulse and I cannot get it to start, it just keeps failing to start and it's giving me this error;
```
[E][00297.758591] mod.protocol-native | [module-protocol-: 731 lock_socket()] server 0x5645674a41c0: unable to lock lockfile '/run/user/1000/pipewire-0.lock': Resource temporarily unavailable (maybe another daemon is running)
[E][00297.758674] pw.conf | [ conf.c: 594 load_module()] 0x5645674692e0: could not load mandatory module "libpipewire-module-protocol-native": Resource temporarily unavailable
[E][00297.758724] default | [ pipewire.c: 125 main()] failed to create context: Resource temporarily unavailable
```
I do not know why it's giving this error, if I just installed it, then ALL the resources should be there, yet it's telling me it's unavailable. Instead of "File Not Found" like issue #2137, it's Resource temporarily unavailable. I followed all the necessary steps to install and enable pipewire service, yet it fails to start from a clean install.
1. Installed from package manager Pacman
2. Enabled services for `pipewire`, `pipewire-pulse`, `pipewire-media-session` with `systemctl --user enable --now`
3. Get error saying the following;
```
ExecStart=/usr/bin/pipewire (code=exited, status=254)
systemd[1]: pipewire.service: Start request repeated too quickly.
systemd[1]: pipewire.service: Failed with result 'exit-code'.
systemd[1]: Failed to start PipeWire Multimedia Service.
systemd[1]: pipewire-pulse.service: Start request repeated too quickly.
systemd[1]: pipewire-pulse.service: Failed with result 'exit-code'.
systemd[1]: Failed to start PipeWire PulseAudio.
```
why would it do this on a clean install from package manager and fail to start? This is why I have avoided pipewire for so long, because it's so convoluted and never starts when installed properly even when you followed the proper way to install it.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3214HDMI: GPU -> AVR -> TV - no HDMI sink after screen blank2023-05-13T08:26:00ZFirst LastHDMI: GPU -> AVR -> TV - no HDMI sink after screen blankHi,
My setup: Arch Linux, current Pipewire, current Wireplumber
Audio out via GPU to an A/V Receiver
Video out via GPU and A/V Receiver and via its monitor HDMI out to the TV
That setup works until I blank the screen (Gnome settings).
...Hi,
My setup: Arch Linux, current Pipewire, current Wireplumber
Audio out via GPU to an A/V Receiver
Video out via GPU and A/V Receiver and via its monitor HDMI out to the TV
That setup works until I blank the screen (Gnome settings).
That leads to any audio output (music) to stop.
After returning from the blanked screen, the HDMI sink is still not available.
Only restarting Pipewire brings back the HDMI sink.
Is that behaviour to be expected?
Of course I'd like the HDMI sink to stay available for audio out, even during screen blanking. And if HDMI has to get disabled, Pipewire should recognize it being available again after screen blanking.
Am I excepting too much?
Or should I configure my setup in a specific way?https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3213Various JACK options do not work2023-05-12T21:16:40ZPlesa RaspoontVarious JACK options do not work<!-- 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.66 - 0.3.70
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os...<!-- 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.66 - 0.3.70
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: XFCE
- Kernel version (`uname -r`): 6.3.1-zen2-1-zen
## Description of Problem:
Version 0.3.67 and since, when using QPWGraph the playback and monitor/capture ports are combined in the same device for virtual devices, instead of being in separate devices.
The wiki suggests that the option `jack.merge-monitor` in `jack.conf` should do something, but it doesn't, in fact none of the options do anything at all (`jack.show-monitor = false` doesn't hide the monitors for example).
The 0.3.67 has a commit that supposedly changes the default of this variable from false to true, however when recompiling version 0.3.66 with the option set to `true` by default, the devices are actually split, which suggests the option never worked in the first place and some other code was responsible for this.
There is no way to merge the virtual devices in versions 0.3.66 and prior, and no way to split them 0.3.67 forward.
Additionally, non-virtual devices are always split no matter what, regardless of version.
This behaviour occurs when running the program with either `qpwgraph` or `pw-jack qpwgraph`
## How Reproducible:
Very
### Steps to Reproduce:
1. Install QPWGraph
2. in `~/.config/pipewire/pipewire.conf.d/pipewire.conf`:
```
context.objects = [
{ factory = adapter
args = {
factory.name = "support.null-audio-sink"
node.name = "PW-Test"
node.description = "Test"
media.class = "Audio/Sink"
object.linger = true
audio.channels = 2
audio.position = "FL,FR"
#jack.show-monitor = "false"
#for the heck of it I even tried it here, it doesn't work anywhere.
}
}
]
```
3. Install a pipewire version from 0.3.67 to 0.3.70
4. in `~/.config/pipewire/jack.conf.d/jack.conf`:
```
jack.properties = {
#jack.show-monitor = false
jack.merge-monitor = false
}
```
5. Restart everything and check QPWGraph to see how nothing matches the configs
6. Install pipewire version 0.3.66 or older
7. in `~/.config/pipewire/jack.conf.d/jack.conf`:
```
jack.properties = {
#jack.show-monitor = false
jack.merge-monitor = true
}
```
8. Restart everything and check QPWgraph to see how nothing matches the configs again
### Actual Results:
Real devices are always split regardless of version
Virtual devices are split 0.3.66 and prior, merged 0.3.67 and after
### Expected Results:
That options in `jack.conf` did something.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3193Volume is much lower with PipeWire than PulseAudio (ALSA UCM)2023-05-12T19:50:43ZDylan Van AsscheVolume is much lower with PipeWire than PulseAudio (ALSA UCM)<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): pipewire 0.3.70
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): pipewire 0.3.70
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): postmarketOS edge (Alpine edge)
- Desktop Environment: Phosh
- Kernel version (`uname -r`): 6.3.0
## Description of Problem:
Audio volume is super low with PipeWire while it is normal with PulseAudio.
If you put your ear against the speaker, you can hear what is being played.
In some cases, the audio is also distorted.
The same ALSA UCM configuration is used in both cases.
`alsamixer` shows nothing special regarding volumes.
I suspect a codec/conversion issue? However, I'm not sure, so anything is welcome so I can debug this further.
## How Reproducible:
Always on SDM845 devices such as Oneplus 6, SHIFTPHONES SHIFT6mq, Xiaomi POCO F1.
See https://gitlab.com/postmarketOS/pmaports/-/issues/1534
### Steps to Reproduce:
1. Replace PulseAudio by PipeWire
2. Play something
### Actual Results:
Audio volume is super low compared to PulseAudio with the same UCM
### Expected Results:
Audio volume is unaffected compared to PulseAudio with the same UCM
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.txt](/uploads/1b68cb139ac752c6b482b05e1da78f33/pw-dump.txt)
- ALSA UCM config: https://gitlab.com/sdm845-mainline/alsa-ucm-conf/-/tree/master/ucm2/SHIFT/axolotlhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3206Proposal: filter-chain profiler2023-05-12T19:16:06ZDmitry SharshakovProposal: filter-chain profilerA way to log or otherwise collect stats of filter-chain processing steps (including math operators, LV2 plugins, builtin processing plugins etc), mostly regarding CPU active time per cycle (time spent on processing a single buffer), whic...A way to log or otherwise collect stats of filter-chain processing steps (including math operators, LV2 plugins, builtin processing plugins etc), mostly regarding CPU active time per cycle (time spent on processing a single buffer), which coincedes with the extra latency added.
This will help people writing their profiles to understand impact of plugins used and scientifically measure efficiency for each solution.