pipewire issueshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues2023-11-07T08:24:42Zhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3488ROG MAXIMUS Z790 HERO: no sound from jack microphone in Ubuntu 23.042023-11-07T08:24:42ZValery KhamenyaROG MAXIMUS Z790 HERO: no sound from jack microphone in Ubuntu 23.04Hi
as suggested on Ubuntu Launchpad, I file the bug also here on your gitlab:
--------------------
If you have a jack microphone connected to your ROG MAXIMUS Z790 HERO motherboard and you go into Settings > Sound > Input, you'll see t...Hi
as suggested on Ubuntu Launchpad, I file the bug also here on your gitlab:
--------------------
If you have a jack microphone connected to your ROG MAXIMUS Z790 HERO motherboard and you go into Settings > Sound > Input, you'll see two entries:
* Digital Input S/PDIF USB Audio
* Microphone - USB Audio
if you detach your microphone jack the second one disappears. So, the second one is responsible for your jack mic.
Unfortunately, if you choose this "Microphone - USB Audio" no sound will be shown by the indicator gauge, even if you pull the mic volume to the maximum.
The default sound system in Ubuntu 23.04 is PipeWire. I see ALSA-related packages installed by default, but no pulseaudio and pulseaudio-utils packages.
It would be nice to get microphone working without creating a mess of different sound systems. I'd stay with ALSA+PipeWire without PulseAudio and without JACK.
I see that `arecord` can use ALSA to record sound from microphone, but what about Skype and your other apps that rely on usage of "Microphone - USB Audio" exposed via PipeWire? They don't work.
Any idea how to fix the mic issue without creating a mess?
thanks.
Other details:
----
% lsb_release -rd
No LSB modules are available.
Description: Ubuntu 23.04
Release: 23.04
% apt list --installed |grep -i pipewire
gstreamer1.0-pipewire/lunar,now 0.3.65-3 amd64 [installed,automatic]
libpipewire-0.3-0/lunar,now 0.3.65-3 amd64 [installed,automatic]
libpipewire-0.3-common/lunar,lunar,now 0.3.65-3 all [installed,automatic]
libpipewire-0.3-modules/lunar,now 0.3.65-3 amd64 [installed,automatic]
pipewire-alsa/lunar,now 0.3.65-3 amd64 [installed,automatic]
pipewire-audio/lunar,lunar,now 0.3.65-3 all [installed,automatic]
pipewire-bin/lunar,now 0.3.65-3 amd64 [installed,automatic]
pipewire-pulse/lunar,now 0.3.65-3 amd64 [installed,automatic]
pipewire/lunar,now 0.3.65-3 amd64 [installed,automatic]
% apt list --installed |grep -i alsa
alsa-base/lunar,lunar,now 1.0.25+dfsg-0ubuntu7 all [installed,automatic]
alsa-topology-conf/lunar,lunar,now 1.2.5.1-2 all [installed,automatic]
alsa-ucm-conf/lunar-updates,lunar-updates,now 1.2.6.3-1ubuntu9.1 all [installed,automatic]
alsa-utils/lunar,now 1.2.8-1ubuntu1 amd64 [installed,automatic]
gstreamer1.0-alsa/lunar-updates,lunar-security,now 1.22.1-1ubuntu1.1 amd64 [installed,automatic]
pipewire-alsa/lunar,now 0.3.65-3 amd64 [installed,automatic]
% apt list --installed |grep -i pulse
libcanberra-pulse/lunar,now 0.30-10ubuntu4 amd64 [installed,automatic]
libpulse-mainloop-glib0/lunar,now 1:16.1+dfsg1-2ubuntu3 amd64 [installed,automatic]
libpulse0/lunar,now 1:16.1+dfsg1-2ubuntu3 amd64 [installed,automatic]
libpulse0/lunar,now 1:16.1+dfsg1-2ubuntu3 i386 [installed,automatic]
pipewire-pulse/lunar,now 0.3.65-3 amd64 [installed,automatic]https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3487Occasional segfault when switching outputs2023-12-11T15:46:58ZDavid EmettOccasional segfault when switching outputsSince updating to 0.3.79, I've been seeing occasional segfaults in the `pipewire` daemon when switching outputs using commands like the following:
pactl set-card-profile alsa_card.pci-0000_0c_00.4 output:analog-surround-51
pactl...Since updating to 0.3.79, I've been seeing occasional segfaults in the `pipewire` daemon when switching outputs using commands like the following:
pactl set-card-profile alsa_card.pci-0000_0c_00.4 output:analog-surround-51
pactl set-sink-port alsa_output.pci-0000_0c_00.4.analog-surround-51 analog-output-speaker
The segfaults aren't always in the same place, however two coredumps show a crash in `spa_node_call_ready` in `audioadapter.c`'s `follower_ready`; GDB says `this->callbacks` is `{funcs = 0x0, data = 0x0}` which is presumably the issue?https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3486Volume control via hotkeys with nullsink as default sink2023-09-03T16:44:28ZSteve ParrisVolume control via hotkeys with nullsink as default sink<!-- 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.79
- 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.79
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: XFCE
- Kernel version (`uname -r`): 6.4.12-arch1-1
## Description of Problem:
When changing volume with **nullsink** as **default sink** the volume doesn't change. Volume is controlled by keyboard/hotkeys (handled by xfce4-pulseaudio-plugin). It always controls the **default sink**. Technically, the volume _does_ change for nullsink (as seen in **pavucontrol**) but nullsink doesn't seem to care about it. That's ok for a virtual sink and i probably should change my soundcard sink instead.
I have 3 output sinks and set them as **default sink** as needed.
1) Soundcard (PCI)
2) Monitor (HDMI)
3) nullsink
Changing **default sink** to 1) or 2) also changes volume control for the hotkeys correspondingly. That's ok (and should be like this).
For 3) i would need to control a different sink (instead of the default sink).
So, how to set 3) as default sink and 1) as volume control?
Something like Alsa's separation pcm.!default and ctl.!default.
Any solution for this?https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3485Sample rate discrepancy?2023-09-06T13:42:12ZJean-Michaël CelerierSample rate discrepancy?Hello,
I have a node created with pw_filter_new_simple and the following properties:
```
PW_KEY_MEDIA_TYPE, "Audio",
PW_KEY_MEDIA_CATEGORY, "Duplex",
PW_KEY_MEDIA_ROLE, "DSP",
PW_KEY_MEDIA_NAME, "ossia",
PW_KEY_NODE_LATENCY, "256/44100"...Hello,
I have a node created with pw_filter_new_simple and the following properties:
```
PW_KEY_MEDIA_TYPE, "Audio",
PW_KEY_MEDIA_CATEGORY, "Duplex",
PW_KEY_MEDIA_ROLE, "DSP",
PW_KEY_MEDIA_NAME, "ossia",
PW_KEY_NODE_LATENCY, "256/44100",
PW_KEY_NODE_RATE, "1/44100",
PW_KEY_NODE_FORCE_QUANTUM, "true",
PW_KEY_NODE_LOCK_QUANTUM, "true",
PW_KEY_NODE_ALWAYS_PROCESS, "true",
PW_KEY_NODE_LOCK_RATE, "true",
PW_KEY_NODE_FORCE_RATE, "true",
PW_KEY_NODE_PAUSE_ON_IDLE, "false",
PW_KEY_NODE_SUSPEND_ON_IDLE, "false",
```
It shows up in pw-top as this:
R 64 256 44100 47.6us 39.1us 0.01 0.01 0 + ossia score
but from within my process function, given `struct spa_io_position* position`, I see `position->clock.rate == 1/48000` and the function is indeed called at a 256/48000 rate (I observe 5.33 milliseconds between calls). Where does this mismatch happen, what can I do?
Setting
PIPEWIRE_LATENCY=256/44100
PIPEWIRE_QUANTUM=256/44100
seems to have no effect with pipewire directly.
Going through the JACK API works.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3484Firefox: can't move streams2023-10-23T14:48:50ZYuriFirefox: can't move streams- PipeWire version (`pipewire --version`): 0.3.79
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Debian unstable
- Desktop Environment: n/a
- Kernel version (`uname -r`): 6.4.13
## Description of Problem...- PipeWire version (`pipewire --version`): 0.3.79
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Debian unstable
- Desktop Environment: n/a
- Kernel version (`uname -r`): 6.4.13
## Description of Problem:
A new problem appeared in recent versions of pipewire+Firefox (can't say exactly which version introduced it) where I can't move the input stream of Firefox during an audio call when using meet or slack (and likely others) when disconnecting devices or directly using pavucontrol. For example, if I disconnect a BT headset during a call, the recording stream becomes connected to "unknown" until I essentially reload the firefox page.
I know there's a Pulse quirk for Firefox that was added to allow moving streams to bypass this dumb firefox policy. However just perusing the preferences, it seems that with FF 117 the "media.webrtc.capture.allow-pipewire" now set as default, so maybe that quirk is no longer applied as FF is now directly attached to pw?
At least the policy is only listed in the pulse configuration.
## How Reproducible:
Always
### Steps to Reproduce:
1. Start a call with FF with a removable device
2. Remove that device mid-call
### Actual Results:
3. Notice how the connected stream becomes "unknown" in pavucontrol
### Expected Results:
Let me reroute the streams as I please.
# Additional Info (as attachments):
I'm not using my usual setup as I'm writing this, however I can provide more details later.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3483Sound suddenly became very quiet in some apps2023-09-01T21:23:13ZAlex PantechovskisSound suddenly became very quiet in some apps<!-- 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.78
- 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.78
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): EndeavourOS
- Desktop Environment: KDE
- Kernel version (`uname -r`): 6.4.12-arch1-1
## Description of Problem:
Suddenly some apps became very quiet, such as Skype(I think it use ALSA directly?). I think it happened after pairing via Bluetooth with an iPhone (to use the PC headphones/mic there). But it’s unpaired now.
As suggested in the Arch wiki I checked volume in `alsamixer` -> F6, if I increase from 37 to 100 Skype becomes better but other apps/sounds become too loud, the volume in KDE becomes 100%.
Skype volume in KDE and `pavucontrol` is 100%.
## How Reproducible:
### Steps to Reproduce:
Unclear, possibly related to using Bluetooth with iPhone (setting the PC as Headphones in iOS).
# Additional Info (as attachments):
![2023-08-31_15-16](/uploads/c1d0a8ce1717e79e78241e936e3a08fb/2023-08-31_15-16.png)
![2023-08-31_15-17](/uploads/8722e73d09344ea6e5fcd8cc376e400a/2023-08-31_15-17.png)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3482general protection fault in libspa-bluez5.so2023-09-10T13:06:57ZJohn Smithgeneral protection fault in libspa-bluez5.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.79
Linked with libpipewire 0.3.79
```
- ...<!-- 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.79
Linked with libpipewire 0.3.79
```
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
`Debian GNU/Linux trixie/sid`
- Desktop Environment:
`KDE (Plasma 5.27.7, Frameworks 5.107.0, Qt 5.15.10, X11, NVidia)`
- Kernel version (`uname -r`):
6.5.0-bcachefs ([git commit](https://github.com/koverstreet/bcachefs/commit/493c276e))
## Description of Problem:
(Originally reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050916)
I noticed this line in dmesg after a Bluetooth audio loss:
`[96307.727270] traps: wireplumber[2128] general protection fault ip:7f7b0145d29f sp:7f7b03ffe950 error:0 in libspa-bluez5.so[7f7b01449000+b1000]`
I had a audio playing in Firefox, which I believe should have been the only app using audio. The computer was essentially idle at the moment it crashed, I wasn't touching the audio/bluetooth settings or the headset.
The bluetooth headset is a WH-1000XM4 using A2DP/LDAC. I'm running trixie/sid, up-to-date as of today.
```shell
$ uname -a
Linux home 6.5.0-bcachefs #35 SMP PREEMPT_DYNAMIC Wed Aug 30 00:31:55 CEST 2023 x86_64 GNU/Linux
```
The wireplumber journal has a backtrace for this crash:
```
$ journalctl --user -u wireplumber
août 31 11:00:03 home wireplumber[1970]: 0x55d23cc770e8: error 24
août 31 11:00:03 home wireplumber[1970]: (bluez_output.94_DB_56_EA_55_42.1-59) running -> error (Received error event)
août 31 11:00:03 home wireplumber[1970]: Failure in Bluetooth audio transport /org/bluez/hci0/dev_94_DB_56_EA_55_42/sep3/fd2
août 31 11:00:33 home wireplumber[1970]: RFCOMM receive command but modem not available: AT+NREC=0
août 31 13:05:37 home systemd-coredump[156718]: [🡕] Process 1970 (wireplumber) of user 1000 dumped core.
Module libudev.so.1 from deb systemd-254.1-3.amd64
Module libsystemd.so.0 from deb systemd-254.1-3.amd64
Stack trace of thread 2128:
#0 0x00007f7b0145d29f n/a (libspa-bluez5.so + 0x2129f)
#1 0x00007f7b0145e813 n/a (libspa-bluez5.so + 0x22813)
#2 0x00007f7b0127721c n/a (libspa-audioconvert.so + 0x1221c)
#3 0x00007f7b09a20e01 n/a (libpipewire-0.3.so.0 + 0x74e01)
#4 0x00007f7b09ceddf6 n/a (libspa-support.so + 0x9df6)
#5 0x00007f7b099f6700 n/a (libpipewire-0.3.so.0 + 0x4a700)
#6 0x00007f7b098523ec start_thread (libc.so.6 + 0x883ec)
#7 0x00007f7b098d2940 __clone (libc.so.6 + 0x108940)
Stack trace of thread 2125:
#0 0x00007f7b098d2e26 epoll_wait (libc.so.6 + 0x108e26)
#1 0x00007f7b09cfc440 n/a (libspa-support.so + 0x18440)
#2 0x00007f7b09cedd3d n/a (libspa-support.so + 0x9d3d)
#3 0x00007f7b09a57265 n/a (libpipewire-0.3.so.0 + 0xab265)
#4 0x00007f7b098523ec start_thread (libc.so.6 + 0x883ec)
#5 0x00007f7b098d2940 __clone (libc.so.6 + 0x108940)
Stack trace of thread 1970:
#0 0x00007f7b098c59ef __GI___poll (libc.so.6 + 0xfb9ef)
#1 0x00007f7b09b00567 n/a (libglib-2.0.so.0 + 0x59567)
#2 0x00007f7b09b00ebf g_main_loop_run (libglib-2.0.so.0 + 0x59ebf)
#3 0x000055d23aa846e9 n/a (wireplumber + 0x26e9)
#4 0x00007f7b097f16ca __libc_start_call_main (libc.so.6 + 0x276ca)
#5 0x00007f7b097f1785 __libc_start_main_impl (libc.so.6 + 0x27785)
#6 0x000055d23aa84831 n/a (wireplumber + 0x2831)
Stack trace of thread 2132:
#0 0x00007f7b098caeb9 syscall (libc.so.6 + 0x100eb9)
#1 0x00007f7b09b5a770 g_cond_wait (libglib-2.0.so.0 + 0xb3770)
#2 0x00007f7b09acaf2b n/a (libglib-2.0.so.0 + 0x23f2b)
#3 0x00007f7b09b2d712 n/a (libglib-2.0.so.0 + 0x86712)
#4 0x00007f7b09b2d0cd n/a (libglib-2.0.so.0 + 0x860cd)
#5 0x00007f7b098523ec start_thread (libc.so.6 + 0x883ec)
#6 0x00007f7b098d2940 __clone (libc.so.6 + 0x108940)
Stack trace of thread 2129:
#0 0x00007f7b098c59ef __GI___poll (libc.so.6 + 0xfb9ef)
#1 0x00007f7b09b00567 n/a (libglib-2.0.so.0 + 0x59567)
#2 0x00007f7b09b00bfc g_main_context_iteration (libglib-2.0.so.0 + 0x59bfc)
#3 0x00007f7b09b00c41 n/a (libglib-2.0.so.0 + 0x59c41)
#4 0x00007f7b09b2d0cd n/a (libglib-2.0.so.0 + 0x860cd)
#5 0x00007f7b098523ec start_thread (libc.so.6 + 0x883ec)
#6 0x00007f7b098d2940 __clone (libc.so.6 + 0x108940)
Stack trace of thread 2134:
#0 0x00007f7b098c59ef __GI___poll (libc.so.6 + 0xfb9ef)
#1 0x00007f7b09b00567 n/a (libglib-2.0.so.0 + 0x59567)
#2 0x00007f7b09b00ebf g_main_loop_run (libglib-2.0.so.0 + 0x59ebf)
#3 0x00007f7b096f78a6 n/a (libgio-2.0.so.0 + 0x11e8a6)
#4 0x00007f7b09b2d0cd n/a (libglib-2.0.so.0 + 0x860cd)
#5 0x00007f7b098523ec start_thread (libc.so.6 + 0x883ec)
#6 0x00007f7b098d2940 __clone (libc.so.6 + 0x108940)
ELF object binary architecture: AMD x86-64
août 31 13:05:37 home systemd[1946]: wireplumber.service: Main process exited, code=dumped, status=11/SEGV
août 31 13:05:37 home systemd[1946]: wireplumber.service: Failed with result 'core-dump'.
août 31 13:05:37 home systemd[1946]: wireplumber.service: Consumed 5min 21.857s CPU time.
août 31 13:05:38 home systemd[1946]: wireplumber.service: Scheduled restart job, restart counter is at 1.
août 31 13:05:38 home systemd[1946]: Started wireplumber.service - Multimedia Service Session Manager.
```
A copy of the core dump may be downloaded at:
https://alacrem.net/core/core.wireplumber.1000.d1b300fdcd144e2c816036f4e6c40d9e.1970.1693479937000000.zst
<details><summary>(The pipewire journal also shows a crash, which I only notice in retrospect is on a previous day and probably unrelated)</summary>
```
$ journalctl --user -u pipewire
-- Boot c156c1df2e4f46c1a5d13e0309961d0f --
août 26 15:53:01 home systemd[1640]: Started pipewire.service - PipeWire Multimedia Service.
août 27 08:02:04 home systemd-coredump[31275]: [🡕] Process 1669 (pipewire) of user 1000 dumped core.
Module libudev.so.1 from deb systemd-254.1-3.amd64
Module libsystemd.so.0 from deb systemd-254.1-3.amd64
Stack trace of thread 1702:
#0 0x00007fb7874d4eab n/a (libspa-audioconvert.so + 0x11eab)
#1 0x00007fb78ddb85a0 n/a (libspa-support.so + 0xd5a0)
#2 0x00007fb78ddb4df6 n/a (libspa-support.so + 0x9df6)
#3 0x00007fb78dcd94f0 n/a (libpipewire-0.3.so.0 + 0x4a4f0)
#4 0x00007fb78db353ec start_thread (libc.so.6 + 0x883ec)
#5 0x00007fb78dbb5940 __clone (libc.so.6 + 0x108940)
Stack trace of thread 1693:
#0 0x00007fb78dbb5e26 epoll_wait (libc.so.6 + 0x108e26)
#1 0x00007fb78ddc3440 n/a (libspa-support.so + 0x18440)
#2 0x00007fb78ddb4d3d n/a (libspa-support.so + 0x9d3d)
#3 0x00007fb78dd3a065 n/a (libpipewire-0.3.so.0 + 0xab065)
#4 0x00007fb78db353ec start_thread (libc.so.6 + 0x883ec)
#5 0x00007fb78dbb5940 __clone (libc.so.6 + 0x108940)
Stack trace of thread 1669:
#0 0x00007fb78dd26be2 pw_resource_destroy (libpipewire-0.3.so.0 + 0x97be2)
#1 0x00007fb78dcf12f5 pw_global_destroy (libpipewire-0.3.so.0 + 0x622f5)
#2 0x00007fb78dd0d798 pw_impl_node_destroy (libpipewire-0.3.so.0 + 0x7e798)
#3 0x00007fb78dd26c48 pw_resource_destroy (libpipewire-0.3.so.0 + 0x97c48)
#4 0x00007fb78dcc735d n/a (libpipewire-0.3.so.0 + 0x3835d)
#5 0x00007fb787fcd15f n/a (libpipewire-module-protocol-native.so + 0x2115f)
#6 0x00007fb787fc454f n/a (libpipewire-module-protocol-native.so + 0x1854f)
#7 0x00007fb787fc47d9 n/a (libpipewire-module-protocol-native.so + 0x187d9)
#8 0x00007fb78ddb4df6 n/a (libspa-support.so + 0x9df6)
#9 0x00007fb78dcfd698 pw_main_loop_run (libpipewire-0.3.so.0 + 0x6e698)
#10 0x000055c641aa945f n/a (pipewire + 0x145f)
#11 0x00007fb78dad46ca __libc_start_call_main (libc.so.6 + 0x276ca)
#12 0x00007fb78dad4785 __libc_start_main_impl (libc.so.6 + 0x27785)
#13 0x000055c641aa9601 n/a (pipewire + 0x1601)
ELF object binary architecture: AMD x86-64
août 27 08:02:04 home systemd[1640]: pipewire.service: Main process exited, code=dumped, status=11/SEGV
août 27 08:02:04 home systemd[1640]: pipewire.service: Failed with result 'core-dump'.
août 27 08:02:04 home systemd[1640]: pipewire.service: Consumed 4min 21.552s CPU time.
août 27 08:02:04 home systemd[1640]: pipewire.service: Scheduled restart job, restart counter is at 1.
```
</details>
State of various packages with more or less related names:
```
i libspa-0.2-bluetooth
p libspa-0.2-bluetooth:i386
p libspa-0.2-dev
p libspa-0.2-dev:i386
i libspa-0.2-jack
p libspa-0.2-jack:i386
p libspa-0.2-libcamera
p libspa-0.2-libcamera:i386
i A libspa-0.2-modules
p libspa-0.2-modules:i386
i bluedevil
i bluetooth
i bluez
i A bluez-obexd
i bluez-tools
i libbluetooth-dev
i A libbluetooth3
i A libkf5bluezqt-data
i libkf5bluezqt-dev
i A libkf5bluezqt-doc
i A libkf5bluezqt6
i libspa-0.2-bluetooth
i A qml-module-org-kde-bluezqt
i A libwireplumber-0.4-0
i wireplumber
i A libkpipewire5
i A libkpipewiredmabuf5
i A libkpipewirerecord5
i A libpipewire-0.3-0
i A libpipewire-0.3-common
i A libpipewire-0.3-modules
i pipewire
i A pipewire-alsa
i pipewire-audio
i A pipewire-bin
i pipewire-jack
i pipewire-pulse
i A qml-module-org-kde-pipewire
i A vlc-plugin-pipewire
i A libcanberra-pulse
i A libkf5pulseaudioqt3
i libpulse-dev
i libpulse-dev:i386
i A libpulse-mainloop-glib0
i A libpulse-mainloop-glib0:i386
i A libpulse0
i A libpulse0:i386
i A libpulsedsp
i libpulsedsp:i386
i pipewire-pulse
i A pulseaudio-utils
```
Please let me know I forgot something relevant, or if I can help further.
## How Reproducible:
I've not noticed previous instances of this crash, and I don't have a repro.
(I have not tried building pipewire from git, as I'm not sure I would be able to confirm if it were fixed w/o a repro).
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:
[pw-dump.log](/uploads/9783af0993e393ca32bd2a630fdc4719/pw-dump.log)
NOTE: This is _after_ a systemctl restart of wireplumber/pipewire, but with the same audio stream playing and same headset (re)connected.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3481pipe wire configuration question2023-11-30T14:44:37Zthrow awaypipe wire configuration questionIs there an equivalent of doing
pactl load-module module-null-sink sink_name=VirtualSpeaker sink_properties=device.description=VirtualSpeaker
pactl load-module module-null-sink media.class=Audio/Source/Virtual sink_name=VirtualMic cha...Is there an equivalent of doing
pactl load-module module-null-sink sink_name=VirtualSpeaker sink_properties=device.description=VirtualSpeaker
pactl load-module module-null-sink media.class=Audio/Source/Virtual sink_name=VirtualMic channel_map=front-left,front-right
pw-link VirtualSpeaker:monitor_FL VirtualMic:input_FL
pw-link VirtualSpeaker:monitor_FR VirtualMic:input_FR
inside of pipewires config files? More so the idea of linking deviceshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3480wishlist: add a mode in pw_stream to do pre-filling of future buffers as earl...2023-09-25T08:39:06ZGeorge Kiagiadakiswishlist: add a mode in pw_stream to do pre-filling of future buffers as early as possibleCurrently, in async (non-RT) playback mode, pw_stream calls the `process` callback about 1 driver period before the stream underruns, no matter how big is the stream's `node.latency` and the buffers it provides. So, for example, if the d...Currently, in async (non-RT) playback mode, pw_stream calls the `process` callback about 1 driver period before the stream underruns, no matter how big is the stream's `node.latency` and the buffers it provides. So, for example, if the driver's period is 1024 samples and the application fills 4096 samples on each buffer every time the `process` callback is called, then the stream will allow 3072 samples to be consumed before it calls the `process` callback again. In some cases, this is a bit tight, especially if the application needs to perform large amounts of processing or I/O in order to fill the next buffer.
This can be solved currently by having the application run a separate thread where it "pushes" into pw_stream, ignoring the `process` callback completely. It would be nice, though, if there was a mode that calls the `process` callback as soon as there is an available buffer to be dequeued for filling. This would allow the application to maintain a large queue fill level without having to run its own "push" thread.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3479LE audio issue on sink node2023-09-14T06:08:35ZsilviubarbulescuLE audio issue on sink nodeHello all,
I have an issue testing the LE audio support in Pipewire. I have a setup with 2 Ubuntu, BlueZ, enabled BlueZ Experimental ISO socket, and PipeWire (commit: 41dcac0ecdc3e03ada8787a9dad4b0421c618687) with LC3 support enabled.
...Hello all,
I have an issue testing the LE audio support in Pipewire. I have a setup with 2 Ubuntu, BlueZ, enabled BlueZ Experimental ISO socket, and PipeWire (commit: 41dcac0ecdc3e03ada8787a9dad4b0421c618687) with LC3 support enabled.
I'm trying to test the Bluetooth LE Audio setup connected or broadcast between these 2 Ubuntu PCs. My problem is that on the sink device, the PipeWire node is not created.
Investigating I found that the problem is commit cd24fe2f (bluez5: A2DP and BAP profiles to enumerate only codec profiles) because no codecless profiles are enumerated on the sink node and on the BAP sink we use codecless profiles.
@pvir I understand you test the comit with BAP connected. Am I missing something?
Attached PipeWire log from the LE audio connected sink node [log_pipewire.txt](/uploads/9c7a369c6954d2fc8583b6c645094ca9/log_pipewire.txt)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3478regression: distored audio2023-09-06T13:42:12ZRay Cregression: distored audio<!-- 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.65-3
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-releas...<!-- 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.65-3
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Ubuntu 23.04
- Desktop Environment: XFCE
- Kernel version (`uname -r`): 6.2.0-27-generic
## Description of Problem:
I originally opened this as a bug against nDAX: https://github.com/kc2g-flex-tools/nDAX/issues/13
nDAX is an application that streams audio to and from a FlexRadio ham radio.
But it turns out to be an issue with pipewire. Uninstalling pipewire and going back to pulseaudio solves this issue for me. This is a regression from pulseaudio.
What I'm seeing: Frequently after TX (to a the ndax sink), the RX audio (ndax source) will be distorted, as shown in the attached screenshot. The top is audio provided by nDAX on a host running Ubuntu 23.04. The bottom is WSJT-X running on windows, attached to the same slice receiving the distorted audio in Linux, but the windows DAX audio, where I don't see the issue. Changing bands and immediately changing back will sometimes correct the audio until I transmit a couple of times again... I changed bands/changed back in the 17:38:15 time slot, which is why the top of the waterfall looks normal.
## How Reproducible:
It seems random, tuned with a realtime profile seemed to help a bit, but really the key was uninstalling this and just going back to pulseaudio.
### Steps to Reproduce:
1. run nDAX with a connection to a flex radio (you get a source and a sink)
2. wait, it's sometimes goes bad soon after transmitting (ie sending audio out a sink)
### Actual Results:
Source audio is distorted.
### Expected Results:
Fidelity.
# Additional Info (as attachments):
![256897687-670db741-43b0-492c-bf6b-b9bf812e707d](/uploads/75550efbedc0bad939850f1ff9cce0e7/256897687-670db741-43b0-492c-bf6b-b9bf812e707d.png)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3477regression (pipewire-jack): Tracktion Waveform12 fails to read JACK connections2023-09-15T14:16:41ZSkyggeregression (pipewire-jack): Tracktion Waveform12 fails to read JACK connectionsWith the new (0.3.78) version Ardour can't read inputs and outputs as mentioned in #3475.
**But also Tracktion Waveform 12 Free/Pro can't use JACK backend anymore with these errors on the console:**
```
Cannot connect input port 0 (AIR ...With the new (0.3.78) version Ardour can't read inputs and outputs as mentioned in #3475.
**But also Tracktion Waveform 12 Free/Pro can't use JACK backend anymore with these errors on the console:**
```
Cannot connect input port 0 (AIR 192 14 Analog Spatial 7.1:capture_1_mic), error 22
Cannot connect input port 1 (AIR 192 14 Analog Spatial 7.1:capture_2_mic), error 22
Cannot connect input port 2 (AIR 192 14 Analog Spatial 7.1:capture_5_gtr), error 22
Cannot connect input port 3 (AIR 192 14 Analog Spatial 7.1:capture_6_gtr), error 22
Cannot connect input port 4 (AIR 192 14 Analog Spatial 7.1:capture_3_mic), error 22
Cannot connect input port 5 (AIR 192 14 Analog Spatial 7.1:capture_4_mic), error 22
Cannot connect input port 6 (AIR 192 14 Analog Spatial 7.1:capture_7_line), error 22
Cannot connect input port 7 (AIR 192 14 Analog Spatial 7.1:capture_8_line), error 22
Cannot connect output port 0 (AIR 192 14 Analog Spatial 4.0:playback_output1), error 22
Cannot connect output port 1 (AIR 192 14 Analog Spatial 4.0:playback_output2), error 22
Cannot connect output port 2 (AIR 192 14 Analog Spatial 4.0:playback_output3), error 22
Cannot connect output port 3 (AIR 192 14 Analog Spatial 4.0:playback_output4), error 22
```
Downgrading pipewire to 0.3.76 (or switching to ALSA backend) makes it work again.
Is pipewire-jack tested before release?
But, to be not only so sarcastic, I want to thank you for resolving audio popping/crackling in 0.3.78 when adjusting system volume (in KDE Plasma) :D Great job, thanks!https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3476regression(pipewire-pulse): unable to open monitor source devices as of 0.3.772023-09-06T13:42:12ZNick Parkerregression(pipewire-pulse): unable to open monitor source devices as of 0.3.77I'm seeing errors attempting to open monitor devices via SDL2 on pipewire-pulse-0.3.77 and newer. The the monitor devices appear in the list of sources, but when trying to open them by name, sdl2 fails with "Requested PulseAudio sink/sou...I'm seeing errors attempting to open monitor devices via SDL2 on pipewire-pulse-0.3.77 and newer. The the monitor devices appear in the list of sources, but when trying to open them by name, sdl2 fails with "Requested PulseAudio sink/source missing?"
The failure first appears on pipewire-pulse-0.3.77. Downgrading to pipewire-pulse-0.3.76 allowed monitor devices to be opened again. Given this, I assume the regression is via [this commit](https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/3a8894d2a4f72879cea146ae270b6b50ac7b6576), looks related going by how it mentions naming of monitor devices?
For example, sdl2 could return a list of devices like this:
- "Monitor of Tiger Lake-LP Smart Sound Technology Audio Controller Speaker + Headphones"
- "Tiger Lake-LP Smart Sound Technology Audio Controller Headset Mono Microphone + Headphones Stereo Microphone"
- "Tiger Lake-LP Smart Sound Technology Audio Controller Digital Microphone"
Trying to then open the source device named "Monitor of Tiger Lake-LP Smart Sound Technology Audio Controller Speaker + Headphones" fails on 0.3.77 (and newer), succeeds on 0.3.76 (and older).
I've been able to repro this across two machines, so it doesn't seem to be specific to the hardware. On one of them, I switched back to stock pulseaudio which also allowed Monitor devices to be opened again.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3475regression(pipewire-jack): Ardour fails to read JACK connections2023-09-15T14:16:40ZMichele Sorcinelliregression(pipewire-jack): Ardour fails to read JACK connectionsWhen making a JACK port connection through Ardour interface, Ardour is now unaware of the actual connection being made, even if it appears in qpwgraph.
From bisect I got 31f91ce9f4302cea55244ab741022e40bbd4e716, and reverting that and ...When making a JACK port connection through Ardour interface, Ardour is now unaware of the actual connection being made, even if it appears in qpwgraph.
From bisect I got 31f91ce9f4302cea55244ab741022e40bbd4e716, and reverting that and c41c812325ca1b0db1efc2fc06a3c90355be59d9 fixes the problem.
Steps to reproduce:
- open a new ardour session
- see how there's no output connected to the master track
- try to connect master track to an output
What should happen:
- the master track should show the connected outputs
What happens instead:
- the master track doesn't show any connected output
- pwgraph shows the connection as being made
The same can be reproduced with input ports, both MIDI and Audio.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3474After idle, the sound controls and devices are broken.2023-08-29T14:20:47ZЄгор ГеращенкоAfter idle, the sound controls and devices are broken.<!-- 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.77
- 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.77
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Void Linux
- Desktop Environment: KDE Plasma (Wayland)
- Kernel version (`uname -r`): 6.3.13_1
## Description of Problem:
The device sound output list is broken, you can't adjust the sound less than or above 45-55%.
## How Reproducible:
???
### Steps to Reproduce:
1. Log in to a KDE session.
2. Do nothing, wait until KDE locks the screen and the screen goes out.
3. Wake up the system
### Actual Results:
[2023-08-29_11-29-13.mkv](/uploads/de38225732b2def103e923b08fab29c3/2023-08-29_11-29-13.mkv)
After the above steps (Steps to Reproduce), it is not possible to adjust the sound above or below 45-55%.
### Expected Results:
[2023-08-29_10-41-46.mkv](/uploads/0751c213495f1f3f2eca528cf674e9bd/2023-08-29_10-41-46.mkv)
The sound works and adjusts as before.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/15906abbdc814d146dd3846fdba1c733/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3473Can't connect ports in Ardour 7.5 using PW 0.3.782023-08-29T08:09:00ZBruno UnnaCan't connect ports in Ardour 7.5 using PW 0.3.78<!-- 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.78
- 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.78
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: cinnamon 5.8.4
- Kernel version (`uname -r`): 6.4.12-zen1-1-zen
## Description of Problem:
After updating to pipewire 0.3.78, from 0.3.77, I lost the ability to connect hardware ports in Ardour. Normally, I would either right-click at the top of the mixer strip, or open the audio-connections window, and I would be able to check the connections I wanted. For example, I could connect channels left and right from my digital interface to channels left and right of my guitar track.
Downgrading pipewire to 0.3.77 removes the problem.
## How Reproducible:
After the update it was happening all the time with new projects.
### Steps to Reproduce:
1. Update pipewire to 0.3.78 (called 1:0.3.78-1 in Arch Linux).
2. Open Ardour.
3. Create an audio track.
4. Try to connect the track to an external hardware source using Ardour's audio connections window.
### Actual Results:
The dots that indicate the connection in the connection matrix don't stick. The connection appears to be made anyway, because I can see the corresponding lines in qpwgraph and helvum, and because when arming the track for recording the signal can be monitored. But Ardour won't record it (or won't display the recording).
### Expected Results:
Clicking on the connection matrix should enable/disable the connections, recording should produce regions unequivocally, the state of the connection of ports should be consistent between Ardour and qpwgraph.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3472Since PW 0.3.78 Guitarix is silent2023-08-31T18:17:21ZYann ColletteSince PW 0.3.78 Guitarix is silent<!-- 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.78
- Distribution and distribution version Fedora 37
- Desktop Environment: KDE
...<!-- 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.78
- Distribution and distribution version Fedora 37
- Desktop Environment: KDE
- Kernel version (`uname -r`): 6.4.12-100.fc37.x86_64
## Description of Problem:
Since 0.3.78, Guitarix audio processor is silent. It looks like no audio input comes in Guitarix.
Was working with the previous version of PW: 0.3.77
## How Reproducible:
Each time I use Gutarix (0.44.1).
I also use rakarrack-plus, but with this one, everything is OK (1.2.3).
### Steps to Reproduce:
1. Start Guitarix
2. Connect one input into gx_head_amp
3. Connect the output of gx_head_amp to gx_head_fx
4. Connect the outputs of gx_head_fx to audio out
### Actual Results:
No sound
### Expected Results:
Normally, you should hear the input processed by guitarixhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3471Inconsistent ALSA sink names2023-08-29T14:14:50ZgudvinrInconsistent ALSA sink names<!-- 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.78
- 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.78
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: KDE Plasma 5.27.7
- Kernel version (`uname -r`): 6.1.47-1-lts
## Description of Problem:
I have analog stereo ALSA sink which might have one of 2 different names in pipewire:
* alsa_output.pci-0000_00_1f.3.3.analog-stereo
* alsa_output.pci-0000_00_1f.3.analog-stereo
I don't know why it has one name over another and it makes automated control though scripts very annoying and unreliable.
Before I switched to PW, PA didn't have this issue (although it had completely different name from either of this).
This audio controller has different sinks:
* Line Out
* Headphones (combined with mic)
* SPDIF output
I use headphones output exclusively and those are always connected.
## How Reproducible:
It is basically random in a sense that I cannot predict what the name will be on the next system startup.
So far I think that it's about 50/50 chance.
### Steps to Reproduce:
1. Start the system
### Actual Results:
Sink name might be either 1 or 2.
### Expected Results:
Having consistent sink name.
# Additional Info (as attachments):
- Audio device: Intel Corporation CM238 HD Audio Controller (rev 31)
- `pw-dump > pw-dump.log` (for alsa_output.pci-0000_00_1f.**3.3**.analog-stereo): [pw-dump.3.3.log](/uploads/f92b439da5a684f796eb8dffa6732b54/pw-dump.3.3.log)
- `pw-dump > pw-dump.log` (for alsa_output.pci-0000_00_1f.**3**.analog-stereo): [pw-dump.3.log](/uploads/18d7582252df497d2396deb33f405b12/pw-dump.3.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3468Pipewire crashing when creating certain connections in pw-jack2023-09-24T18:43:19ZUltraBlackPipewire crashing when creating certain connections in pw-jack<!-- 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.78
- 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.78
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Garuda Linux
- Desktop Environment: Hyprland
- Kernel version (`uname -r`): 6.4.12-zen1-1-zen
## Description of Problem:
For quite a while now, pipewire has been sometimes randomly crashing when I make certain connections in pw-jack (with carla, if that's relevant)
## How Reproducible:
I haven't found a reliable setup, it crashes pretty regularly just by creating connections around zrythm
### Steps to Reproduce:
Download Zrythm, and connect some in- and outputs. Sometimes pipewire just crashes from that.
It seems to occur more often when there is a "connection loop", as follows (for my setup):
Midi interface in -> Midi interface out
Midi interface in -> Zrythm input -> zrythm output -> midi interface out
# Additional Info (as attachments):
- [coredump](https://chonkyrabbit.eu/lettermbox/8xpng1/)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3467Locking Screen Breaks Sound2023-08-29T08:33:35Zjasker5183Locking Screen Breaks 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.78
- 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.78
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Fedora Linux 38 (Workstation Edition)
- Desktop Environment: Gnome 44.4
- Kernel version (`uname -r`): 6.4.11-200.fc38.x86_64
## Description of Problem:
When I lock my screen and unlock it again Pipewire produces no sound, I then have to restart Pipewire to get sound working again.
I notice that `systemctl status pipewire` shows:
````
Aug 25 20:12:47 host pipewire[53146]: spa.audioadapter: was started
Aug 25 20:12:47 host pipewire[53146]: mod.client-node: node 0x55642d09b6f0: set_param Spa:Enum:ParamId:PortConfig (11) 0x55642d0652f8: Input/output error
Aug 25 20:12:47 host pipewire[53146]: pw.core: 0x55642d023b70: error -5 for resource 2: node_set_param(Spa:Enum:ParamId:PortConfig) failed: Input/output error
Aug 25 20:12:47 host pipewire[53146]: mod.client-node: 0x55642d0f3230: error seq:879 -5 (node_set_param(Spa:Enum:ParamId:PortConfig) failed: Input/output error)
````
## How Reproducible:
Every time I lock my screen with 0.3.78 this happens.
### Steps to Reproduce:
1. Lock screen.
2. Unlock screen.
3. No sound.
### Actual Results:
No sound after screen unlock.
### Expected Results:
Sound after screen unlock.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:
* [pw-dump-working.log](/uploads/a72e26f2d32806e820b9f11a41d6d4e0/pw-dump-working.log)
* [pw-dump-broken.log](/uploads/78787fb136ba27fa3c85daa290520aeb/pw-dump-broken.log)