pipewire issueshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues2022-10-21T18:56:05Zhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2255Crowded /etc/alsa/conf.d causes quirky sound behavior2022-10-21T18:56:05ZLukas WiestCrowded /etc/alsa/conf.d causes quirky sound behavior<!--
- PipeWire version (`pipewire --version`):
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
- Desktop Environment:
- Kernel version (`uname -r`):
-->
__Disclaimer:__
The issue turned out to be not ...<!--
- PipeWire version (`pipewire --version`):
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
- Desktop Environment:
- Kernel version (`uname -r`):
-->
__Disclaimer:__
The issue turned out to be not a specific application but everything using a Alsa sound device and in the end I could track down the strange behaviour to an crowded Alsa configuration folder, [see my comment below](#note_1420452).
| | | | | |
|--------------------------|---------------------------------------|----------------------|-------------------------------|------------------|
| Distribution and version | Fedora Linux 35 (Workstation Edition) | Ubuntu 20.04.4 LTS | Debian GNU/Linux bookworm/sid | Manjaro Linux |
| Pipewire version | 0.3.48 | 0.3.48 | 0.3.48 | 0.3.48 |
| Wireplumber version | 0.4.9-1 | 0.4.8.r20.gb95da33-1 | 0.4.9-1 | 0.4.8-2 |
| Desktop Environment | Gnome 41 Wayland | Gnome 41 Wayland | Gnome 42 Wayland | Gnome 41 Wayland |
| Kernel version | 5.16 | 5.16 | 5.16 | 5.15 |
| state | :white_check_mark: | :x: | :x: | :x: |
## Description of Problem:
[sts]: https://www.stellwerksim.de/
I've a Java Webstart game called [Stellwerksim][sts], running it with OpenWebStart.
This game has a self-test on startup built in.
The sound check is audible, but the application never goes to pass the test on all tested systems other than Fedora.
The main difference is, that on Fedora pipewire was enabled by default already, while on Debian, Ubuntu and Manjaro I first had to disable pulseaudio and install \& enable pipewire.
I'm curious if it's just a configuration I maybe have to make on the other systems to get it to work there as well or what's causing this.
## How Reproducible:
replace pulseaudio with pipewire on Debian, Ubuntu or Manjaro with pipewire, see it not working. Install Fedora having pipewire out of the box it's working fine.
### Steps to Reproduce:
1. install [OpenWebStart](https://openwebstart.com/download/)
1. sign up on [Stellwerksim][sts]
1. download the application
1. run it see the self test never pass the audio test
### Actual Results:
Application won't start as self-test never passes or fails, just stays pending
### Expected Results:
Self test passes and application starts
# Additional Info (as attachments):
[pw-dump-fedora.txt](/uploads/8ce00d52ce30dca5caf649ba434fe8fa/pw-dump-fedora.txt)
[pw-dump-ubuntu.txt](/uploads/237cf823a4dacba8e1f5c356c35dfe71/pw-dump-ubuntu.txt)
[pw-dump-debian.txt](/uploads/07ee489759a45a7a5070d9fc677ef282/pw-dump-debian.txt)
[pw-dump-manjaro.txt](/uploads/ff74c8cb41065480a011b8ea68deca88/pw-dump-manjaro.txt)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2254Lenovo Thinkpad Dock not recognized (?)2022-07-14T11:41:55ZudaemonLenovo Thinkpad Dock not recognized (?)<!-- 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.49
- 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.49
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: Gnome 41
- Kernel version (`uname -r`): 5.17.1-arch1-1
## Description of Problem:
I have Thinkpad T410 running Arch Linux and Gnome 41, pipewire 0.3.49; the laptop is in a dock (Mini Dock Series 3) and it seems pipewire doesn't recognize the dock properly. That means the audio ports for headphones out and mic in are not forwarded, I guess. So, when running `pw-mon` in a terminal and plugging in headphones into the jack of the dock no change is monitored whereas it is monitored if I use the headphone jack of the laptop. btw. pavucontrol behaves accordingly i. e doesn't recognize (un-)plugging at the dock.
what happens when I play music and plug headphones into the dock's jack is that sound is muted. interestingly, within `alsamixer` I can observe that sound comes back if I unmute headphones and bring the volume up. but here sound is only sent through the dock's jack if both headphone and speaker are unmuted while volume is controlled only via the headphone-slider. so it's confusing.
so my question is: where do I have to go on investigating? probably it's a problem of alsa and not pipewire. but I remember that it worked with alsa and pulse (w/o pipewire).
thanks very much!
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:[pw-dump.log](/uploads/c21b38e91ffb7b4d2344c3d342ac1c88/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2253pw-dot stopped outputting anything between 0.3.47 and 0.3.482022-03-31T07:42:43ZLink Mauvepw-dot stopped outputting anything between 0.3.47 and 0.3.48<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): found on 0.3.49
- 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`): found on 0.3.49
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: Weston
- Kernel version (`uname -r`): 5.17.1-arch1-1
## Description of Problem:
`pw-dot` outputs an empty `digraph pipewire {}` pw.dot file, instead of the usual graph of stuff it used to, even with `-a`.
## How Reproducible:
Always.
### Steps to Reproduce:
1. Install pipewire 0.3.48 or 0.3.49
2. Make sure to kill any previous running version
3. Run `pw-dot && cat pw.dot`
### Actual Results:
```dot
digraph pipewire {
}
```
### Expected Results:
A graph with more stuff.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/250aef759e6663205da775a6b30667c4/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2252segfault in module-rt2022-04-01T09:49:04ZJonas Holmbergsegfault in module-rtGot a segfault in a program that plays sound to multiple alsasrc:es in different threads:
```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x736d61f2 in spa_list_insert (elem=0x75b238c4, list=0x75b50065) at ../git/spa/...Got a segfault in a program that plays sound to multiple alsasrc:es in different threads:
```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x736d61f2 in spa_list_insert (elem=0x75b238c4, list=0x75b50065) at ../git/spa/include/spa/utils/list.h:61
[Current thread is 1 (LWP 1286)]
#0 0x736d61f2 in spa_list_insert (elem=0x75b238c4, list=0x75b50065) at ../git/spa/include/spa/utils/list.h:61
#1 impl_create (data=0x75b8d898, props=<optimized out>, start_routine=0x7479584d <do_loop>, arg=0x75b20228) at ../git/src/modules/module-rt.c:677
#2 0x74795c26 in spa_thread_utils_create (props=0x0, start_routine=<optimized out>, arg=0x75b20228, o=<optimized out>) at ../git/spa/include/spa/support/thread.h:85
#3 pw_data_loop_start (loop=0x75b20228) at ../git/src/pipewire/data-loop.c:203
#4 0x74790cc6 in pw_context_new (main_loop=main_loop@entry=0x75b6d0b0, properties=<optimized out>, user_data_size=user_data_size@entry=0) at ../git/src/pipewire/context.c:408
#5 0x7480efcc in snd_pcm_pipewire_open (period_bytes=1280, channels=1, format=SND_PCM_FORMAT_S32_LE, rate=16000, flags=0, mode=1, stream=SND_PCM_STREAM_PLAYBACK, role=<optimized out>, capture_node=<optimized out>, playback_node=<optimized out>, server_name=0x0, node_name=0x0, name=0x75b175e0 "audiosink0", pcmp=0x75138fb8) at ../git/pipewire-alsa/alsa-plugins/pcm_pipewire.c:1067
#6 _snd_pcm_pipewire_open (pcmp=0x75138fb8, name=0x75b175e0 "audiosink0", root=<optimized out>, conf=<optimized out>, stream=SND_PCM_STREAM_PLAYBACK, mode=1) at ../git/pipewire-alsa/alsa-plugins/pcm_pipewire.c:1231
#7 0x748a6b38 in snd_pcm_open_conf (pcmp=pcmp@entry=0x75138fb8, name=name@entry=0x75b175e0 "audiosink0", pcm_root=pcm_root@entry=0xd35520, pcm_conf=0x75b17600, stream=stream@entry=SND_PCM_STREAM_PLAYBACK, mode=mode@entry=1) at ../../../alsa-lib-1.2.5.1/src/pcm/pcm.c:2609
#8 0x748a6fec in snd_pcm_open_noupdate (pcmp=pcmp@entry=0x75138fb8, root=root@entry=0xd35520, name=0x75b175e0 "audiosink0", stream=stream@entry=SND_PCM_STREAM_PLAYBACK, mode=mode@entry=1, hop=1) at ../../../alsa-lib-1.2.5.1/src/pcm/pcm.c:2668
#9 0x748a9762 in snd1_pcm_open_named_slave (pcmp=pcmp@entry=0x75138fb8, name=name@entry=0x0, root=root@entry=0xd35520, conf=0x75b175a8, stream=stream@entry=SND_PCM_STREAM_PLAYBACK, mode=mode@entry=1, parent_conf=parent_conf@entry=0x75b6cfc8) at ../../../alsa-lib-1.2.5.1/src/pcm/pcm.c:2821
#10 0x748d8d3a in _snd_pcm_asym_open (pcmp=0x75138fb8, name=0x0, root=0xd35520, conf=0x75b6cfc8, stream=SND_PCM_STREAM_PLAYBACK, mode=1) at ../../../alsa-lib-1.2.5.1/src/pcm/pcm_asym.c:112
#11 0x748a6b38 in snd_pcm_open_conf (pcmp=pcmp@entry=0x75138fb8, name=name@entry=0x0, pcm_root=pcm_root@entry=0xd35520, pcm_conf=pcm_conf@entry=0x75b6cfc8, stream=stream@entry=SND_PCM_STREAM_PLAYBACK, mode=mode@entry=1) at ../../../alsa-lib-1.2.5.1/src/pcm/pcm.c:2609
#12 0x748a9730 in snd1_pcm_open_named_slave (pcmp=pcmp@entry=0x75138fb8, name=name@entry=0x0, root=root@entry=0xd35520, conf=0x75b6cfc8, stream=stream@entry=SND_PCM_STREAM_PLAYBACK, mode=mode@entry=1, parent_conf=parent_conf@entry=0x75b6d208) at ../../../alsa-lib-1.2.5.1/src/pcm/pcm.c:2823
#13 0x748c4316 in snd_pcm_open_slave (parent_conf=0x75b6d208, mode=1, stream=SND_PCM_STREAM_PLAYBACK, conf=<optimized out>, root=0xd35520, pcmp=0x75138fb8) at ../../../alsa-lib-1.2.5.1/src/pcm/pcm_local.h:1008
#14 _snd_pcm_plug_open (pcmp=0x75b01eec, name=0x75b6b530 "default", root=0xd35520, conf=0x75b6d208, stream=SND_PCM_STREAM_PLAYBACK, mode=1) at ../../../alsa-lib-1.2.5.1/src/pcm/pcm_plug.c:1324
#15 0x748a6b38 in snd_pcm_open_conf (pcmp=pcmp@entry=0x75b01eec, name=name@entry=0x75b6b530 "default", pcm_root=pcm_root@entry=0xd35520, pcm_conf=0x75b6d208, stream=stream@entry=SND_PCM_STREAM_PLAYBACK, mode=mode@entry=1) at ../../../alsa-lib-1.2.5.1/src/pcm/pcm.c:2609
#16 0x748a6fec in snd_pcm_open_noupdate (pcmp=pcmp@entry=0x75b01eec, root=0xd35520, name=name@entry=0x75b6b530 "default", stream=stream@entry=SND_PCM_STREAM_PLAYBACK, mode=mode@entry=1, hop=hop@entry=0) at ../../../alsa-lib-1.2.5.1/src/pcm/pcm.c:2668
#17 0x748a93ae in snd_pcm_open (pcmp=pcmp@entry=0x75b01eec, name=0x75b6b530 "default", stream=stream@entry=SND_PCM_STREAM_PLAYBACK, mode=mode@entry=1) at ../../../alsa-lib-1.2.5.1/src/pcm/pcm.c:2698
#18 0x74924cae in gst_alsasink_open (asink=0x75b01cc0) at ../gst-plugins-base-1.18.3/ext/alsa/gstalsasink.c:859
#19 0x75a9d90a in gst_audio_ring_buffer_open_device (buf=0x75b6cbc0) at ../gst-plugins-base-1.18.3/gst-libs/gst/audio/gstaudioringbuffer.c:469
#20 0x75a930ba in gst_audio_base_sink_change_state (element=0x75b01cc0, transition=GST_STATE_CHANGE_NULL_TO_READY) at ../gst-plugins-base-1.18.3/gst-libs/gst/audio/gstaudiobasesink.c:2412
#21 0x76c9a2c4 in gst_element_change_state (element=0x75b01cc0, transition=<optimized out>) at ../gstreamer-1.18.3/gst/gstelement.c:3076
#22 0x76c9a3d4 in gst_element_set_state_func (element=0x75b01cc0, state=<optimized out>) at ../gstreamer-1.18.3/gst/gstelement.c:3030
#23 0x7366406a in gst_auto_detect_find_best (self=0x75b1f0c8) at ../gst-plugins-good-1.18.3/gst/autodetect/gstautodetect.c:313
#24 gst_auto_detect_detect (self=0x75b1f0c8) at ../gst-plugins-good-1.18.3/gst/autodetect/gstautodetect.c:374
#25 gst_auto_detect_change_state (element=0x75b1f0c8, transition=GST_STATE_CHANGE_NULL_TO_READY) at ../gst-plugins-good-1.18.3/gst/autodetect/gstautodetect.c:426
#26 0x76c9a2c4 in gst_element_change_state (element=0x75b1f0c8, transition=<optimized out>) at ../gstreamer-1.18.3/gst/gstelement.c:3076
#27 0x76c9a3d4 in gst_element_set_state_func (element=0x75b1f0c8, state=<optimized out>) at ../gstreamer-1.18.3/gst/gstelement.c:3030
#28 0x75ae2ed0 in try_element (playsink=0xd12d30, unref=1, element=0x75b1f0c8) at ../gst-plugins-base-1.18.3/gst/playback/gstplaysink.c:1466
#29 gen_audio_chain (raw=1, playsink=0xd12d30) at ../gst-plugins-base-1.18.3/gst/playback/gstplaysink.c:2703
#30 gst_play_sink_do_reconfigure (playsink=0xd12d30) at ../gst-plugins-base-1.18.3/gst/playback/gstplaysink.c:3557
#31 sinkpad_blocked_cb (blockedpad=<optimized out>, info=<optimized out>, user_data=0xd12d30) at ../gst-plugins-base-1.18.3/gst/playback/gstplaysink.c:4386
#32 0x76ca667c in probe_hook_marshal (hook=0x75b24468, data=0x751392b8) at ../gstreamer-1.18.3/gst/gstpad.c:3637
#33 0x76b591a6 in g_hook_list_marshal (hook_list=hook_list@entry=0x75b1e628, may_recurse=may_recurse@entry=1, marshaller=marshaller@entry=0x76ca6509 <probe_hook_marshal>, data=data@entry=0x751392b8) at ../glib-2.68.4/glib/ghook.c:672
#34 0x76ca63c6 in do_probe_callbacks (pad=pad@entry=0x75b1e5c0, info=info@entry=0x75139350, defaultval=defaultval@entry=GST_FLOW_OK) at ../gstreamer-1.18.3/gst/gstpad.c:3800
#35 0x76ca771e in gst_pad_push_event_unchecked (pad=pad@entry=0x75b1e5c0, event=0x75b1c2b0, type=type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../gstreamer-1.18.3/gst/gstpad.c:5435
#36 0x76ca7980 in push_sticky (pad=0x75b1e5c0, ev=0x751393d0, user_data=0x75139414) at ../gstreamer-1.18.3/gst/gstevent.h:412
#37 0x76ca6a16 in events_foreach (pad=pad@entry=0x75b1e5c0, func=0x76ca7945 <push_sticky>, user_data=user_data@entry=0x75139414) at ../gstreamer-1.18.3/gst/gstpad.c:608
#38 0x76cab60e in check_sticky (event=0x75b1c2b0, pad=0x75b1e5c0) at ../gstreamer-1.18.3/gst/gstpad.c:4058
#39 gst_pad_push_event (pad=pad@entry=0x75b1e5c0, event=0x75b1c2b0) at ../gstreamer-1.18.3/gst/gstpad.c:5619
#40 0x76cab674 in event_forward_func (pad=0x75b1e5c0, data=0x7513948c) at ../gstreamer-1.18.3/gst/gstevent.h:412
#41 0x76ca9e54 in gst_pad_forward (pad=pad@entry=0x75b1e380, forward=0x76cab661 <event_forward_func>, user_data=user_data@entry=0x7513948c) at ../gstreamer-1.18.3/gst/gstpad.c:3074
#42 0x76ca9eca in gst_pad_event_default (pad=0x75b1e380, parent=<optimized out>, event=0x75b1c2b0) at ../gstreamer-1.18.3/gst/gstpad.c:3171
#43 0x76ca7196 in gst_pad_send_event_unchecked (pad=pad@entry=0x75b1e380, event=event@entry=0x75b1c2b0, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../gstreamer-1.18.3/gst/gstpad.c:5844
#44 0x76ca77fe in gst_pad_push_event_unchecked (pad=pad@entry=0x75b6b910, event=0x75b1c2b0, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../gstreamer-1.18.3/gst/gstpad.c:5488
#45 0x76ca7980 in push_sticky (pad=0x75b6b910, ev=0x751395a8, user_data=0x751395ec) at ../gstreamer-1.18.3/gst/gstevent.h:412
#46 0x76ca6a16 in events_foreach (pad=pad@entry=0x75b6b910, func=0x76ca7945 <push_sticky>, user_data=user_data@entry=0x751395ec) at ../gstreamer-1.18.3/gst/gstpad.c:608
#47 0x76cab60e in check_sticky (event=0x75b1c2b0, pad=0x75b6b910) at ../gstreamer-1.18.3/gst/gstpad.c:4058
#48 gst_pad_push_event (pad=0x75b6b910, event=0x75b1c2b0) at ../gstreamer-1.18.3/gst/gstpad.c:5619
#49 0x76ca7196 in gst_pad_send_event_unchecked (pad=pad@entry=0x75b526b8, event=event@entry=0x75b1c2b0, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../gstreamer-1.18.3/gst/gstpad.c:5844
#50 0x76ca77fe in gst_pad_push_event_unchecked (pad=pad@entry=0x75b20bd8, event=0x75b1c2b0, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../gstreamer-1.18.3/gst/gstpad.c:5488
#51 0x76ca7980 in push_sticky (pad=0x75b20bd8, ev=0x75139718, user_data=0x7513975c) at ../gstreamer-1.18.3/gst/gstevent.h:412
#52 0x76ca6a16 in events_foreach (pad=pad@entry=0x75b20bd8, func=0x76ca7945 <push_sticky>, user_data=user_data@entry=0x7513975c) at ../gstreamer-1.18.3/gst/gstpad.c:608
#53 0x76cab60e in check_sticky (event=0x75b1c2b0, pad=0x75b20bd8) at ../gstreamer-1.18.3/gst/gstpad.c:4058
#54 gst_pad_push_event (pad=pad@entry=0x75b20bd8, event=0x75b1c2b0) at ../gstreamer-1.18.3/gst/gstpad.c:5619
#55 0x76cab674 in event_forward_func (pad=0x75b20bd8, data=0x751397d4) at ../gstreamer-1.18.3/gst/gstevent.h:412
#56 0x76ca9e54 in gst_pad_forward (pad=pad@entry=0x75b69b20, forward=0x76cab661 <event_forward_func>, user_data=user_data@entry=0x751397d4) at ../gstreamer-1.18.3/gst/gstpad.c:3074
#57 0x76ca9eca in gst_pad_event_default (pad=0x75b69b20, parent=<optimized out>, event=0x75b1c2b0) at ../gstreamer-1.18.3/gst/gstpad.c:3171
#58 0x76ca7196 in gst_pad_send_event_unchecked (pad=pad@entry=0x75b69b20, event=event@entry=0x75b1c2b0, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../gstreamer-1.18.3/gst/gstpad.c:5844
#59 0x76ca77fe in gst_pad_push_event_unchecked (pad=pad@entry=0x75b004b0, event=0x75b1c2b0, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../gstreamer-1.18.3/gst/gstpad.c:5488
#60 0x76ca7980 in push_sticky (pad=0x75b004b0, ev=0x751398f0, user_data=0x75139934) at ../gstreamer-1.18.3/gst/gstevent.h:412
#61 0x76ca6a16 in events_foreach (pad=pad@entry=0x75b004b0, func=0x76ca7945 <push_sticky>, user_data=user_data@entry=0x75139934) at ../gstreamer-1.18.3/gst/gstpad.c:608
#62 0x76cab60e in check_sticky (event=0x75b1c2b0, pad=0x75b004b0) at ../gstreamer-1.18.3/gst/gstpad.c:4058
#63 gst_pad_push_event (pad=pad@entry=0x75b004b0, event=0x75b1c2b0) at ../gstreamer-1.18.3/gst/gstpad.c:5619
#64 0x76cab674 in event_forward_func (pad=0x75b004b0, data=0x751399ac) at ../gstreamer-1.18.3/gst/gstevent.h:412
#65 0x76ca9e54 in gst_pad_forward (pad=pad@entry=0x75b222f0, forward=0x76cab661 <event_forward_func>, user_data=user_data@entry=0x751399ac) at ../gstreamer-1.18.3/gst/gstpad.c:3074
#66 0x76ca9eca in gst_pad_event_default (pad=0x75b222f0, parent=<optimized out>, event=0x75b1c2b0) at ../gstreamer-1.18.3/gst/gstpad.c:3171
#67 0x76ca7196 in gst_pad_send_event_unchecked (pad=pad@entry=0x75b222f0, event=event@entry=0x75b1c2b0, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../gstreamer-1.18.3/gst/gstpad.c:5844
#68 0x76ca77fe in gst_pad_push_event_unchecked (pad=pad@entry=0x75b22080, event=0x75b1c2b0, type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../gstreamer-1.18.3/gst/gstpad.c:5488
#69 0x76ca7980 in push_sticky (pad=0x75b22080, ev=0x75139ac8, user_data=0x75139b0c) at ../gstreamer-1.18.3/gst/gstevent.h:412
#70 0x76ca6a16 in events_foreach (pad=pad@entry=0x75b22080, func=0x76ca7945 <push_sticky>, user_data=user_data@entry=0x75139b0c) at ../gstreamer-1.18.3/gst/gstpad.c:608
#71 0x76cab60e in check_sticky (event=0x75b20758, pad=0x75b22080) at ../gstreamer-1.18.3/gst/gstpad.c:4058
#72 gst_pad_push_event (pad=pad@entry=0x75b22080, event=0x75b20758) at ../gstreamer-1.18.3/gst/gstpad.c:5619
#73 0x7470883c in gst_pad_set_caps (caps=0x75b5ca30, pad=0x75b22080) at /usr/include/gstreamer-1.0/gst/gstcompat.h:59
#74 gst_wavparse_add_src_pad (wav=wav@entry=0x75b21c48, buf=buf@entry=0x75b37e40) at ../gst-plugins-good-1.18.3/gst/wavparse/gstwavparse.c:1943
#75 0x74708b4a in gst_wavparse_stream_data (wav=wav@entry=0x75b21c48, flushing=flushing@entry=0) at ../gst-plugins-good-1.18.3/gst/wavparse/gstwavparse.c:2110
#76 0x7470aa7e in gst_wavparse_loop (pad=0x75b22f88) at ../gst-plugins-good-1.18.3/gst/wavparse/gstwavparse.c:2251
#77 0x76cc39bc in gst_task_func (task=0x75b22480) at ../gstreamer-1.18.3/gst/gsttask.c:328
#78 0x76b80c16 in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib-2.68.4/glib/gthreadpool.c:354
#79 0x76b80512 in g_thread_proxy (data=0xced720) at ../glib-2.68.4/glib/gthread.c:826
#80 0x76a3cf3e in start_thread (arg=0x974a97c5) at pthread_create.c:434
```https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2250apparent non bit perfect playback with USB device2022-03-29T07:30:10ZNaomi Calabrettaapparent non bit perfect playback with USB deviceHello,
I am currently investigating a peculiar issue with my setup. Recently I bought a Scarlett 2i2 to use as my main audio interface; however, it seems that getting bit perfect playback out of it is rather tricky.
I checked the pw-top...Hello,
I am currently investigating a peculiar issue with my setup. Recently I bought a Scarlett 2i2 to use as my main audio interface; however, it seems that getting bit perfect playback out of it is rather tricky.
I checked the pw-top output and it all seems fine here:
```
65 256 44100 31.8µs 11.5µs 0.01 0.00 0 alsa_output.usb-Focusrite_Scarlett_2i2_USB_Y8KYW5Y1C173EF-00.pro-output-0
101 3969 44100 19.3µs 6.2µs 0.00 0.00 0 + strawberry
127 2048 192000 0.1µs 0.1µs 0.00 0.00 0 alsa_input.usb-Focusrite_Scarlett_2i2_USB_Y8KYW5Y1C173EF-00.pro-input-0
```
However, when I checked the card through procfs, things didn't quite align
```
% cat /proc/asound/card2/stream0
Focusrite Scarlett 2i2 USB at usb-0000:0f:00.3-2, high speed : USB Audio
Playback:
Status: Running
Interface = 1
Altset = 1
Packet Size = 200
Momentary freq = 192000 Hz (0x18.0000)
Interface 1
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 0x01 (1 OUT) (SYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
Bits: 24
Channel map: FL FR
Capture:
Status: Stop
Interface 2
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 0x81 (1 IN) (SYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Data packet interval: 125 us
Bits: 24
Channel map: FL FR
```
I am not really sure about what's happening here. I will attach my configuration here (everything else let's assume it's default values)
```
context.properties = {
## Configure properties in the system.
#library.name.system = support/libspa-support
#context.data-loop.library.name.system = support/libspa-support
#support.dbus = true
#link.max-buffers = 64
link.max-buffers = 16 # version < 3 clients can't handle more
#mem.warn-mlock = false
#mem.allow-mlock = true
#mem.mlock-all = false
#clock.power-of-two-quantum = true
#log.level = 2
#cpu.zero.denormals = false
core.daemon = true # listening for socket connections
core.name = pipewire-0 # core name and socket name
## Properties for the DSP configuration.
default.clock.rate = 192000
default.clock.allowed-rates = [ 44100 48000 88200 96000 176400 192000 ]
#default.clock.quantum = 1024
default.clock.min-quantum = 16
#default.clock.max-quantum = 2048
#default.clock.quantum-limit = 8192
#default.video.width = 640
#default.video.height = 480
#default.video.rate.num = 25
#default.video.rate.denom = 1
#
#settings.check-quantum = false
#settings.check-rate = false
#
# These overrides are only applied when running in a vm.
vm.overrides = {
default.clock.min-quantum = 1024
}
}
```
My system runs Artix Linux, on PipeWire 0.3.48 and WirePlumber 0.4.9https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2249Running Pipewire server without X11 or Wayland2022-05-13T20:02:22Zmanuel alfayateRunning Pipewire server without X11 or WaylandHi there,
I need to lauch several libSDL2 programs at the same time against the same audio device, on a system where ALSA's DMIX isn't going to work (Pi4 vc4hdmi audio device, if you are curious).
I am trying to bring up pipewire on th...Hi there,
I need to lauch several libSDL2 programs at the same time against the same audio device, on a system where ALSA's DMIX isn't going to work (Pi4 vc4hdmi audio device, if you are curious).
I am trying to bring up pipewire on this system, after I rebuild libSDL2 with pipewire support of course, so several SDL2 programs can connect to the pipewire server at the same time.
So far, I launch DBUS daemon like this:
`dbus-daemon --system --fork`
And then I got this when launching the pipewire server:
```
~/src/pipewire-0.3.39/b4# pipewire
[W][07900.486686] mod.rtkit | [ module-rtkit.c: 205 translate_error()] RTKit error: org.freedesktop.DBus.Error.ServiceUnknown
[W][07900.486895] mod.rtkit | [ module-rtkit.c: 465 set_nice()] could not set nice-level to -11: No such file or directory
[W][07900.487391] mod.rtkit | [ module-rtkit.c: 205 translate_error()] RTKit error: org.freedesktop.DBus.Error.ServiceUnknown
[E][07900.489333] spa.dbus | [ dbus.c: 349 impl_connection_get()] Failed to connect to session bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
[E][07900.489383] mod.portal | [ module-portal.c: 346 pipewire__module_init()] Failed to connect to session bus: Input/output error
[W][07900.491251] mod.rtkit | [ module-rtkit.c: 205 translate_error()] RTKit error: org.freedesktop.DBus.Error.ServiceUnknown
[W][07900.491615] mod.rtkit | [ module-rtkit.c: 205 translate_error()] RTKit error: org.freedesktop.DBus.Error.ServiceUnknown
[W][07900.491647] mod.rtkit | [ module-rtkit.c: 625 impl_acquire_rt()] could not make thread realtime: No such file or directory
```
...what seems to be really preventing SDL2 programs to run against pipewire is this part:
```
[E][07900.489333] spa.dbus | [ dbus.c: 349 impl_connection_get()] Failed to connect to session bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
[E][07900.489383] mod.portal | [ module-portal.c: 346 pipewire__module_init()] Failed to connect to session bus: Input/output error
```
This system has no X11 or Wayland sessions running, and SDL2 programs use KMS/DRM for video.
So, does pipewire work at all without X11/Wayland?
Also, is there something I can do about the DBUS i/o error?
Thanks!https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2248Pipewire does not switch to headphones when plugged in2022-03-28T16:28:19ZRizal MartinPipewire does not switch to headphones when plugged in<!-- 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`): Puppy Linux
- Desktop Environment: XFCE
- Kernel version (`uname -r`): 5.16.12
## Description of Problem:
The sound I/O does not switch automatically from speaker to headset when plugged in. It requires manually set sound I/O devices on pavucontrol.
### Steps to Reproduce:
1. Plug the headphone to the headphone jack.
### Actual Results:
1. The sound still playing on speakers. Internal mic was still active. Instead of using the plugged headset automatically. It requires to use pavucontrol to route sound to headset
### Expected Results:
1. The sound I/O will automatically redirected to headphone upon plugged in. And return to internal mic and speaker when headset was unplugged
# Additional Info (as attachments): [dump.log](/uploads/6cea43bfabc86ddf5d27df1b2a49bdda/dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2247Bluetooth: Issues connecting with bluetooth devices after service restart (br...2022-03-28T14:03:50ZAnimesh SahuBluetooth: Issues connecting with bluetooth devices after service restart (br-connection-profile-unavailable | le-connection-abort-by-local)<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
<!-- If you can, test also with Pulseaudio and list `pulseaudio --version`. -->
- PipeWire version (`pipewire --version`): li...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
<!-- If you can, test also with Pulseaudio and list `pulseaudio --version`. -->
- PipeWire version (`pipewire --version`): libpipewire 0.3.48
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Void Linux
- Desktop Environment: herbstluftwm
- Kernel version (`uname -r`): 5.16.16_1
- BlueZ version (`bluetoothctl --version`): bluetoothctl: 5.63
- `lsusb`:
```
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 27c6:609c Goodix Technology Co., Ltd. Goodix USB2.0 MISC
Bus 003 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 004: ID 8087:0032 Intel Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```
- Bluetooth devices:
```
Device D4:EC:AB:64:EC:96 V2040
```
## Description of Problem:
Bluetooth connection (testing with mobile as host and laptop as sound receiver), work and does not work.
It works if:
Installed package `bluez libspa-bluetooth`, enabled service `bluetoothd dbus pipewire pipewire-pulse` and rebooted (Note 1: does not work unless reboot). And any subsequent reboot it works by default. Restarting service `bluetoothd`, it still works, just need to connnect again.
```bash
sudo xbps-install -S dbus bluez libspa-bluetooth
for i in dbus bluetoothd pipewire pipewire-pulse; do sudo ln -s /etc/sv/$i /var/service; done
# at the moment does not work
[bluetooth]# connect D4:EC:AB:64:EC:96
Attempting to connect to D4:EC:AB:64:EC:96
Failed to connect: org.bluez.Error.Failed br-connection-profile-unavailable
sudo reboot
# works now
sudo sv restart bluetoothd
# still works, need to run `power on` then just connect as usual
sudo sv restart pipewire-pulse
# still works, nothing needed, no disconnection
```
And when does not work: At runtime when it was "working", restarted the pipewire service
```
sudo sv restart pipewire
# magically puts the following sequence at the bluetoothctl console and disconnects
[CHG] Controller F8:B5:4D:D7:15:6C Class: 0x004c010c
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 0000110e-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C Class: 0x000c010c
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 0000110e-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C Class: 0x0008010c
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 0000110e-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C Class: 0x0000010c
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 0000110e-0000-1000-8000-00805f9b34fb
[CHG] Controller F8:B5:4D:D7:15:6C UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Device D4:EC:AB:64:EC:96 ServicesResolved: no
[CHG] Device D4:EC:AB:64:EC:96 Connected: no
# Now this happens
[bluetooth]# connect D4:EC:AB:64:EC:96
Attempting to connect to D4:EC:AB:64:EC:96
Failed to connect: org.bluez.Error.Failed br-connection-profile-unavailable
# Now whatever I do, restart bluetoothd or pipewire-pulse services, in different sequences,
# or anything regardless, it "doesn't work", unless I reboot once again.
# Although when restarting bluetoothd service now, it stucks until the timeout (41s as measured by prompt),
# and then `le-connection-abort-by-local` (a different error)
sudo sv restart bluetoothd
[bluetooth]# connect D4:EC:AB:64:EC:96
Attempting to connect to D4:EC:AB:64:EC:96
Failed to connect: org.bluez.Error.Failed le-connection-abort-by-local
```
Now, removing the `libspa-bluetooth` package does not break anything at runtime when
connected, or trying connecting, everything works, booting without the package does not let me connect, post install needs reboot as specified earlier.
### Actual Results:
* Post installation of `libspa-bluetooth`, unless rebooted, cannot connect.
* Restarting `pipewire` when connection was working, breaks everything and unless rebooted I couldn't connect again.
### Expected Results:
* Post installation of `libspa-bluetooth`, it should not be required to reboot to make connection work.
* Restarting `pipewire` should just make bluetooth connection available again.
# Additional Info (as attachments):
Let me know if I need to provide this, also which state do I have to provide it.
- `pw-dump > pw-dump.log`:
- Bluetooth debug log, see [here](https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting#bluetooth):https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2245ladspa-sinks not working reliable since wireplumber 0.4.92022-03-27T11:16:10ZJan Sieber-Taegertladspa-sinks not working reliable since wireplumber 0.4.9<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version:
Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48
- Distribution and distribution version:
...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version:
Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48
- Distribution and distribution version:
Debian GNU/Linux 11 (bullseye)
- Desktop Environment:
GNOME 3.38.5
- Kernel version:
5.10.0-13-amd64
## Description of Problem:
For streaming to my home amp/raspberrypi I'm using a null-sink (connected with roc-send binary on its monitor) and airplay streaming with module-raop-sink/discover. Depending on the current wifi situation in our apartment building at times the one works better and at times the other. Each of these sinks is coupled with a ladspa-sink. Thus additionally I can choose more "compressed" audio output - e.g. for looking video late in the evening.
Since wireplumber 0.4.9 switching between these sinks is not working reliably any more: After switching around, the sound of the ladspa-sinks comes out of the onboard sound speaker.
Whereas the raop-/raop+ladspa-combination works fine as long there isn't any other ladspa-sink present (1.+2.), the null-/null+ladspa-combination failes as it is (3.).
## How Reproducible:
1.) Load raop-discover and link a ladspa-sink to the raop-sink once it has been established. Start audio input (e.g. firefox audio stream). Toggle default sink around.
2.) Additionally load null-sink and link a ladspa-sink to it. Start audio input. Toggle default sink around.
3.) Load null-sink and link a ladspa-sink to it. Start audio input. Toggle default sink around.
### Steps to Reproduce:
1.)
`pactl load-module module-raop-discover`
Wait 5 seconds until airplay sinks have been established... (sink_name = raop-sink-13 )
`pactl load-module module-ladspa-sink sink_name=raop-sink-13+sc4 master=raop-sink-13 plugin=/usr/lib/ladspa/sc4_1882.so label=sc4 control=0.5,20,500,-30,5,1,5`
`pactl set-default-sink raop-sink-13+sc4`
`pactl set-default-sink raop-sink-13`
`pactl set-default-sink raop-sink-13+sc4`
2.)
`pactl load-module module-raop-discover`
Waiting 5 seconds until airplay sinks have been established... (sink_name = raop-sink-13 )
`pactl load-module module-ladspa-sink sink_name=raop-sink-13+sc4 master=raop-sink-13 plugin=/usr/lib/ladspa/sc4_1882.so label=sc4 control=0.5,20,500,-30,5,1,5`
`pactl load-module module-null-sink sink_name=roc-send`
`pactl load-module module-ladspa-sink sink_name=roc-send+sc4 master=roc-send plugin=/usr/lib/ladspa/sc4_1882.so label=sc4 control=0.5,20,500,-30,5,1,5`
`pactl set-default-sink raop-sink-13+sc4`
`pactl set-default-sink raop-sink-13`
`pactl set-default-sink raop-sink-13+sc4`
`pactl set-default-sink roc-send`
`pactl set-default-sink raop-sink-13+sc4`
`pactl set-default-sink roc-send+sc4`
`pactl set-default-sink raop-sink-13+sc4`
3.)
`pactl load-module module-null-sink sink_name=roc-send`
`pactl load-module module-ladspa-sink sink_name=roc-send+sc4 master=roc-send plugin=/usr/lib/ladspa/sc4_1882.so label=sc4 control=0.5,20,500,-30,5,1,5`
`pactl set-default-sink roc-send+sc4`
`pactl set-default-sink roc-send`
`pactl set-default-sink roc-send+sc4`
### Actual Results:
Audio output comes out of the onboard sound speaker.
### Expected Results:
Audio is routed to the amp/raspberrypi.
# Additional Info (as attachments):
[pw-dump_raop-only.good](/uploads/ecca75b28f8d4b2684d3dda9ef39989b/pw-dump_raop-only.good)
[pw-dump_raop+null-sink.bad](/uploads/49e16ac30fa1e5fff20e385b4ca09ca3/pw-dump_raop+null-sink.bad)
[pw-dump_nullsink-only.bad](/uploads/05d02b91cfb5dae3a008b2634dcae894/pw-dump_nullsink-only.bad)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2244Please allow invocation by the superuser.2024-03-22T15:07:15Z`{third: "Beedell", first: "Roke"}`{.JSON5}hyqjfpci@rokejulianlockhart.addy.ioPlease allow invocation by the superuser.Many people utilize the superuser account (*commonly* named `root`) as their personal account, because for many, the potential advantages of utilizing *any* alternative user-account is nullified by the necessity of utilizing `sudo` or `s...Many people utilize the superuser account (*commonly* named `root`) as their personal account, because for many, the potential advantages of utilizing *any* alternative user-account is nullified by the necessity of utilizing `sudo` or `su` to elevate to the superuser's permission level when performing certain common actions: mounting filesystems, and managing packages (with `apt`, `zypper`, or `dnf`).
However, I believe that, as https://www.reddit.com/r/pipewire/comments/mibuu9/pipewire_as_root/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button demonstrates, the `ConditionUser=!root`, which https://gitlab.freedesktop.org/search?search=ConditionUser%3D!root&nav_source=navbar&project_id=4753&group_id=10138&search_code=true&repository_ref=4db081187815192e0b45a1d4d784369edab43019 contain, prevent this by default.
I am confident that this decision is erroneous, and that it consequently should be reconsidered.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2243Virtual Surround clipping2022-03-31T14:26:28ZAidan DangVirtual Surround clipping<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.48
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.48
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: i3
- Kernel version (`uname -r`): 5.16.16-zen1-1-zen
## Description of Problem:
I've set up virtual surround with the irc54 HRIR from HeSuVi as per the wiki entry. Without turning down the volume of the Virtual Surround Sink (e.g. through Pavucontrol), there are some sounds that will clip on my output device when they otherwise wouldn't without virtual surround. HeSuVi has a button to calculate the amount of attenuation needed to avoid this kind of clipping, so maybe the pipewire virtual surround should do something similar?
## How Reproducible:
Fully and deterministically.
### Steps to Reproduce:
1. Set up virtual surround with HeSuVi's irc54 HRIR according to the wiki.
2. Ensure the Virtual Surround Sink and output device are set to 0.00 dB (e.g. in Pavucontrol).
3. Play some classical guitar videos on YouTube and listen for clipping.
4. Fix by lowering the volume on the Virtual Surround Sink (to approximately the level suggested by HeSuVi).
### Actual Results:
Distortion due to clipping.
### Expected Results:
The virtual surround module should calculate and apply an automatic attenuation so that 0.00 dB on both the Virtual Surround Sink and output device should not result in clipping?https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2241pw_time documentation is less than helpful2022-04-22T17:24:22ZRemi Denis-Courmontpw_time documentation is less than helpfulI may be a moron but the documentation for `struct pw_time` does not seem very sensible or helpful.
* `now` is according to the the documentation "the monotonic time in nanoseconds". But it looks like it actually is the monotonic clock t...I may be a moron but the documentation for `struct pw_time` does not seem very sensible or helpful.
* `now` is according to the the documentation "the monotonic time in nanoseconds". But it looks like it actually is the monotonic clock timestamp at the time that rest of the time structure was last sampled. At least it seems consistently slightly behind the monotonic clock.
* `rate` is just "the rate" which is rather nondescript. Besides rates are typically measured in Hertz, but this seems to be the period time expressed in seconds. The documentation does not mention the unit either.
* `ticks` seems to be some kind of accumulated time of the stream? The documentation does not clarify how it is or is not affected by pauses, underruns/overruns though.
* `delay` seems intended to be the difference from the record/playback time of the other end to `ticks`. However for me it is a **positive** constant for raw audio playback streams, which makes no physical sense (and indeed contradicts the documentation).
* `queued` refers to an unspecified queue, and so far it is always zero for me.
I was hoping to get some equivalent to `snd_pcm_delay` or `pa_stream_get_time` and I'm at a complete loss here.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2239libpipewire-module-x11-bell causes pipewire crash when running without x2023-08-01T18:20:54ZJeremiah Ticketlibpipewire-module-x11-bell causes pipewire crash when running without xI use ratpoison wm. When using the libpipewire-module-x11-bell module without x, IE I have pipewire start before X starts so I can get console audio, pipewire crashes. Is there a way to make the module fail safely and not crash pipewire?...I use ratpoison wm. When using the libpipewire-module-x11-bell module without x, IE I have pipewire start before X starts so I can get console audio, pipewire crashes. Is there a way to make the module fail safely and not crash pipewire? Logs say it cannot find the display and then crashes. Maybe have it watch for SX and work then.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2238pw_deinit() is not reentrant2022-04-02T02:21:03ZRemi Denis-Courmontpw_deinit() is not reentrant`pw_init()` tries to support multiple users in a single process by skipping processing if the initialised flag is already set. But `pw_deinit()` frees everything on its first call.
Obviously this won't work if there are multiple indepen...`pw_init()` tries to support multiple users in a single process by skipping processing if the initialised flag is already set. But `pw_deinit()` frees everything on its first call.
Obviously this won't work if there are multiple independent components using the run-time library in the same process. In fact, it looks like calling it is not possible to recover from `pw_deinit()` at all, as it won't reset the initialised flag to false.
This leaves library code between a rock and a hard place. Don't call `pw_deinit()` and you'll leak resources. Do call it and everything breaks down.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2237pw_init() is not thread-safe2022-05-11T14:10:28ZRemi Denis-Courmontpw_init() is not thread-safe`pw_init()` calls `setlocale()` which is notoriously not thread-safe and will happily crash the process if another thread uses locale data or gettext simultaneously. (This was already a problem for LibVLC in 2008, I'd have thought people...`pw_init()` calls `setlocale()` which is notoriously not thread-safe and will happily crash the process if another thread uses locale data or gettext simultaneously. (This was already a problem for LibVLC in 2008, I'd have thought people would know better in 2022, but I digress.)
In an application that links with pipewire directly and calls `pw_init()` early, that might be fine. In library code in a multi-threaded application this is simply fatal. `pw_init()` cannot be called, and thus the entirety of libpipewire is ostensibly unusable.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2236pipewire-media-session seems to hang and crash on exit2022-03-24T17:47:12ZGino Badouripipewire-media-session seems to hang and crash on exit<!-- 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`): Fedora 36 ARM 32bit
- Desktop Environment: Gnome Shell 42 (wayland)
- Kernel version (`uname -r`): 5.8.18
## Description of Problem:
pipewire-media-session seems to hang and sefaults when trying to abort/exit.
## How Reproducible:
It's started using the pipewire-media-session user service
### Steps to Reproduce:
1.
2.
3.
### Actual Results:
Systemd logging:
```
Mar 24 10:48:39 odroidxu4 systemd[1319]: Started pipewire-media-session.service - PipeWire Media Session Manager.
Mar 24 10:48:39 odroidxu4 systemd[1319]: Started pipewire-pulse.service - PipeWire PulseAudio.
Mar 24 10:48:39 odroidxu4 rtkit-daemon[645]: Successfully made thread 1573 of process 1573 (/usr/bin/pipewire) owned by '1000' high priority at nice level -11.
Mar 24 10:48:39 odroidxu4 rtkit-daemon[645]: Successfully made thread 1575 of process 1575 (/usr/bin/pipewire-pulse) owned by '1000' high priority at nice level -11.
Mar 24 10:48:39 odroidxu4 rtkit-daemon[645]: Successfully made thread 1584 of process 1574 (/usr/bin/pipewire-media-session) owned by '1000' RT at priority 20.
Mar 24 10:48:40 odroidxu4 rtkit-daemon[645]: Successfully made thread 1587 of process 1575 (/usr/bin/pipewire-pulse) owned by '1000' RT at priority 20.
Mar 24 10:48:40 odroidxu4 rtkit-daemon[645]: Successfully made thread 1588 of process 1573 (/usr/bin/pipewire) owned by '1000' RT at priority 20.
Mar 24 10:48:40 odroidxu4 pipewire-pulse[1586]: 536870912
Mar 24 10:48:56 odroidxu4 systemd[908]: Stopping pipewire-pulse.service - PipeWire PulseAudio...
Mar 24 10:48:56 odroidxu4 systemd[908]: Stopped pipewire-pulse.service - PipeWire PulseAudio.
Mar 24 10:48:56 odroidxu4 systemd[908]: Stopping pipewire-media-session.service - PipeWire Media Session Manager...
Mar 24 10:48:56 odroidxu4 pipewire-media-session[982]: free(): invalid pointer
Mar 24 10:48:56 odroidxu4 systemd[1]: Started systemd-coredump@1-2160-0.service - Process Core Dump (PID 2160/UID 0).
Mar 24 10:48:57 odroidxu4 systemd-coredump[2162]: [🡕] Process 982 (pipewire-media-) of user 42 dumped core.
Module linux-vdso.so.1 with build-id b917e210f89ac1320d8a565ec90951dd124f1cad
Module libpipewire-module-session-manager.so with build-id 66a467e0f0ef6b4273679088c29d3f4e952438ae
ELF object binary architecture: ARM
Mar 24 10:48:57 odroidxu4 systemd[908]: pipewire-media-session.service: Main process exited, code=dumped, status=6/ABRT
Mar 24 10:48:57 odroidxu4 systemd[908]: pipewire-media-session.service: Failed with result 'core-dump'.
Mar 24 10:48:57 odroidxu4 systemd[908]: Stopped pipewire-media-session.service - PipeWire Media Session Manager.
Mar 24 10:48:57 odroidxu4 systemd[908]: Stopping pipewire.service - PipeWire Multimedia Service...
Mar 24 10:48:57 odroidxu4 systemd[1]: systemd-coredump@1-2160-0.service: Deactivated successfully.
Mar 24 10:48:57 odroidxu4 systemd[908]: Stopped pipewire.service - PipeWire Multimedia Service.
Mar 24 10:48:57 odroidxu4 systemd[908]: Closed pipewire-pulse.socket - PipeWire PulseAudio.
Mar 24 10:48:57 odroidxu4 systemd[908]: Closed pipewire.socket - PipeWire Multimedia System Socket.
```
Backtrace when running from gdb when pressing CTRL + C:
```
(gdb) bt full
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
tid = 3015
ret = 0
pd = <optimized out>
old_mask = {__val = {0, 0, 0, 3070226472, 0, 1, 3070225612, 30, 1, 0, 3070227860, 5484872, 1, 0, 3070225664, 3204443992, 3204444272, 3204444256, 3069993472, 0, 3070182816, 3204443796, 3067427360, 3204443752, 0, 3069993396,
5484872, 3069993396, 5021696, 3204443752, 3204443324, 1977111134}}
ret = <optimized out>
#1 0xb6c8f848 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
No locals.
#2 0xb6c47bec in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
ret = <optimized out>
#3 0xb6c31614 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x544a60, sa_sigaction = 0x544a60}, sa_mask = {__val = {3066696340, 5524016, 3204443752, 5367280, 3066684380, 1, 2214001664, 5590608, 3066685560, 3070182816, 2214001664, 5022920,
3066685560, 5092728, 2214001664, 1, 5367304, 5503696, 3066684380, 0, 5494320, 5506528, 2214001664, 3043184108, 3204443667, 3204443672, 3067427588, 0, 0, 0, 2214001664, 5499888}}, sa_flags = -2080965632,
sa_restorer = 0xb6ff45a0}
sigs = {__val = {32, 0 <repeats 15 times>, 3070182816, 2214001664, 3204443876, 2214001664, 0, 5355904, 3070182816, 2214001664, 42, 5524064, 3070182816, 11, 5524016, 5524064, 4, 0}}
#4 0xb6c82844 in __libc_message (action=action@entry=do_abort, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:155
ap = {__ap = 0xbeffee7c}
fd = <optimized out>
list = <optimized out>
nlist = <optimized out>
cp = <optimized out>
#5 0xb6c9c37c in malloc_printerr (str=<optimized out>) at malloc.c:5664
No locals.
#6 0xb6c9e6e8 in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>) at malloc.c:4439
size = <optimized out>
fb = <optimized out>
nextchunk = <optimized out>
nextsize = <optimized out>
nextinuse = <optimized out>
prevsize = <optimized out>
bck = 0x0
fwd = <optimized out>
__PRETTY_FUNCTION__ = "_int_free"
#7 0xb6ca1294 in __GI___libc_free (mem=0x4bea58) at malloc.c:3391
ar_ptr = <optimized out>
p = 0x4bea50
err = 11
#8 0xb6eeca08 in clear_item (item=0x4d2a68) at ../src/pipewire/properties.c:69
No locals.
#9 pw_properties_clear (properties=properties@entry=0x4c6d88) at ../src/pipewire/properties.c:287
impl = 0x4c6d88
item = 0x4d2a68
#10 0xb6eeca38 in pw_properties_free (properties=0x4c6d88) at ../src/pipewire/properties.c:376
impl = 0x4c6d88
impl = <optimized out>
#11 pw_properties_free (properties=0x4c6d88) at ../src/pipewire/properties.c:368
impl = <optimized out>
#12 0x0040bcf0 in session_destroy (data=0x4c5ce8) at ../src/bluez-monitor.c:695
impl = 0x4c5ce8
#13 0x00407514 in session_shutdown (impl=0xbeffef68) at ../src/media-session.c:2295
_f = <optimized out>
_res = true
_list = 0xbefff068
_s = 0xbefff068
_cursor = {link = {next = 0x4b983c, prev = 0xbefff070}, cb = {funcs = 0x0, data = 0x0}, removed = 0x0, priv = 0x0}
_ci = <optimized out>
_count = <optimized out>
obj = <optimized out>
re = <optimized out>
free_list = {next = 0xbeffef50, prev = 0xbeffef50}
obj = <optimized out>
re = <optimized out>
free_list = <optimized out>
__func__ = <optimized out>
_list = <optimized out>
_s = <optimized out>
_cursor = <optimized out>
_ci = <optimized out>
_count = <optimized out>
_f = <optimized out>
_res = <optimized out>
_list = <optimized out>
_s = <optimized out>
_cursor = <optimized out>
_ci = <optimized out>
_count = <optimized out>
_f = <optimized out>
_res = <optimized out>
#14 main (argc=<optimized out>, argv=<optimized out>) at ../src/media-session.c:2603
impl = {this = {session = 0x0, props = 0x467330, session_id = 0, client_session = 0x0, loop = 0x467b90, context = 0x468958, dbus_connection = 0x4886e8, metadata = 0x0, info = 0x583ca8}, config_dir = 0x43dfbc "media-session.d", conf = 0x467438, modules = 0x468078, loop = 0x467b78, dbus = 0x472744, dbus_connection_listener = {link = {next = 0x488710, prev = 0x488710}, cb = {funcs = 0x458f58 <dbus_connection_events>, data = 0xbeffef70}, removed = 0x0, priv = 0x0}, monitor_core = 0x488760, monitor_listener = {link = {next = 0x488794, prev = 0x4887bc}, cb = {funcs = 0x458f64 <monitor_core_events>, data = 0xbeffef70}, removed = 0x0, priv = 0x0}, monitor_seq = 1073742018, policy_core = 0x49b358, policy_listener = {link = {next = 0x49b38c, prev = 0x49b3b4}, cb = {funcs = 0x458f94 <policy_core_events>, data = 0xbeffef70}, removed = 0x0, priv = 0x0}, proxy_policy_listener = {link = {next = 0x49b384, prev = 0x49b3cc}, cb = {funcs = 0x458fb8 <proxy_core_events>, data = 0xbeffef70}, removed = 0x0, priv = 0x0}, registry = 0x4ade80, registry_listener = {link = {next = 0x4adeb4, prev = 0x4adeb4}, cb = {funcs = 0x458fd0 <registry_events>, data = 0xbeffef70}, removed = 0x0, priv = 0x0}, monitor_registry = 0x49b310, monitor_registry_listener = {link = {next = 0x49b344, prev = 0x49b344}, cb = {funcs = 0x458f88 <monitor_registry_events>, data = 0xbeffef70}, removed = 0x0, priv = 0x0}, globals = {items = {data = 0x553998, size = 332, alloc = 512, extend = 64}, free_list = 4294967295}, object_list = {next = 0xbefff060, prev = 0xbefff060}, registry_event_list = {next = 0xbefff068, prev = 0xbefff068}, hooks = {list = {next = 0xbeffef58, prev = 0x4bea1c}}, endpoint_link_list = {next = 0xbefff078, prev = 0xbefff078}, endpoint_links = {items = {data = 0x4885d8, size = 0, alloc = 256, extend = 64}, free_list = 4294967295}, link_list = {next = 0xbefff094, prev = 0xbefff094}, sync_list = {next = 0xbefff09c, prev = 0xbefff09c}, rescan_seq = 1073742717, last_seq = 1073742574, scanning = 0, rescan_pending = 0, seat_active = 1}
support = <optimized out>
str = <optimized out>
config_name = <optimized out>
do_show_help = <optimized out>
n_support = 10
res = 0
c = <optimized out>
i = <optimized out>
item = <optimized out>
level = <optimized out>
config_dir = <optimized out>
long_options = {{name = 0x444524 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x44452c "version", has_arg = 0, flag = 0x0, val = 86}, {name = 0x444534 "config", has_arg = 1, flag = 0x0, val = 99}, {name = 0x44453c "verbose", has_arg = 0, flag = 0x0, val = 118}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
__func__ = "main"
```
### Expected Results:
no crashes
# Additional Info (as attachments):
- pw-dump.log: [pw-dump.log](/uploads/9b3d3f593e64443a022199c4fa0ae8a6/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2235pipewire thinks my headphones is a capture device2022-03-27T13:57:31Zdriskey willowspipewire thinks my headphones is a capture deviceCompiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48
before plugging in headphones:
```
> pw-cli dump short Node
28: s="suspended" n="Dummy-Driver"
29: s="suspended" n="Freewheel-Driver"
42: s="suspended" i=2/64 n="alsa_outpu...Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48
before plugging in headphones:
```
> pw-cli dump short Node
28: s="suspended" n="Dummy-Driver"
29: s="suspended" n="Freewheel-Driver"
42: s="suspended" i=2/64 n="alsa_output.pci-0000_00_1f.3.analog-stereo" p="alsa:pcm:0:front:0:playback"
```
after plugging in headphones:
```
> pw-cli dump short Node
28: s="suspended" n="Dummy-Driver"
29: s="suspended" n="Freewheel-Driver"
40: s="suspended" o=2/64 n="alsa_input.pci-0000_00_1f.3.analog-stereo" p="alsa:pcm:0:front:0:capture"
42: s="suspended" i=2/64 n="alsa_output.pci-0000_00_1f.3.analog-stereo" p="alsa:pcm:0:front:0:playback"
```
headphones do not work. device continues playing through speakershttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2234Crackling sound in Satisfactory2023-09-28T19:58:20ZHaxk20Crackling sound in Satisfactory<!-- 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 (Latest git commit)
- Distribution and distribution version (`PRETTY_NAME` fr...<!-- 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 (Latest git commit)
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Gentoo
- Desktop Environment: GNOME
- Kernel version (`uname -r`): linux-next
## Description of Problem:
Satisfactory instead of nice music has a lot of crackling sounds. Attaching a video of the issue ![2022-03-22_01-44-02](/uploads/1c4a01958172e78abdbc9a6a1de28e4b/2022-03-22_01-44-02.mp4)
## How Reproducible:
100% of the time
### Steps to Reproduce:
1. Launch satisfactory with PipeWire
### Actual Results:
As can be seen in the video. Horrible crackling that gets FAR worse in actual gameplay. Unplayable.
### Expected Results:
As tested on pure PulseAudio. Clean sound with no crackling.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/4004341e519764b17fb1d6862bee1260/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2233monitors/alsa.lua contains unlocalized, UI visible strings2022-03-22T19:07:39ZP Vmonitors/alsa.lua contains unlocalized, UI visible stringsThe strings "Built-in Audio" and "Modem" appearing in alsa.lua are not localized. They go into node.description, which appears as-is in user interfaces, e.g. GNOME Settings. There may be also other unlocalized strings elsewhere, didn't c...The strings "Built-in Audio" and "Modem" appearing in alsa.lua are not localized. They go into node.description, which appears as-is in user interfaces, e.g. GNOME Settings. There may be also other unlocalized strings elsewhere, didn't check...
There probably should be some i18n system set up here, given that some strings in Wireplumber are user-visible.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2232impl-core 0x55a5b0990690: error -5 for resource 81: port_use_buffers error: I...2023-08-01T18:22:02ZMarc Debruyneimpl-core 0x55a5b0990690: error -5 for resource 81: port_use_buffers error: Input/output error<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
- De...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
- Desktop Environment:
- Kernel version (`uname -r`):5.15.23-gentoo-x86_64
## Description of Problem:playing flac's results sometimes in following error:
Mar 21 10:46:01 marc pipewire[262571]: impl-core 0x55a5b0990690: error -5 for resource 81: port_use_buffers error: Input/output error
Mar 21 10:46:01 marc pipewire[262571]: client-node 0x55a5b0bad4a0: error seq:45352 -5 (port_use_buffers error: Input/output error
## How Reproducible:change pipewire.conf
from: default.clock.allowed-rates = [ 48000 ]
to : default.clock.allowed-rates = [ 44100 48000 88200 96000 176400 192000 352800 ]
### Steps to Reproduce:
1. play different flac's
2.
3.
### Actual Results:
only one channel or none is heard
error:
Mar 21 10:46:01 marc pipewire[262571]: impl-core 0x55a5b0990690: error -5 for resource 81: port_use_buffers error: Input/output error
Mar 21 10:46:01 marc pipewire[262571]: client-node 0x55a5b0bad4a0: error seq:45352 -5 (port_use_buffers error: Input/output error
intermittent occurrence
### Expected Results:
both channels should be playing
no error should occur
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: