pipewire issueshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues2023-10-16T15:15:11Zhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3582[Feature request] Implement functionality similar to PulseAudio's module-allo...2023-10-16T15:15:11ZMarkus Koller[Feature request] Implement functionality similar to PulseAudio's module-allow-passthroughFrom https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-allow-passthrough:
> This module ensures that passthrough streams are always allowed to play on sinks. The default policy in PulseAudio is to o...From https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-allow-passthrough:
> This module ensures that passthrough streams are always allowed to play on sinks. The default policy in PulseAudio is to only allow exclusive access if nothing else is currently using the sink. With this module, all the existing streams are muted (by being re-routed to the null sink) when a passthrough stream comes in, allowing the passthrough stream to exclusively use the sink.
>
> This is particularly useful with media centers and HTPC boxes (e.g. Kodi media center) where we usually always want to be able to start a video even if an external notification sound happened to be playing at the same time.
This is quite a big quality-of-life improvement on a HTPC that's also used for other desktop purposes. Before PulseAudio implemented this, I always had to make sure that no other client was blocking passthrough (e.g. my music player being paused instead of stopped, or having an open browser tab with a YouTube video).https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3575MIDI input stopped working (master)2023-10-16T07:37:02ZMarcin KoziołMIDI input stopped working (master)- PipeWire version (`pipewire --version`): master after 6fefd49a8a212e827b0413b05ed5f73f1bd72876
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Ubuntu 23.04
- Desktop Environment: Gnome shell
- Kernel ver...- PipeWire version (`pipewire --version`): master after 6fefd49a8a212e827b0413b05ed5f73f1bd72876
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Ubuntu 23.04
- Desktop Environment: Gnome shell
- Kernel version (`uname -r`): 6.2.0-1014-lowlatency
## Description of Problem:
I'm not able to play using MIDI keyboard
## How Reproducible:
always
### Steps to Reproduce:
1. build master branch
2. open carla/ardour with some plugins, try to play using MIDI keyboard
### Actual Results:
1. MIDI events aren't passed to plugin
2. Clicking on virtual keyboard (for example in Carla's patchbay, when plugin is selected) works
### Expected Results:
I should be able to use USB Midi keyboard
# Additional Info
After git bisect:
➜ pipewire git:( c94d5d9d3) git bisect good\
6fefd49a8a212e827b0413b05ed5f73f1bd72876 is the first bad commit commit 6fefd49a8a212e827b0413b05ed5f73f1bd72876 Author: Wim Taymans wtaymans@redhat.com Date: Sat Oct 14 12:23:39 2023 +0200
```plaintext
jack: use a private writable mapping on input
See #3571
```https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3574choppy audio in recording when using loopback module2023-10-16T16:32:55Zjazzticketschoppy audio in recording when using loopback module<!-- 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.81+ to master (2bef05742842ede4ce018d9a31d72e42c09be185)
- Distribution and dist...<!-- 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.81+ to master (2bef05742842ede4ce018d9a31d72e42c09be185)
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: XFCE 4.18
- Kernel version (`uname -r`): 6.1.57-1-lts
## Description of Problem:
I use libpipewire-module-loopback to create a sink that I can redirect my game's audio output to. This allows me to record just the game's audio in OBS. After upgrading to pipewire 0.3.81, I noticed that the audio in the recording is choppy. The audio is fine through the speakers as I'm playing the game though.
git bisect tells me the 'bad' commit was cc0eb1ba0dea6d0d5e3586e1267e2b6dd7ac3795
## How Reproducible:
100%
### Steps to Reproduce:
1. Create a sink using the attached ~/.config/pipewire/pipewire.conf.d/20-loopback.conf config file:
[20-loopback.conf](/uploads/435d523eb5251b0109ce66ca08be77ff/20-loopback.conf)
2. Start the game and switch its output to the new 'game' sink
3. Use OBS to record a video and make sure the audio device is set to record from 'game'
### Actual Results:
Choppy audio:
![pipewire_bad](/uploads/903680b13aa2922721d2dcfed1879189/pipewire_bad.mp3)
### Expected Results:
Good audio:
![pipewire_good](/uploads/d7cd60ae40942f428a410b623ab1bc8c/pipewire_good.mp3)
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/679daf84632c22da9de7086f08d29557/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3573getsockopt(SCO_OPTIONS) failed, loading defaults2023-10-16T06:36:34ZAsela Fernandogetsockopt(SCO_OPTIONS) failed, loading defaults- PipeWire version (`pipewire --version`):
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Debian GNU/Linux 12 (bookworm)
- Desktop Environment: No window manager
- Kernel version (`uname -r`): 6.1.0-rpi4-...- PipeWire version (`pipewire --version`):
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Debian GNU/Linux 12 (bookworm)
- Desktop Environment: No window manager
- Kernel version (`uname -r`): 6.1.0-rpi4-rpi-v8
- BlueZ version (`bluetoothctl --version`): 5.66
- `lsusb`:
```
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 1235:8211 Focusrite-Novation Scarlett Solo (3rd Gen.)
Bus 001 Device 003: ID 0eef:0005 D-WAV Scientific Co., Ltd WS170120
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```
- Bluetooth devices:
```
Device F0:39:XX:XX:XX:XX AceSailor S21
```
## Description of Problem:
With ofono, the MTU for the SCO audio path is not negotiated and the default of 48 is used which is too small. This results in choppy audio.
If ofono is disabled the MTU is negotiated fine and the audio is perfect.
In either case A2DP audio is fine.
Pulseaudio also had this issue in v14.x however they increased the default MTU from 48 to 144 to fix this.
https://github.com/pulseaudio/pulseaudio/blob/13ef02da1bc55b8a36ff35ca5f9d15cf7495932a/src/modules/bluetooth/backend-ofono.c#L331
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/plugins/bluez5/backend-ofono.c?ref_type=heads#L96
## How Reproducible:
Reproducible
### Steps to Reproduce:
1. Install ofono: ```sudo apt -y install ofono```
2. Modify dbus config to ensure the user can send information to ofono (/etc/dbus-1/system.d/ofono.conf)
3. Enable ofono ```sudo systemctl enable ofono```
4. Configure wireplumber to use ofono backend ```sed -i '/bluez5.hfphsp-backend/s/--//;s/native/ofono/' /etc/wireplumber/bluetooth.lua.d/50-bluez-config.lua```
5. Reboot and login
6. Connect the hfp_ag service with a phone
7. Make a phone call
### Actual Results:
wireplumber: getsockopt(SCO_OPTIONS) failed, loading defaults
### Expected Results:
Expect wireplumber to have obtained the MTU from the ofono socket
# Additional Info (as attachments):
```
ofonod --version
1.31
```
```
systemctl --user status wireplumber
Oct 15 21:56:01 MR2 systemd[767]: Started wireplumber.service - Multimedia Service Session Manager.
Oct 15 21:56:02 MR2 wireplumber[784]: SPA handle 'api.libcamera.enum.manager' could not be loaded; is it installed?
Oct 15 21:56:02 MR2 wireplumber[784]: PipeWire's libcamera SPA missing or broken. libcamera not supported.
Oct 15 21:56:03 MR2 wireplumber[784]: Trying to use legacy bluez5 API for LE Audio - only A2DP will be supported. Please upgrade bluez5.
Oct 15 21:56:29 MR2 wireplumber[784]: getsockopt(SCO_OPTIONS) failed, loading defaults <---- Happens as call is made
Oct 15 21:56:45 MR2 wireplumber[784]: sco-sink: write failure: -9 (Bad file descriptor) <-- Happens as the call is terminated
```
```
systemctl --user status pipewire
Oct 15 21:56:01 MR2 systemd[767]: Started pipewire.service - PipeWire Multimedia Service.
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video14' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video15' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video21' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video22' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video14' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video15' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video21' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video22' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
```
During a phone call
```
wpctl status
PipeWire 'pipewire-0' [0.3.65, asela@MR2, cookie:684911199]
└─ Clients:
31. pipewire [0.3.65, asela@MR2, pid:785]
33. WirePlumber [0.3.65, asela@MR2, pid:784]
34. WirePlumber [export] [0.3.65, asela@MR2, pid:784]
90. wpctl [0.3.65, asela@MR2, pid:826]
Audio
├─ Devices:
│ 53. Scarlett Solo (3rd Gen.) [alsa]
│ 54. Built-in Audio [alsa]
│ 55. Built-in Audio [alsa]
│ 77. AceSailor S21 [bluez5]
│
├─ Sinks:
│ 32. Built-in Audio Digital Stereo (HDMI) [vol: 0.40]
│ * 69. Scarlett Solo (3rd Gen.) Analog Stereo [vol: 1.00]
│
├─ Sink endpoints:
│
├─ Sources:
│ * 70. Scarlett Solo (3rd Gen.) Analog Stereo [vol: 1.00]
│
├─ Source endpoints:
│
└─ Streams:
78. bluez_input.F0_39_XX_XX_XX_XX.0
79. output_FR > Scarlett Solo USB:playback_FR [active]
82. output_FL > Scarlett Solo USB:playback_FL [active]
80. bluez_output.F0_39_XX_XX_XX_XX.1
81. input_FL < Scarlett Solo USB:capture_FL [active]
83. monitor_FL
84. input_FR < Scarlett Solo USB:capture_FR [active]
85. monitor_FR
Video
├─ Devices:
│ 39. rpivid [v4l2]
│ 40. bcm2835-codec-decode [v4l2]
│ 41. bcm2835-codec-encode [v4l2]
│ 42. bcm2835-codec-isp [v4l2]
│ 43. bcm2835-codec-image_fx [v4l2]
│ 44. bcm2835-codec-encode_image [v4l2]
│ 45. bcm2835-isp [v4l2]
│ 46. bcm2835-isp [v4l2]
│ 47. bcm2835-isp [v4l2]
│ 48. bcm2835-isp [v4l2]
│ 49. bcm2835-isp [v4l2]
│ 50. bcm2835-isp [v4l2]
│ 51. bcm2835-isp [v4l2]
│ 52. bcm2835-isp [v4l2]
│
├─ Sinks:
│
├─ Sink endpoints:
│
├─ Sources:
│ 61. bcm2835-isp (V4L2)
│ 63. bcm2835-isp (V4L2)
│ 65. bcm2835-isp (V4L2)
│ 67. bcm2835-isp (V4L2)
│
├─ Source endpoints:
│
└─ Streams:
Settings
└─ Default Configured Node Names:
```https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3572UBSAN: left shift of negative value -64, store to misaligned address2023-10-16T11:34:17ZP VUBSAN: left shift of negative value -64, store to misaligned addressRunning the test suite with UBSan enabled emits some complaints:
```
$ ./builddir/spa/plugins/audiomixer/test-mix-ops
got get CPU flags 19419
test_s8_0
test_s8_1
test_s8_4
test_u8_0
test_u8_1
test_u8_4
test_s16_0
test_s16_1
test_s16_4
t...Running the test suite with UBSan enabled emits some complaints:
```
$ ./builddir/spa/plugins/audiomixer/test-mix-ops
got get CPU flags 19419
test_s8_0
test_s8_1
test_s8_4
test_u8_0
test_u8_1
test_u8_4
test_s16_0
test_s16_1
test_s16_4
test_u16_0
test_u16_1
test_u16_4
test_s24_0
test_s24_1
test_s24_4
../spa/plugins/audiomixer/mix-ops.h:46:26: runtime error: left shift of negative value -64
#0 0x5609f9efd46d in s24_to_s32 ../spa/plugins/audiomixer/mix-ops.h:46
#1 0x5609f9efd46d in mix_s24_c ../spa/plugins/audiomixer/mix-ops-c.c:41
#2 0x5609f9eff83f in run_test ../spa/plugins/audiomixer/test-mix-ops.c:48
#3 0x5609f9f020c5 in test_s24 ../spa/plugins/audiomixer/test-mix-ops.c:125
#4 0x5609f9f06c47 in main ../spa/plugins/audiomixer/test-mix-ops.c:263
#5 0x7ff170c46149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: 7dd93cb9991a89f0ec53d9443a0b78ad952269bc)
#6 0x7ff170c4620a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) (BuildId: 7dd93cb9991a89f0ec53d9443a0b78ad952269bc)
#7 0x5609f9efd864 in _start (/home/pauli/prj/external/pipewire/builddir/spa/plugins/audiomixer/test-mix-ops+0x10864) (BuildId: e3eadde5566317598a0a5aaeb70c2e6e23b9d1ea)
```
```
$ ./builddir/spa/plugins/audioconvert/test-fmt-ops
got CPU flags 19419
test test_f32_s8:
test test_f32d_s8:
test test_f32_s8d:
test test_f32d_s8d:
test test_s8_f32:
test test_s8d_f32:
test test_s8_f32d:
test test_s8d_f32d:
test test_f32_u8:
test test_f32d_u8:
test test_f32_u8d:
test test_f32d_u8d:
test test_u8_f32:
test test_u8d_f32:
test test_u8_f32d:
test test_u8d_f32d:
test test_f32_u16:
test test_f32d_u16:
test test_u16_f32d:
test test_u16_f32:
test test_f32_s16:
test test_f32d_s16:
test test_f32_s16d:
test test_f32d_s16d:
test test_f32_s16_sse2:
test test_f32d_s16_sse2:
../spa/plugins/audioconvert/fmt-ops-sse2.c:1151:35: runtime error: store to misaligned address 0x559099f3db66 for type 'int32_t', which requires 4 byte alignment
0x559099f3db66: note: pointer points here
ff 7f ff 7f 00 00 00 00 00 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 00 00 00 00 00
^
#0 0x559099e87319 in conv_f32d_to_s16_2s_sse2 ../spa/plugins/audioconvert/fmt-ops-sse2.c:1151
#1 0x559099e87319 in conv_f32d_to_s16_sse2 ../spa/plugins/audioconvert/fmt-ops-sse2.c:1241
#2 0x559099e3e9dd in run_test ../spa/plugins/audioconvert/test-fmt-ops.c:90
#3 0x559099e3f522 in test_f32_s16 ../spa/plugins/audioconvert/test-fmt-ops.c:213
#4 0x559099e436f3 in main ../spa/plugins/audioconvert/test-fmt-ops.c:755
#5 0x7f2a25c46149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: 7dd93cb9991a89f0ec53d9443a0b78ad952269bc)
#6 0x7f2a25c4620a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) (BuildId: 7dd93cb9991a89f0ec53d9443a0b78ad952269bc)
#7 0x559099e39604 in _start (/home/pauli/prj/external/pipewire/builddir/spa/plugins/audioconvert/test-fmt-ops+0x69604) (BuildId: f06f441b668c61295a3a84772591bed796ad0bdb)
```
Don't know if these are false alarms.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3571Audio corruption when connecting one source to multiple sinks, and a sink ove...2023-10-17T16:23:14Znyanpasu64Audio corruption when connecting one source to multiple sinks, and a sink overwrites memory<!-- 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.82
- 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.82
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: KDE Wayland
- Kernel version (`uname -r`): 6.5.6-arch2-1
## Description of Problem:
When a node's output source is connected to multiple nodes with sinks, and one JACK or PipeWire node overwrites its input buffers in-place, the audio gets corrupted in the other nodes as well.
## How Reproducible:
Always (if you launch the corrupting app before other listeners).
### Steps to Reproduce:
I've found multiple ways (both through everyday use and synthetic test cases) to trigger this bug.
#### Minimal corruptor
1. Clone and build https://github.com/nyanpasu64/jack-corruptor.
2. Run a program (like Audacity or REAPER) which records from the microphone.
3. Run `jack-corruptor` to overwrite the default input port (mic?) with -0.5, then watch as audio becomes garbled in the recording program (randomly alternating between -0.5 and actual audio).
#### Easy Effects corrupting audio
1. Enable an Easy Effects chain.
2. For the first effect in the chain (listening to "Easy Effects Sink" monitor_FL/FR), set the input gain to any nonzero number (I used negative).
3. Begin recording audio in Audacity, then use pavucontrol to have it listen to "Monitor of Easy Effects Sink" as well.
4. Replay the audio and note it's garbled (randomly alternating between the gain value and actual audio).
#### REAPER corrupting audio
1. Run `pw-loopback --name "loop1" --capture-props='media.class=Audio/Sink' --playback-props='media.class=Audio/Source'`, and route a microphone into its sink (input).
2. Launch REAPER (with JACK backend) and have it listen to loop1's source (output).
3. Arm a track for recording, then mute it to disable software playthrough. (This also causes REAPER to zero out input buffers.)
4. Try recording audio from the microphone in another program (eg. close/reopen Firefox, then open Google Voice and call an echo test number like `(804) 222-1111, press 3`).
Audio remains garbled and mostly silent.
- Closing REAPER but leaving loop1 running does not fix this.
- If you instead disconnect and reconnect the microphone to loop1 (with or without REAPER still listening to loop1), the issue stops (even though the previous and final states are the "same").
### Actual Results:
Whether it's legal or not, it's common for apps to overwrite input audio it receives from JACK or PipeWire. This also affects other apps listening to the same source node. I think this is because all sink nodes (and possibly the source node producing audio) share the same audio buffer through shared memory mapping.
Why does the issue not recur when I disconnect and reconnect the corrupting sink? I think the first sink that connects to a source (output) is the first one to get polled when it's ready, and any changes it makes to the audio buffer are likely to be heard by other clients. If you stop and restart the app corrupting memory (eg. reconnect microphone -> loop1), this link gets placed at the end of the list of sinks polled when a source (output) is ready, and other sinks will likely finish reading memory by the time your app gets called and starts corrupting memory.
Why does the microphone get corrupted, even when REAPER is listening to loop1 rather than the microphone? I suppose `pw-loopback` shares its input and output buffers? IDK.
### Expected Results:
If one app overwrites input audio, it should not corrupt the audio heard by other apps. This could be implemented using copy-on-write shared memory, read-only shared memory (though this will break existing apps dependent on mutating input buffers), or copying memory to each sink rather than merely mapping it in.
I don't know which fixes have acceptable CPU/memory/backwards-compat penalties.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/48b90140aab1a89193de11f8415a6b5f/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3570PipeWire refuses to use ALSA cards with any subdevice in use2023-10-15T16:57:12ZHector MartinPipeWire refuses to use ALSA cards with any subdevice in use`spa/plugins/alsa/alsa-udev.c` has a check (`check_pcm_device_availability`) that refuses to probe the entire ALSA card if *any* subdevice is in use.
For Apple laptops, the layout of our subdevices is:
* hw:0,0: Headphone jack (capture...`spa/plugins/alsa/alsa-udev.c` has a check (`check_pcm_device_availability`) that refuses to probe the entire ALSA card if *any* subdevice is in use.
For Apple laptops, the layout of our subdevices is:
* hw:0,0: Headphone jack (capture/playback)
* hw:0,1: Speakers (playback)
* hw:0,2: Speaker Sense (capture)
Speaker sense is opened persistently by an out of band daemon (`speakersafetyd`) and the kernel side is set up to feed it data (and actually power up the hardware) only when the speaker playback is started. That means that subdevice is always busy, and pipewire then refuses to use the entire card.
This trivial patch fixes the issue, but I don't understand the reasoning behind this check in the first place. The code even notes that with certain kernel config settings, the check cannot be done and always succeeds. Perhaps we should just get rid of this entirely? What purpose does it serve?
This is a blocker for enabling audio on Asahi systems (sorry for only noticing now, I wasn't expecting plugging in speakersafetyd to a separate subdevice to affect PipeWire...).
```
diff --git a/spa/plugins/alsa/alsa-udev.c b/spa/plugins/alsa/alsa-udev.c
index 3048d7363..b84db3ddd 100644
--- a/spa/plugins/alsa/alsa-udev.c
+++ b/spa/plugins/alsa/alsa-udev.c
@@ -349,6 +349,9 @@ static int check_pcm_device_availability(struct impl *this, struct card *card,
spa_log_debug(this->log, "card %u has %d PCM device(s)",
card->card_nr, *num_pcm_devices);
+
+ return 0;
+
/*
* Check if some pcm devices of the card are busy. Check it via /proc, as we
* don't want to actually open any devices using alsa-lib (generates uncontrolled
```https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3569Need to reload pipewire service to have sound2023-10-28T16:07:20ZNguyễn Hoàng HưngNeed to reload pipewire service to have sound<!-- 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.80
- 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.80
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Manjaro Linux
- Desktop Environment: xfce4
- Kernel version (`uname -r`): 6.1.55-1-MANJARO
## Description of Problem (this issue will only happen one time when booted up):
I switched from pulseaudio to pipewire, by installing manjaro-pipewire. Now, whenever I connect to a new bluetooth speaker, I need to reload pipewire service for it to have sound.
## How Reproducible:
I can reproduce every time (when computer boots up). after that, every's fine 'til the next time computer boots up
### Steps to Reproduce:
1. connect to bluetooth speaker
2. no sound
3. restart pipewire
4. sound show up
### Actual Results:
### Expected Results:
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3568Problems playing youtube videos with pipewire-0.3.812023-10-13T16:04:59ZAdam WilliamsonProblems playing youtube videos with pipewire-0.3.81Several users downstream in Fedora have reported issues playing youtube videos with pipewire 0.3.81:
* https://bugzilla.redhat.com/show_bug.cgi?id=2242080
* https://bodhi.fedoraproject.org/updates/FEDORA-2023-e3e1c6b6d0
the bug report ...Several users downstream in Fedora have reported issues playing youtube videos with pipewire 0.3.81:
* https://bugzilla.redhat.com/show_bug.cgi?id=2242080
* https://bodhi.fedoraproject.org/updates/FEDORA-2023-e3e1c6b6d0
the bug report initially identified this as a kernel issue, but later comments seem to make it clear it's a pipewire issue. Problems seem to be reported in VMware and VirtualBox VMs, and by [one reporter](https://bugzilla.redhat.com/show_bug.cgi?id=2242080#c7) on bare metal.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3567FR: Private Mode 2026 to resolve 'flicker' in pw-top - Health risk to users, ...2023-11-29T12:54:10ZpallasweptFR: Private Mode 2026 to resolve 'flicker' in pw-top - Health risk to users, please respond.- PipeWire version: Master
- Distribution and distribution version: openSUSE Tumbleweed
- Desktop Environment: KDE Plasma
- Kernel version: 6.5.4-1-default
## Description of Problem:
Extreme flickering in pw-top
## How Reproducible:
...- PipeWire version: Master
- Distribution and distribution version: openSUSE Tumbleweed
- Desktop Environment: KDE Plasma
- Kernel version: 6.5.4-1-default
## Description of Problem:
Extreme flickering in pw-top
## How Reproducible:
100%, though the severity depends on the terminal emulator or multiplexer which hosts pw-top
### Steps to Reproduce:
1. Use a fast, GPU accelerated Wayland terminal emulator like foot or kitty, or just konsole will also work if you are a KDE user
2. Use a terminal multiplexer such as zellij (tmux will also do this, but it is far more evident in zellij)
3. start pw-top, within zellij, wait a few seconds
Additionally/alternatively:
1. Use foot terminal emulator.
2. In foot.ini, add the following configuration, in order to disable delayed rendering and allow pw-top to draw at will:
```plaintext
[tweak]
delayed-render-lower=0
delayed-render-upper=0
```
3. Start foot and run pw-top. Immediate, extreme flicker ensues.
### Actual Results:
Extreme screen flicker to the degree of being health hazard as it is a potential migraine or epilepsy trigger.
### Expected Results:
No flicker, happy epileptic PW users
# Additional Info (as attachments):
### TL;DR this is a feature request for private mode 2026 implementation in pw-top,
#### and/or some other approach to delay/synchronise/atomicise screen updates, in order to avoid potentially dangerous screen flicker.
#### 2026, What is it?
This is the official specification: https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec by the original author. There is a good summary of the state and implementation of the feature here: https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036 with links following from there to various discussions working to officially standardise the feature.
#### Why though?
pw-top has a tendency to flicker somewhat when updating the screen. Since pw-top provides updates to data which can change quite rapidly and regularly, this results in the application drawing at a frequency which can be difficult or impossible for the terminal emulator to handle elegantly, resulting in segmented updates to the display that appear as 'flicker' or 'tearing'. I have not fully analysed the code, but on a quick look, I did not initially note any attempts to avoid screen flicker or control/limit the timing of updates to the screen.
Having spent some time in my career working in hospitals (as an IT guy, I am not a Doctor), I'm aware that these same optical effects which trigger my severe migraines, can be triggers for epilepsy, which is quite serious and, as a result of witnessing such events (a young boy who watched the wrong TV show and is in heaven now), I feel strongly compelled to try to mitigate this issue. I hope you can help me in this endeavour.
#### Is this really a problem?/Works for me!
I love Pipewire and everything about it so please, don't take this as an attack on pw-top, or feel bad for me, I'll be fine.... But I do worry for the sake of others. I initially logged this as an issue with zellij, since that was the application where I saw pw-top's flicker go from "mildly annoying thing I had noticed sometimes in various terminals" to "I just spent two days partially paralyzed and blind, in agony, and violently ill". My first thought was of that young boy, and I'm sure with the ubiquity of pipewire as it is, there will be a segment of the userbase who are sufferers of epilepsy.
zellij's developer was very kind about the whole experience, and foot's developer kindly dropped by to help share some insight into this. Being a terminal developer of high order (he makes the fastest terminal emulator on linux, if you haven't tried it I recommend it, you might really like it!) he was very well informed on the matter.
He explained to me that the reason why the flicker was worse in certain cases was due to different terminal emulators' and terminal multiplexers' handling of screen updates. Essentially, it rests upon the terminal emulator/muxer, to ensure that flicker from client applications does not occur, and without this feature I'm requesting, they must do so without having any awareness of the application's intent to begin or end an update.
Foot itself, in its default configuration. does not exhibit the flicker, as a result of an implementation of delaying updates by a configurable timeframe (up to a limit, to avoid lock-ups); nor is the flicker evident in kitty (I do not know the details of how kitty avoids the flicker but I gather that it is again some kind of delayed update mechanism) however running zellij within any of these terminal emulators I tested, the flicker from pw-top was quite unbearable and had serious effects on my physical wellbeing, which honestly just makes me worry about what it would do to somebody with a more serious illness than my own.
#### So what can we do about it?
Taking advice from foot's developer, he has suggested that the way to resolve this issue is a pending standard which has already become a de-facto standard though wide adoption among terminal emulators, that being 'private mode 2026'. The effect as I understand it is that the application signals its intentions to begin and to end a screen update, thus allowing the terminal emulator to display said updates appropriately.
I am not a terminal dev, this is a long way from my wheelhouse, but as far as I gather this may be as simple to implement, as sending an escape sequence near the start of pw-top's do_refresh() function, and another escape sequence near the end, respectively marking the beginning and end of the display update. Beyond that, it is up to the terminal emulator to support the feature or not (and as you can see from the link above, it is quite widely implemented among the top terminal emulators, and naturally, I have made a FR to zellij to add support for it also)
I very much hope you'll have some interest in adding this feature. If you are willing to have the feature added, while I'm not entirely experienced with this, I am very comfortable with the programming languages involved, so I would be happy to attempt to write the code and submit an MR if you would prefer it and it would avoid adding to your workload, or equally satisfied to step aside and get out of the way and let your team do your usual wonderful work. Anything that I can do to assist with this, just say the words and consider it done.
If you have any thoughts on this I would be very glad to hear it. Please let me know what you think.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3566Streaming to AirPlay fails, error streaming packet: -92023-10-12T21:51:47ZSwapnil DeveshStreaming to AirPlay fails, error streaming packet: -9[libpipewire-module-raop-discover-log.txt](/uploads/71930a56aa402cbf8e248213956dc9c9/libpipewire-module-raop-discover-log.txt)
Attached is the log, just see `error streaming packet: -9` being spammed and no audio playing.[libpipewire-module-raop-discover-log.txt](/uploads/71930a56aa402cbf8e248213956dc9c9/libpipewire-module-raop-discover-log.txt)
Attached is the log, just see `error streaming packet: -9` being spammed and no audio playing.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3564Mic volume/amplification: Implement some feature to detect it better?2023-10-12T20:59:41ZPer sonMic volume/amplification: Implement some feature to detect it better?I am on Fedora KDE and the microphone volume is everytime presetted to 100%
This produces extremely distorted audio, I tested and the best value was 10% for many devices.
A good way to determine this could be to record silence and decr...I am on Fedora KDE and the microphone volume is everytime presetted to 100%
This produces extremely distorted audio, I tested and the best value was 10% for many devices.
A good way to determine this could be to record silence and decrease the volume constantly. When the silence stops producing white noise (as the mic is overamplified) the volume is low enough. Maybe when there is no value where no white noise is playing, something like an "acceptable white noise" could be chosen instead.
The KDE people told me to report it here, even though this preset occurs on all KDE Distros.
But the best solution really would be to have some calibration tooling, that sets the volume=amplification to the correct value by detecting when there is no distortion/white noise/artifacts anymore.
Also, in KDE this value is reset often. The mic volume switch should not even exist, as its a workaround for an underlying problem. You should never change the mic volume really.
Currently about 10% is best for me and totally enough, everything above has white noise.
Relevant KDE bug:
https://bugs.kde.org/show_bug.cgi?id=474959
```
Specified App:
pipewire-0.3.81-1.fc38.x86_64
pipewire-libs-0.3.81-1.fc38.x86_64
pipewire-pulseaudio-0.3.81-1.fc38.x86_64
pipewire-alsa-0.3.81-1.fc38.x86_64
pipewire-jack-audio-connection-kit-libs-0.3.81-1.fc38.x86_64
kpipewire-5.27.8-1.fc38.x86_64
pipewire-jack-audio-connection-kit-0.3.81-1.fc38.x86_64
pipewire-gstreamer-0.3.81-1.fc38.x86_64
pipewire-utils-0.3.81-1.fc38.x86_64
--- Software ---
OS: Fedora Linux 38.20231011.0 (Kinoite)
KDE Plasma: 5.27.8
KDE Frameworks: 5.110.0
Qt: 5.15.10
Kernel: 6.5.6-200.fc38.x86_64
Compositor: wayland
--- Hardware ---
Thinkpad T495
CPU: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx
RAM: 21.4 GB
GPU: AMD Radeon Vega 8 Graphics
Video memory: 2048MB
Audio: Pipewire, Alsa
```
---
@pallaswept
Hi, interesting, so its motherboard specific. I had the same happening on two headphones but using the same motherboard, this may probably be the cause.
Okay found out it seems that Fedora KDE saves the state of the mic volume. Normally I also put that into a startup script.
But my main point is not, that any default should be set to what works for my board, but that there has to be a way to detect the right value automatically. I guess on the windows side this works by every manufacturer having some configured Driver with that value right.
I know it would be hard to have a good recording environment etc. and you would need to filter out the noise floor, or simply measure the curve of noise going down to a certain level, and when it doesnt go down anymore, tadaa noise floor. You can then preset the highest value of that path as the amplification, or not?
In KDE there is only that one thing, and I think its volume, but I dont know its a GUI slider that could do anything.
So, its not Pipewire but Alsa? Before I used
```
pactl set-source-volume $(pactl get-default-source) 10%
pactl set-source-mute $(pactl get-default-source) 1
```
as a `~/.config/autostart/startup.sh` to always force this level. No idea why this Pulseaudio thing works here, I guess when Fedora stops shipping it, it will break? These are installed on my system:
```
alsa-lib-1.2.10-2.fc38.x86_64
alsa-ucm-1.2.10-2.fc38.noarch
pipewire-alsa-0.3.81-1.fc38.x86_64
alsa-utils-1.2.10-1.fc38.x86_64
alsa-sof-firmware-2.2.5-1.fc38.noarch
alsa-ucm-1.2.10-2.fc38.noarch
```
This command works
```
amixer sset 'Capture' 10%
```
But again, this sets my graphical mic volume to 10% (which I dont have a problem with, if it has no weird disadvantages)
Thanks very much for your help. But I dont think this is the best way. So the problem is, the kernel reads the hardware and in many cases has the correct values? So it already works, but on many fancy motherboards it does not?
btw what is going on with like... everything? I could not make a comment and Google recaptcha everywhere...
the hardware is a Thinkpad T495 with its own mic or a Sennheiser PC38X headsethttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3563A workaround for a bizarre bug in Firefox (and possibly other pulseaudio clie...2023-10-29T05:37:03ZpallasweptA workaround for a bizarre bug in Firefox (and possibly other pulseaudio clients) that makes it always use the quantum limit and ignore your pipewire configFirefox will always ignore the settings you make in pipewire (ie pipewire-pulse.conf or any of its overrides in /etc/pipewire/pipewire-pulse.conf.d/* or ~/.config/pipewire/pipewire-pulse.conf.d/*) for its quantum/buffers, and use the qua...Firefox will always ignore the settings you make in pipewire (ie pipewire-pulse.conf or any of its overrides in /etc/pipewire/pipewire-pulse.conf.d/* or ~/.config/pipewire/pipewire-pulse.conf.d/*) for its quantum/buffers, and use the quantum limit (8192 by default).
I've discovered that setting the environment variable PULSE_LATENCY_MSEC to any number less than 23 makes this strange behaviour stop, and it will use the quanta and other settings you have set in your pipewire pulse configuration.
See https://github.com/mozilla/cubeb-pulse-rs/issues/87 for my issue for firefox for the rundown on this.
I discovered this by accident while helping with a spotify issue, as it exhibits the same bug as firefox (uses the quantum limit for no good reason at all), so I won't be at all surprised if this effects other pulseaudio clients aside from firefox.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3562MIDI clock not sent out on USB MIDI interface2023-11-19T11:57:55ZDaniel LundqvistMIDI clock not sent out on USB MIDI interface<!-- 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.80
- 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.80
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Debian GNU/Linux trixie/sid
- Desktop Environment: N/A
- Kernel version (`uname -r`): 6.5.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.3-1
## Description of Problem:
MIDI clock is not sent out on USB MIDI interface. This works fine with regular JACK (1.9.21). Perhaps this also affects other realtime messages, I have not investigated that further. I've tried this over two different USB MIDI interfaces, Roland Rubix22 and Roland Super MPU64/Edirol UM-4 (4 in/4 out MIDI interface). This is never a problem if the JACK clients are directly connected to each other, or through another JACK client (I tried with LV2 plugin http://gareus.org/oss/lv2/midifilter#passthru)
## How Reproducible:
Always.
### Steps to Reproduce:
1. Loop a MIDI DIN output to an input.
2. Run "jack_midi_clock <MIDI output port>" to send out clock according to BPM in JACK transport (use jack_transport to set tempo and start if not already rolling)
3. Run "jack_mclk_dump <MIDI input port>" to dump incoming clock and display tempo and some other transport information.
### Actual Results:
"jack_mclk_dump" won't receive the MIDI clock from USB MIDI interface. The UM-4 MIDI interface have leds for MIDI activity, they never light up on the MIDI out port.
### Expected Results:
MIDI clock to be sent out on the USB MIDI interface.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/225862a5359eaa4e9bf87d6fbaecd12f/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3561No sound after some time of silence2023-10-11T14:58:03ZЄгор ГеращенкоNo sound after some time of silence<!-- 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.81
- 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.81
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Void Linux
- Desktop Environment: Plasma 5.27.8 (wayland)
- Kernel version (`uname -r`): 6.5.7_1
## Description of Problem:
No sound after some time of silence.
## How Reproducible:
### Steps to Reproduce:
1. Log in to a new Plasma (wayland) session
2. Turn on any sound source and later turn off the sound source
### Actual Results:
No sound after silence
### Expected Results:
The sound works and doesn't go away
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:
[pw-dump.log](/uploads/3bc88ce9f87990d78181d87470f180f2/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3560MIDI Note On with velocity 0 gets to Note Off when more than one client is co...2023-10-13T07:21:37ZFlorian FaberMIDI Note On with velocity 0 gets to Note Off when more than one client is connected to output<!-- 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.81
- 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`):
Compiled with libpipewire 0.3.81
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
Gentoo
- Desktop Environment:
- Kernel version (`uname -r`):
6.5.6
## Description of Problem:
Title says it. As soon as I connect a second client to a MIDI output port, Note On with velocity 0 gets converted to Note Off. When I remove the second client, MIDI data passes thru transparently again.
## How Reproducible:
External MIDI device (AKAI APCmini mkII) connected via USB, routed to internal jack client, the output gets routed back to the AKAI. As soon as I connect the jack client's output to another jack client's input to dump MIDI data, the conversion takes place.
### Expected Results:
Transparent transport.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3559Freezing System2023-10-23T10:45:00ZTechXero *~* DarkXeroFreezing System<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): v0.3.81
- 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`): v0.3.81
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): ArchLinux Latest
- Desktop Environment: KDE Plasma 5.27
- Kernel version (`uname -r`): Linux 6.5.6-arch2-1
## Description of Problem:
Every time I reboot the system it hangs becomes unresponsive until I restart services via
```
systemctl --user restart pipewire
systemctl --user restart pipewire-pulse
```
## How Reproducible:
Well, I dunno reboot n see ? It's not happening to everyone which I find weird. Just a few on KDE Plasma.
### Actual Results:
System it hangs becomes unresponsive until I restart services.
# Additional Info (as attachments):
- [pw-dump.log](/uploads/013805aa0b80a6bce3fde5d996ae43df/pw-dump.log)`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3558how to configure FFADO ? Is ti working yet?2024-03-20T13:49:57Zaklinbailhow to configure FFADO ? Is ti working yet?<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.380 (pipewire-git 0.3.81.32.g2278dd146-1 )
- Arch Linux
- Desktop Environment: ...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.380 (pipewire-git 0.3.81.32.g2278dd146-1 )
- Arch Linux
- Desktop Environment: XFCE-4
- Kernel version 6.5.2.8.realtime1-1-rt
## Description of Problem:
pipewire-ffado installed..
But don't know how to configure .. documentation isn't clear for a noob to pipewire (but nearly 2 decades of using jack)
Why not ALSA?
I have 2 DICE devices which under FFADO/Jack appear as one device.. (which they are supposed to) ..
In pipewire-alsa as per normal ALSA , latency is higher, and generally the whole thing is less stable (even with only one device powered up_
(A&H Zed R16 and Profire 610)
Yes _ I'll probably get something like a Raydat PCIE and ditch firewire at some point..
## How Reproducible:
Not really relevant - I don't believe this is a fault.. other than documentation not being clear.
A full pipewire.conf example with fw:0 as the device would be really helpful
### Actual Results:
### Expected Results:
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3557Elgato Wave XLR resets input gain, volume, and crossover to max when restarti...2023-10-09T09:49:43ZDaktylElgato Wave XLR resets input gain, volume, and crossover to max when restarting the computer- PipeWire version (`pipewire --version`): 0.3.81
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Garuda Linux
- Desktop Environment: KDE Plasma 5.27.8
- Kernel version (`uname -r`): 6.5.5-zen1-1-zen
## D...- PipeWire version (`pipewire --version`): 0.3.81
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Garuda Linux
- Desktop Environment: KDE Plasma 5.27.8
- Kernel version (`uname -r`): 6.5.5-zen1-1-zen
## Description of Problem:
When restarting the computer, the Elgato Wave XLR will re-initialize it's "volumes" (input gain, output volume, and crossover slider) all into their maximum positions. This requires manual intervention to reset these values on the device itself every time I power cycle the computer.
## How Reproducible:
Every single time I restart my computer
### Steps to Reproduce:
1. Configure Elgato Wave XLR with some arbitrary level for input gain, volume, and crossover
2. Restart the computer
3. Check new values
### Actual Results:
Input gain, volume, and crossover reset to highest "position" possible each power cycle of the computer.
### Expected Results:
PipeWire or device remembers previous values and reinstates them upon initialization
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/9949dd74d544ed233a5bdc9a73c6d8c4/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3554Segfault in spa_alsa_prepare/snd_pcm_lock in update from 0.3.80 to 0.3.812023-10-11T09:41:37ZMalina ThomasSegfault in spa_alsa_prepare/snd_pcm_lock in update from 0.3.80 to 0.3.81- PipeWire version (`pipewire --version`):
```plaintext
pipewire
Compiled with libpipewire 0.3.81
Linked with libpipewire 0.3.81
```
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): `Arch Linux`
- Desktop...- PipeWire version (`pipewire --version`):
```plaintext
pipewire
Compiled with libpipewire 0.3.81
Linked with libpipewire 0.3.81
```
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): `Arch Linux`
- Desktop Environment: `sway` / `wlroots`
- Kernel version (`uname -r`): `6.5.6-arch1-1`
## Description of Problem:
As stated in title; I'm experiencing a segfault in snd_pcm_lock when starting pavucontrol (and also when chrome attempts to start sound playback I believe; less confirmed); downgrading to 0.3.80 fixes the problem
## How Reproducible:
### Steps to Reproduce:
1. upgrade to pipewire-\*:1:0.3.81-1 (translates to 0.3.81)
2. open pavucontrol
3. see segfault
### Actual Results:
segfault
### Expected Results:
program starts and displays volume control widgets
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/9cfb076c5b2202ec5d5555ece585f4bb/pw-dump.log)
- backtrace:
```
Core was generated by `/usr/bin/pipewire'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Section `.reg-xstate/2832846' in core file too small.
#0 snd_pcm_lock (pcm=0x0) at pcm/pcm_local.h:1215
Downloading source file /usr/src/debug/alsa-lib/alsa-lib-1.2.10/src/pcm/pcm_local.h
1215 if (pcm->lock_enabled && pcm->need_lock)
[Current thread is 1 (Thread 0x7f812417c740 (LWP 2832846))]
(gdb) bt
#0 snd_pcm_lock (pcm=0x0) at pcm/pcm_local.h:1215
#1 snd_pcm_status (pcm=0x56460fe448d0, status=status@entry=0x7ffc13aad6d0) at pcm/pcm.c:1055
#2 0x00007f8121d3080b in do_link (driver=driver@entry=0x56460fbdea48, state=state@entry=0x56460fbafdf8) at ../pipewire/spa/plugins/alsa/alsa-pcm.c:639
#3 0x00007f8121d3479c in spa_alsa_prepare.isra.0 (state=0x56460fbdea48) at ../pipewire/spa/plugins/alsa/alsa-pcm.c:3038
#4 0x00007f8121cee1b8 in spa_alsa_start (state=0x56460fbdea48) at ../pipewire/spa/plugins/alsa/alsa-pcm.c:3055
#5 0x00007f8121cdf43b in impl_node_send_command (object=<optimized out>, command=<optimized out>) at ../pipewire/spa/plugins/alsa/alsa-pcm-source.c:354
#6 0x00007f81219ea3bf in impl_node_send_command (object=0x56460fbe1b88, command=0x7ffc13aad830) at ../pipewire/spa/plugins/audioconvert/audioadapter.c:952
#7 0x00007f81243efc21 in node_update_state (node=0x56460fbff9c0, state=PW_NODE_STATE_RUNNING, res=0, error=0x0) at ../pipewire/src/pipewire/impl-node.c:374
#8 0x00007f81244148d4 in process_work_queue (data=0x56460f96c9c0, count=<optimized out>) at ../pipewire/src/pipewire/work-queue.c:67
#9 0x00007f812447da09 in source_event_func (source=0x56460f96ca00) at ../pipewire/spa/plugins/support/loop.c:663
#10 0x00007f812447f5b6 in loop_iterate (object=0x56460f957698, timeout=<optimized out>) at ../pipewire/spa/plugins/support/loop.c:496
#11 0x00007f81243e9954 in pw_main_loop_run (loop=loop@entry=0x56460f957540) at ../pipewire/src/pipewire/main-loop.c:128
#12 0x000056460e2092f1 in main (argc=<optimized out>, argv=<optimized out>) at ../pipewire/src/daemon/pipewire.c:111
(gdb) quit
```