pipewire issueshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues2023-04-21T10:22:34Zhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3169crackling audio every 1-2 seconds2023-04-21T10:22:34ZFlorian Hänelcrackling audio every 1-2 seconds<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): libpipewire 0.3.58
- Distribution and distribution version (`PRETTY_NAME` from `/etc...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): libpipewire 0.3.58
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Ubuntu 22.10
- Desktop Environment: KDE plasma
- Kernel version (`uname -r`): 5.19.0-1022-lowlatency
## Description of Problem:
audio crackling every 2-3 seconds for few ms. it appears on SPDIF speakers but also bluetooth headphones.
I can record it using audacity on a monitor device and it looks like zero samples
this manifested one or two weeks ago
## How Reproducible:
first noticed on spotify, firefox. also on speaker-test -t sine -f 100 and pa-play
### Steps to Reproduce:
1. play any audio using any client
### Actual Results:
crackling
### Expected Results:
no crackling
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/31deab10947862d8131d3aa1a812fdbd/pw-dump.log)
PIPEWIRE_DEBUG=5 pw-play does not show xruns that coincide with the crackling
speaker-test crackles every time it prints Time per period = 10.989598 but also more than thathttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3168USB DAC disappearing after waking from sleep/suspend (fiio k3)2023-09-11T00:07:46ZAdis DurakovicUSB DAC disappearing after waking from sleep/suspend (fiio k3)When waking the PC from sleep, my USB DAC (FiiO K3) disappears, and only comes back when I re-plug it.
The problem does not affect the BT speaker or my onboard audio jack.
```
pipewire --version
pipewire
Compiled with libpipewire 0.3.6...When waking the PC from sleep, my USB DAC (FiiO K3) disappears, and only comes back when I re-plug it.
The problem does not affect the BT speaker or my onboard audio jack.
```
pipewire --version
pipewire
Compiled with libpipewire 0.3.69
Linked with libpipewire 0.3.69
Fedora 38
when it's connected: cat /proc/asound/modules
1 0 snd_usb_audio
2 1 snd_hda_intel
3 2 snd_usb_audio
4 3 snd_hda_intel
5 4 snd_usb_audio
6 5 snd_usb_audio
after wakeup: cat /proc/asound/modules
1 0 snd_usb_audio
2 1 snd_hda_intel
3 2 snd_usb_audio
4 3 snd_hda_intel
5 4 snd_usb_audio
```
If you need anything else, let me know.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3165Updating pipewire 0.3.68 to 0.3.69 broke bluetooth and crashes wireplumber an...2023-04-19T13:10:36ZDolf AndringaUpdating pipewire 0.3.68 to 0.3.69 broke bluetooth and crashes wireplumber and pipewire
- PipeWire version (`pipewire --version`): 0.3.69-1
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Fedora 37
- Desktop Environment: Gnome-shell
- Kernel version (`uname -r`): 6.2.10-200
## Description o...
- PipeWire version (`pipewire --version`): 0.3.69-1
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Fedora 37
- Desktop Environment: Gnome-shell
- Kernel version (`uname -r`): 6.2.10-200
## Description of Problem:
Gnome refuses to connect bluetooth devices and restart of Pipewire (wireplumber) crashes during restart with core dump after upgrade on fedora 37 from pipewire 0.3.68 to 0.3.69
After I did a `dnf downgrade pipewire` and restarted pipewire (no reboot needed) which downgrades to 0.3.59, the issue is gone and bluetooth connects again. I can't seem to easily downgrade to 0.3.68, since that version is no longer available. But yesterday (before I updated) everything worked just fine, so I think it is due to an issue with 0.3.69.
## How Reproducible:
Connect any a2dp bluetooth device.
`systemctl --user restart pipewire`
`systemctl --user restart pipewire-pulse.service`
### Steps to Reproduce:
1. `dnf update` on fedora 37
2. reboot
3. try to connect a bluetooth device (fails)
4. restart pipewire (crashes)
### Actual Results:
When trying to connect a bluetooth audio device:
```
Apr 18 10:25:35 dolfdesktop bluetoothd[33432]: src/service.c:btd_service_connect() a2dp-sink profile connect failed for xx:xx:xx:xx:xx:xx: Protocol not available
```
Restarting `pipewire` and `pipewire-pulse` crashes pipewire and all audio stops working (audio ui components even disappear from gnome).
```
Apr 18 10:42:44 dolfdesktop abrt-notification[55239]: [🡕] Process 2945 (wireplumber) crashed in _nl_load_domain.cold()
Subject: ABRT has detected unexpected termination: wireplumber
Defined-By: ABRT
Support: https://bugzilla.redhat.com/
Documentation: man:abrt(1)
wireplumber killed by SIGABRT
#1 [libc.so.6] _nl_load_domain.cold
#2 [libc.so.6] 81daba31ee66dbd63efdc4252a872949d874d136+218710
#3 [libasound.so.2] snd_mixer_elem_add
#4 [libspa-alsa.so] mixer_class_event
#5 [libasound.so.2] hctl_event_handler
Use the abrt command-line tool for further analysis or to report
the problem to the appropriate support site.
```
### Expected Results:
Bluetooth connection working.
# Additional Info (as attachments):
Additional crash info.
```
abrt-notification[55060]: [🡕] Process 2945 (wireplumber) crashed in _nl_load_domain.cold()
Subject: ABRT has detected unexpected termination: wireplumber
Defined-By: ABRT
Support: https://bugzilla.redhat.com/
Documentation: man:abrt(1)
wireplumber killed by SIGABRT
#1 [libc.so.6] _nl_load_domain.cold
#2 [libc.so.6] 81daba31ee66dbd63efdc4252a872949d874d136+218710
#3 [libasound.so.2] snd_mixer_elem_add
#4 [libspa-alsa.so] mixer_class_event
#5 [libasound.so.2] hctl_event_handler
Module libpcre2-8.so.0 with build-id 51cf2b0dc0884111cd6107b8b84bc1dc9e896de6
Metadata for module libpcre2-8.so.0 owned by FDO found: {
"type" : "rpm",
"name" : "pcre2",
"version" : "10.40-1.fc37.1",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Module libffi.so.8 with build-id 56594b436dfdeaf3559f3dd0748c0e476cca46de
Metadata for module libffi.so.8 owned by FDO found: {
"type" : "rpm",
"name" : "libffi",
"version" : "3.4.4-1.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Module libgio-2.0.so.0 with build-id 67b6e34538841cb4a37f2627dac7626ec451d721
Metadata for module libgio-2.0.so.0 owned by FDO found: {
"type" : "rpm",
"name" : "glib2",
"version" : "2.74.6-1.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Module libgmodule-2.0.so.0 with build-id ec8aa7c05708af8a1b0c56b828d88352a5c2bafc
Metadata for module libgmodule-2.0.so.0 owned by FDO found: {
"type" : "rpm",
"name" : "glib2",
"version" : "2.74.6-1.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Module libc.so.6 with build-id 81daba31ee66dbd63efdc4252a872949d874d136
Module libgcc_s.so.1 with build-id bad96a3adc0a3a006e7ef4900ff3ae1ddcc33ed2
Module libpipewire-0.3.so.0 with build-id f6dd038300adbf1c8cef3a1946be042c70fe03bd
Metadata for module libpipewire-0.3.so.0 owned by FDO found: {
"type" : "rpm",
"name" : "pipewire",
"version" : "0.3.69-1.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Module libglib-2.0.so.0 with build-id eac9203e396de94741ad9651644497c245a83ae8
Metadata for module libglib-2.0.so.0 owned by FDO found: {
"type" : "rpm",
"name" : "glib2",
"version" : "2.74.6-1.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Module libgobject-2.0.so.0 with build-id dca95a679cf6bb8d7e3a9a2e239aa50b95026ceb
Metadata for module libgobject-2.0.so.0 owned by FDO found: {
"type" : "rpm",
"name" : "glib2",
"version" : "2.74.6-1.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Module libwireplumber-0.4.so.0 with build-id 96a2e6ae07de51ddada1f3fc1a634c1595d13fca
Metadata for module libwireplumber-0.4.so.0 owned by FDO found: {
"type" : "rpm",
"name" : "wireplumber",
"version" : "0.4.14-1.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Module wireplumber with build-id e710ebce923a74d6648e2a0990372e84e2af52fe
Metadata for module wireplumber owned by FDO found: {
"type" : "rpm",
"name" : "wireplumber",
"version" : "0.4.14-1.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Stack trace of thread 54924:
#0 0x00007f70ce6c6e5c __pthread_kill_implementation (libc.so.6 + 0x8ce5c)
#1 0x00007f70ce676a76 raise (libc.so.6 + 0x3ca76)
#2 0x00007f70ce6607fc abort (libc.so.6 + 0x267fc)
#3 0x00007f70ce66071b __assert_fail_base.cold (libc.so.6 + 0x2671b)
#4 0x00007f70ce66f656 __assert_fail (libc.so.6 + 0x35656)
#5 0x00007f70be59d1f3 snd_mixer_elem_add (libasound.so.2 + 0x741f3)
#6 0x00007f70be6a8851 mixer_class_event (libspa-alsa.so + 0x6f851)
#7 0x00007f70be58eeee hctl_event_handler (libasound.so.2 + 0x65eee)
#8 0x00007f70be59121d snd_hctl_load (libasound.so.2 + 0x6821d)
#9 0x00007f70be59d541 snd_mixer_load (libasound.so.2 + 0x74541)
#10 0x00007f70be6a8a90 pa_alsa_open_mixer_by_name (libspa-alsa.so + 0x6fa90)
#11 0x00007f70be6b5883 pa_alsa_open_mixer_for_pcm.constprop.0 (libspa-alsa.so + 0x7c883)
#12 0x00007f70be6b103e mapping_paths_probe.constprop.0 (libspa-alsa.so + 0x7803e)
#13 0x00007f70be6a32d4 pa_alsa_profile_set_probe (libspa-alsa.so + 0x6a2d4)
#14 0x00007f70be690d57 acp_card_new (libspa-alsa.so + 0x57d57)
#15 0x00007f70be667b9a impl_init.lto_priv.1 (libspa-alsa.so + 0x2eb9a)
#16 0x00007f70ce8ad0da load_spa_handle.lto_priv.0 (libpipewire-0.3.so.0 + 0x760da)
#17 0x00007f70ce8ad444 pw_load_spa_handle (libpipewire-0.3.so.0 + 0x76444)
#18 0x00007f70ce87f94c pw_context_load_spa_handle (libpipewire-0.3.so.0 + 0x4894c)
#19 0x00007f70ceae2508 wp_spa_device_new_from_spa_factory (libwireplumber-0.4.so.0 + 0x2a508)
#20 0x00007f70bf8b6867 spa_device_new (libwireplumber-module-lua-scripting.so + 0x15867)
#21 0x00007f70bf84d672 luaD_precall (liblua-5.4.so + 0x1a672)
#22 0x00007f70bf85fdf7 luaV_execute (liblua-5.4.so + 0x2cdf7)
#23 0x00007f70bf845a26 f_call (liblua-5.4.so + 0x12a26)
#24 0x00007f70bf849f13 luaD_rawrunprotected (liblua-5.4.so + 0x16f13)
#25 0x00007f70bf84b694 luaD_pcall (liblua-5.4.so + 0x18694)
#26 0x00007f70bf845af0 lua_pcallk (liblua-5.4.so + 0x12af0)
#27 0x00007f70bf8bc8e8 _wplua_pcall (libwireplumber-module-lua-scripting.so + 0x1b8e8)
#28 0x00007f70bf8bca1a _wplua_closure_marshal (libwireplumber-module-lua-scripting.so + 0x1ba1a)
#29 0x00007f70cea6c060 g_closure_invoke (libgobject-2.0.so.0 + 0x14060)
#30 0x00007f70cea98f66 signal_emit_unlocked_R.isra.0 (libgobject-2.0.so.0 + 0x40f66)
#31 0x00007f70cea894da g_signal_emit_valist (libgobject-2.0.so.0 + 0x314da)
#32 0x00007f70cea896f3 g_signal_emit (libgobject-2.0.so.0 + 0x316f3)
#33 0x00007f70cea76b04 g_object_dispatch_properties_changed.lto_priv.0 (libgobject-2.0.so.0 + 0x1eb04)
#34 0x00007f70cea7cf7f g_object_notify (libgobject-2.0.so.0 + 0x24f7f)
#35 0x00007f70bf88c3b3 on_acquire_transition_done (libwireplumber-module-reserve-device.so + 0x93b3)
#36 0x00007f70cea6c060 g_closure_invoke (libgobject-2.0.so.0 + 0x14060)
#37 0x00007f70ceafe4f8 wp_transition_return (libwireplumber-0.4.so.0 + 0x464f8)
#38 0x00007f70ceb07efb wp_transition_advance (libwireplumber-0.4.so.0 + 0x4fefb)
#39 0x00007f70bf88ba6c on_name_acquired (libwireplumber-module-reserve-device.so + 0x8a6c)
#40 0x00007f70ce568884 do_call.lto_priv.0 (libgio-2.0.so.0 + 0x107884)
#41 0x00007f70ce568aa8 on_name_lost_or_acquired (libgio-2.0.so.0 + 0x107aa8)
#42 0x00007f70ce55f55f emit_signal_instance_in_idle_cb (libgio-2.0.so.0 + 0xfe55f)
#43 0x00007f70ce96cc72 g_idle_dispatch (libglib-2.0.so.0 + 0x55c72)
#44 0x00007f70ce96dc7f g_main_context_dispatch (libglib-2.0.so.0 + 0x56c7f)
#45 0x00007f70ce9c4118 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xad118)
#46 0x00007f70ce96d24f g_main_loop_run (libglib-2.0.so.0 + 0x5624f)
#47 0x0000565079aead0c main (wireplumber + 0x2d0c)
#48 0x00007f70ce661510 __libc_start_call_main (libc.so.6 + 0x27510)
#49 0x00007f70ce6615c9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x275c9)
#50 0x0000565079aeafe5 _start (wireplumber + 0x2fe5)
Stack trace of thread 54927:
#0 0x00007f70ce746196 epoll_wait (libc.so.6 + 0x10c196)
#1 0x00007f70ceb53e48 impl_pollfd_wait (libspa-support.so + 0x17e48)
#2 0x00007f70ceb446db loop_iterate (libspa-support.so + 0x86db)
#3 0x00007f70ce87ea87 do_loop (libpipewire-0.3.so.0 + 0x47a87)
#4 0x00007f70ce6c512d start_thread (libc.so.6 + 0x8b12d)
#5 0x00007f70ce745d74 __clone (libc.so.6 + 0x10bd74)
Stack trace of thread 54931:
#0 0x00007f70ce73e92d syscall (libc.so.6 + 0x10492d)
#1 0x00007f70ce9bfde0 g_cond_wait_until (libglib-2.0.so.0 + 0xa8de0)
#2 0x00007f70ce93d451 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x26451)
#3 0x00007f70ce99cb0a g_thread_pool_thread_proxy.lto_priv.0 (libglib-2.0.so.0 + 0x85b0a)
#4 0x00007f70ce997982 g_thread_proxy (libglib-2.0.so.0 + 0x80982)
#5 0x00007f70ce6c512d start_thread (libc.so.6 + 0x8b12d)
#6 0x00007f70ce745d74 __clone (libc.so.6 + 0x10bd74)
Stack trace of thread 54930:
#0 0x00007f70ce73921f __poll (libc.so.6 + 0xff21f)
#1 0x00007f70ce9c408d g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xad08d)
#2 0x00007f70ce96af00 g_main_context_iteration (libglib-2.0.so.0 + 0x53f00)
#3 0x00007f70ce96cb91 glib_worker_main (libglib-2.0.so.0 + 0x55b91)
#4 0x00007f70ce997982 g_thread_proxy (libglib-2.0.so.0 + 0x80982)
#5 0x00007f70ce6c512d start_thread (libc.so.6 + 0x8b12d)
#6 0x00007f70ce745d74 __clone (libc.so.6 + 0x10bd74)
Stack trace of thread 54932:
#0 0x00007f70ce73921f __poll (libc.so.6 + 0xff21f)
#1 0x00007f70ce9c408d g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xad08d)
#2 0x00007f70ce96d24f g_main_loop_run (libglib-2.0.so.0 + 0x5624f)
#3 0x00007f70ce571eca gdbus_shared_thread_func.lto_priv.0 (libgio-2.0.so.0 + 0x110eca)
#4 0x00007f70ce997982 g_thread_proxy (libglib-2.0.so.0 + 0x80982)
#5 0x00007f70ce6c512d start_thread (libc.so.6 + 0x8b12d)
#6 0x00007f70ce745d74 __clone (libc.so.6 + 0x10bd74)
ELF object binary architecture: AMD x86-64
Subject: Process 54924 (wireplumber) dumped core
Defined-By: systemd
Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Documentation: man:core(5)
Process 54924 (wireplumber) crashed and dumped core.
This usually indicates a programming error in the crashing program and
should be reported to its vendor as a bug.
```
pw-dump:[pwdump.log](/uploads/d3e1010e2a5d3bd082014105e89a3508/pwdump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3162USB DAC hifi said connected but there is sound2023-04-15T08:01:38ZJohan de SandeUSB DAC hifi said connected but there is soundUsing kubuntu 22.04 /2 pipewire is working but on mine yamaha hifi it said not connected but there is sound. ![IMG_20230415_095257_134](/uploads/8bad104e614369ec8932a03082183cdd/IMG_20230415_095257_134.jpg)This happened by an upgrade of ...Using kubuntu 22.04 /2 pipewire is working but on mine yamaha hifi it said not connected but there is sound. ![IMG_20230415_095257_134](/uploads/8bad104e614369ec8932a03082183cdd/IMG_20230415_095257_134.jpg)This happened by an upgrade of pipewire in November and the next after didn't change anything. Thats why i am asking it if this is an issue or do i need change some settings? Maybe it is an idea if there is an config tool.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3158Incorrect output selection on Raspberry Pi 4/4002023-04-14T08:10:09ZDave JonesIncorrect output selection on Raspberry Pi 4/400While testing the Ubuntu desktop images for Raspberry Pi which now use pipewire, I ran into a couple of odd default audio selections: [LP: #1993316](https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1993316), [LP: #1993347](https:/...While testing the Ubuntu desktop images for Raspberry Pi which now use pipewire, I ran into a couple of odd default audio selections: [LP: #1993316](https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1993316), [LP: #1993347](https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1993347).
On the Raspberry Pi 4 it's a mild annoyance: the audio jack is selected as the default output rather than the HDMI audio. However, on the Pi 400 (the keyboard-based model) it's a bit more serious as the audio jack doesn't exist on that board so the stack is selecting a non-existent output.
I'm unfortunately not yet familiar with the pipewire stack, but I'll try and add some more useful details once the madness of the release has calmed down!https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3157[Gamescope] Streaming crashes steam when gamescope is used2023-04-13T14:20:10ZMatthew Anderson[Gamescope] Streaming crashes steam when gamescope is usedThere have been multiple reports that after 0.3.59 of pipewire streaming broke on ChimeraOS and I'm just now starting to get around to look into it. I got a journal log showing the crash event.
[Stream-crash.log](/uploads/5404b861ac64dd5...There have been multiple reports that after 0.3.59 of pipewire streaming broke on ChimeraOS and I'm just now starting to get around to look into it. I got a journal log showing the crash event.
[Stream-crash.log](/uploads/5404b861ac64dd5d326166cad7735008/Stream-crash.log)
I am still investigating the issue and need to sort out some compilation issues to be able to confirm on my end that 0.3.59 was indeed the last working version. I do know for certain that streaming did work at one point so it's a regression.
Here are my current notes:
- Streaming from ChimeraOS to Steam Link works
- Streaming from Chimeraos to ChimeraOS crashes
- Streaming from ChimeraOS to SteamOS (Steam Deck) crashes ( I haven't confirmed this yet myself)
It seems Valve might think the issues is with pipewire and not gamescope itself.
https://github.com/ValveSoftware/gamescope/issues/775#issuecomment-1500715234https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3156AirPlay: No Audio2024-02-26T18:08:53ZerebionAirPlay: No Audio<!-- 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.65
Linked with libpipewire 0.3.65
```
-...<!-- 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.65
Linked with libpipewire 0.3.65
```
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): `Debian GNU/Linux 12 (bookworm)`
- Desktop Environment: MATE
- Kernel version (`uname -r`): `6.1.0-7-amd64`
## Description of Problem:
Using `module-raop-discover`, I get sinks for AirPlay devices, but cannot play audio.
## How Reproducible:
Install the module, load it, try to play audio. No audio.
### Steps to Reproduce:
1. Install the module
2. Load it
3. Try to play audio
4. no audio
### Actual Results:
No Audio
### Expected Results:
Audio
# Additional Info (as attachments):
`PIPEWIRE_DEBUG=3 pw-cli -m load-module libpipewire-module-raop-discover`
Output:
```
[I][03475.660855] mod.raop-sink | [module-raop-sink: 853 rtsp_setup_reply()] reply 200
[I][03475.660889] mod.raop-sink | [module-raop-sink: 889 rtsp_setup_reply()] server port:6000
[I][03475.660907] mod.raop-sink | [module-raop-sink: 905 rtsp_setup_reply()] control:6001 timing:6002
[I][03475.660949] mod.raop-sink | [module-raop-sink: 641 connect_socket()] Connected to host:169.254.208.79 port:6000
[I][03475.660969] mod.raop-sink | [module-raop-sink: 641 connect_socket()] Connected to host:169.254.208.79 port:6001
[I][03475.660987] mod.raop-sink | [module-raop-sink: 641 connect_socket()] Connected to host:169.254.208.79 port:6002
[I][03475.661047] default | [ rtsp-client.c: 426 flush_output()] sent: RECORD rtsp://192.168.178.37/569144142 RTSP/1.0
CSeq: 4
Client-Instance: 55b42417500d93ff
User-Agent: iTunes/11.0.4 (Windows; N)
Session: 1
Range: npt=0-
RTP-Info: seq=57071;rtptime=1402560660
[I][03475.677499] default | [ rtsp-client.c: 263 process_status()] status: RTSP/1.0 453 Not Enough Bandwidth
[I][03475.677665] default | [ rtsp-client.c: 337 process_header()] Server: AirTunes/105.1
[I][03475.677689] default | [ rtsp-client.c: 337 process_header()] CSeq: 3
[I][03475.677706] default | [ rtsp-client.c: 296 dispatch_handler()] received reply to request with cseq:3
[I][03475.677722] mod.raop-sink | [module-raop-sink: 853 rtsp_setup_reply()] reply 453
[E][03475.677737] mod.raop-sink | [module-raop-sink: 856 rtsp_setup_reply()] missing Session header
[I][03475.742735] default | [ rtsp-client.c: 263 process_status()] status: RTSP/1.0 200 OK
[I][03475.742897] default | [ rtsp-client.c: 337 process_header()] Audio-Latency: 15409
[I][03475.742924] default | [ rtsp-client.c: 337 process_header()] Server: AirTunes/105.1
[I][03475.742942] default | [ rtsp-client.c: 337 process_header()] CSeq: 4
[I][03475.742961] default | [ rtsp-client.c: 296 dispatch_handler()] received reply to request with cseq:4
[I][03475.742981] mod.raop-sink | [module-raop-sink: 765 rtsp_record_reply()] reply 200
[I][03475.743194] default | [ rtsp-client.c: 426 flush_output()] sent: SET_PARAMETER rtsp://192.168.178.37/569144142 RTSP/1.0
CSeq: 5
Content-Type: text/parameters
Content-Length: 17
progress: 0/0/0
```
- `pw-dump > pw-dump.log`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3155pipewire not working with Falkon, Firefox or mpv2023-04-14T20:17:20ZGhost Userpipewire not working with Falkon, Firefox or mpvWith pipewire running (i'm on Artix linux, s6 init env, LXQT desktop env, using pipewire, pipewire-pulse & wireplumber, just upgraded to 1:0.3.68 from 1:0.3.67, and still exactly the same problems) mpv starts every stream at current posi...With pipewire running (i'm on Artix linux, s6 init env, LXQT desktop env, using pipewire, pipewire-pulse & wireplumber, just upgraded to 1:0.3.68 from 1:0.3.67, and still exactly the same problems) mpv starts every stream at current position -106:45:06 (therefore, can't usefully seek in stream) and audio of videos play (in Falkon... not at all in Firefox) but the video and timecounter don't advance. This is a showstopper for me. I was happy to not run pipewire at all (just using alsa) and everything worked fine, except alsa doesn't allow me to use my new audio interface (without tweaking the alsa config, which i haven't tried).https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3149Gstreamer pipewiresrc element produces non-monotonously timestamped buffers w...2023-04-20T11:28:48ZMarkus EbnerGstreamer pipewiresrc element produces non-monotonously timestamped buffers with keepalive- PipeWire version (`pipewire --version`):
Compiled with libpipewire 0.3.67
Linked with libpipewire 0.3.67
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
openSUSE Tumbleweed
- Desktop Environment:
...- PipeWire version (`pipewire --version`):
Compiled with libpipewire 0.3.67
Linked with libpipewire 0.3.67
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
openSUSE Tumbleweed
- Desktop Environment:
KDE 5.27.4
- Kernel version (`uname -r`):
6.2.9-1-default
## Description of Problem:
I am using `pipewiresrc` with a dynamic-framerate source (screencapture of an application window).
At least with kwin_wayland as window-manager and Firefox as captured window, `pipewiresrc` only receives a new frame whenever something changed (e.g. mouse cursor moved over the captured window, or content of the window changed) - thus the variable framerate.
The caps here are: `video/x-raw,framerate=0/1,max-framerate=25/1`
Because of this, the entire pipeline could potentially go to sleep for hours when nothing changes.
The `keepalive-time` option in `pipewiresrc` avoids that problem by sending the last buffer **with a new timestamp** on a regular/timeout basis.
However, the dts/pts timestamps of the buffers that were emitted due to the keepalive timeout seem to have a totally different clock and reference time than the ones comming from pipewire/kwin.
This makes the timestamps in the pipeline non-monotonous and drives many elements in the GStreamer pipeline absolute bonkers.
### Steps to Reproduce:
By whatever means (I wrote a small application), start a screencast for an application window and insert the first stream's nodeId into the following pipeline:
```
GST_DEBUG="3,pipewiresrc:8" gst-launch-1.0 pipewiresrc do-timestamp=true keepalive-time=500 path=<%NODE_ID%> client-name=<%APPLICATION_NAME%> ! videoconvert ! autovideosink
```
### Actual Results:
Here is an excerpt of the produced log.
Buffers that originated from a new incomming buffer from pipewire/kwin all have a timestamp of `0:00:00.000000000`:
```
0:00:16.327006168 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1177:gst_pipewire_src_create:<pipewiresrc0> popped buffer 0x7f224c02bee0
0:00:16.327010458 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:480:buffer_recycle:<pipewiresrc0> recycle buffer 0x7f2240008ab0
0:00:16.327016228 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1222:gst_pipewire_src_create:<pipewiresrc0> pts 16313538000, dts 16313538000, base-time 8:07:02.500927324 -> 0:00:00.000000000, 0:00:00.000000000
0:00:16.327031528 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1177:gst_pipewire_src_create:<pipewiresrc0> popped buffer (nil)
0:00:16.343645445 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:568:dequeue_buffer:<pipewiresrc0> got new buffer 0x7f2240004b70
0:00:16.343651475 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:578:dequeue_buffer:<pipewiresrc0> pts 16330218000, dts_offset 0
0:00:16.343656735 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1177:gst_pipewire_src_create:<pipewiresrc0> popped buffer 0x7f224c0050c0
0:00:16.343659915 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:480:buffer_recycle:<pipewiresrc0> recycle buffer 0x7f2240008ed0
0:00:16.343665115 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1222:gst_pipewire_src_create:<pipewiresrc0> pts 16330218000, dts 16330218000, base-time 8:07:02.500927324 -> 0:00:00.000000000, 0:00:00.000000000
```
whereas buffers coming from a cloned last buffer due to the keepalive timeout triggering have an actually working monotonously increasing clock, equal to the pipeline's `running_time`:
```
0:00:18.170920108 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1177:gst_pipewire_src_create:<pipewiresrc0> popped buffer (nil)
0:00:18.670998960 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1172:gst_pipewire_src_create:<pipewiresrc0> timeout, send keepalive buffer
0:00:18.671029180 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1222:gst_pipewire_src_create:<pipewiresrc0> pts 18119571430, dts 18119571430, base-time 8:07:02.500927324 -> 0:00:18.650208762, 0:00:18.650208762
0:00:18.700762726 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1177:gst_pipewire_src_create:<pipewiresrc0> popped buffer (nil)
0:00:19.200853848 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1172:gst_pipewire_src_create:<pipewiresrc0> timeout, send keepalive buffer
0:00:19.200881898 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1222:gst_pipewire_src_create:<pipewiresrc0> pts 18650208762, dts 18650208762, base-time 8:07:02.500927324 -> 0:00:19.180062900, 0:00:19.180062900
```
Here is the entire log (probably not much of additional value): [timestamps.log](/uploads/a1bbc503127c13572eae11c4176d4765/timestamps.log)
### Expected Results:
No matter whether the frame was a copy of `last_buffer` sent out due to the keepalive timeout triggering, or whether it was a fresh one from pipewire/kwin, the timestamps should be monotonous. And since this is a live pipeline, they should be the pipeline's `running_time`.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3143Motu M4 - USB-sound-card (dis)connection issues, missing profiles and applica...2023-06-26T08:15:10ZXander BaatzMotu M4 - USB-sound-card (dis)connection issues, missing profiles and application hangs/freezes
- PipeWire version (`pipewire --version`): 0.3.67
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Nobara Linux 37 (Thirty Seven)
- Desktop Environment: GNOME 43.2
- Kernel version (`uname -r`): 6.2.8-200...
- PipeWire version (`pipewire --version`): 0.3.67
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Nobara Linux 37 (Thirty Seven)
- Desktop Environment: GNOME 43.2
- Kernel version (`uname -r`): 6.2.8-200.fsync.fc37.x86_64
## Description of Problem:
I've had the Motu M4 for about 6 months, and it has always been like this.
What I've tried:
- Using my old USB audio interface (Audient iD4), which works without any problems.
- Using other systems, a laptop and a desktop, both running Fedora (36 or 37). Motu M4 would still not function properly.
- Using another USB cable (e.g. USB-C to USB-C and USB-C to USB-A), using other USB ports (both 3.x and 2.0).
- Switching from wireplumber to pipewire-media-session, changes nothing.
- Following the advice on https://github.com/kiosion/alsa-motu-m2, I've tried to downgrade kernel and alsa packages to no avail.
- Adding my user to the audio group. Doesn't fix the issue.
- Locking the sample-rate and buffer size (among other things) through wireplumber's and PipeWire's configs. No difference.
- Using boot quirks for snd-usb-audio under `/etc/modprobe.d/`. Still no difference.
- Updating the firmware using Motu's official firmware updater on a Windows machine. Still did not change anything.
Upon a shutdown/reboot of my computer I have to power-cycle the interface (physically) for it to enter a working state, however there may be an excessive amount of xruns (sometimes in the thousands).
I'm using GNOME 43.2, and in audio settings it either says `Dummy Output/Input` or just completely greyed out.
Applications that are trying to utilize the audio server in this state may crash (such as Firefox, e.g. when playing a YouTube video, where even the video won't play).
When in this state only the `Off` and `Pro Audio` profile is available for the M4 in pavucontrol under the Configuration tab.
Above mentioned state happens after a computer boot-up before having turned off and on the M4 USB Interface. During this state the interface appears fully working when looking at the meters.
The audio interface would stop working at random times, usually as a result of changes in the audio server while doing tasks such as gaming and audio editing.
A program like Ardour will hang when closing the application, where I have to kill the process for it to close OR power-cycle my interface, where Ardour closes normally as soon as the interface is turned off.
The same thing will happen when trying to restart the pipewire service, it'll then hang until the interface is power-cycled, just like Ardour.
Upon boots, in its non-working state, I have to wait around 20-30 seconds before the computer will register my mouse and keyboard inputs, which halts my ability to log in that time. Physically turning off the interface fixes the issue, "unlocking" mouse and keyboard again.
In its working state there are more profiles available, like `HiFi` and `Direct`. Hi-Fi is the one I prefer, as the others seem to put me into the non-working state.
Changing sample-rate may put the M4 into the non-working state. From my limited testing and experimenting, I've found that it's most stable at 48000 Hz (the default for M4 on Windows is 48000 Hz at a 256 buffer size).
Alsa is always able to detect the interface, no matter if it's in the working state or not. However `aplay -l` will say `Subdevices: 1/1` in the non-working state and `Subdevices: 0/1` in the working state.
Below I've attached text files with outputs from:
- `aplay -lL`
- `pactl list cards`
- `pactl list sinks`
- `sudo fuser -v /dev/snd/*`
- `systemctl --user status pipewire pipewire-media-session pipewire-pulse wireplumber`
- `pw-dump`
in both the working and not-working state.
Similar issue from other people (links):
- https://github.com/kiosion/alsa-motu-m2/issues/3
- https://linuxmusicians.com/viewtopic.php?t=20936&start=30
## How Reproducible:
...
### Steps to Reproduce:
Below I've listed different methods on how to reproduce the issue, putting the interface into the non-working state:
- Booting, rebooting, and logging out.
- Switching audio profiles (e.g. through pavucontrol).
- Throwing many different audio-dependent applications at it simultaneously, like Ardour, Firefox, EasyEffects, video games, Discord.
### Actual Results:
Motu M4 is in a limited state on boots and reboots, additionally it can cause applications to hang at random times.
### Expected Results:
The Motu M4 working as expected, able to utilize all profiles and handle a diverse range of audio tasks without crashing/hanging applications that use it.
# Additional Info (as attachments):
Not-working state:
- [alsa-info-not-working](/uploads/bac0f27dc86f299732c6e1106ab6e561/alsa-info-not-working)
- [aplay-lL-not-working](/uploads/08820e54ccc33a1bb86800b6b2fba38f/aplay-lL-not-working)
- [pactl-list-cards-not-working](/uploads/8ec6b356556e21787519d5a871b3b9c1/pactl-list-cards-not-working)
- [pactl-list-sinks-not-working](/uploads/5596b4d918582df58f86d87c4390a103/pactl-list-sinks-not-working)
- [pw-dump-not-working.log](/uploads/4405a4d51e1ef2aa296e4e1042cf2d67/pw-dump-not-working.log)
- [sudo-fuser-v-not-working](/uploads/d691a4d09aef4dc6f55b4125ff698cc5/sudo-fuser-v-not-working)
- [systemctl-user-status-not-working](/uploads/841f99458a82545bf2e7d3efdc36f9b6/systemctl-user-status-not-working)
Working state:
- [aplay-lL](/uploads/29eaba361e26f04babf97949ca10d0f8/aplay-lL)
- [pactl-list-cards](/uploads/f00c1daa8d54454042781f42aa698a3f/pactl-list-cards)
- [pactl-list-sinks](/uploads/8bc46f7fdb69817905081883a0d853aa/pactl-list-sinks)
- [pw-dump.log](/uploads/e033323c8dbd21a689312ee9dcdf0be0/pw-dump.log)
- [sudo-fuser-v](/uploads/1adee780116870575fb88cefaa943da9/sudo-fuser-v)
- [systemctl-user-status](/uploads/73e7eb871edcf61a79265fc3dc1941ea/systemctl-user-status)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3141Support Antlion ModMic Wireless aptx-ll2023-04-19T16:01:28ZMassimo BSupport Antlion ModMic Wireless aptx-llFirst discussed here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/972#note_1031490
https://antlionaudio.com/collections/microphones/products/modmic-wireless
**Background:**
This device is special. Even though adding suppo...First discussed here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/972#note_1031490
https://antlionaudio.com/collections/microphones/products/modmic-wireless
**Background:**
This device is special. Even though adding support for just a single rare device could be some effort not worth the few users, BUT: This device is so special, there are no alternative devices on the market. I was long time looking for a high quality wireless mic. I also use the USB wired version in some setups, great voice quality.
I was thinking about purchasing the Avantree devices from the other thread, their aptx-LL should be a great improvement for the microphone back channel. But as with the wired modmic, this ModMic wireless makes it possible to use whatever headphone, combined with the best microphone performance.
Finally it would be great to run both, the headphone and the ModMic with the same internal BT receiver. Yes, and the BT mouse. Could saturate the max bandwidth, not sure. Some people already had issues when running a LDAC headphone together with a mouse...
I purchased one and like to help adding support for it.
Using the dedicated USB receiver it already works great, just another USB audio device. But on the laptop I would like to avoid the additional receiver and use the internal one which supports BT 5.2
As according to their [FAQ](https://antlionaudio.com/pages/faq) it should be able to connect the ModMic with any aptx-LL receiver, I did not succeed with any receiver yet, probably just not supported using some A2DP profile with a microphone-only, just guessing.
Currently I'm not able to pair at all. Holding the button for 5 secs it gets to pairing mode, possible to pair with its receiver, but not visible from the blueman-manager. Maybe it's unnamed. I see some unnamed Hifi device, but can't pair.
We could get some support from the manufacturer if pipewire dev is interested to implement.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3140No sound after computer boot with orca screenreader enabled2023-06-23T10:58:50ZMichał ZeganNo sound after computer boot with orca screenreader enabledI am using fedora 37 with pipewire 0.3.67, although the bug was present before.
I am using a laptop with intel core i7 12700h, and a nvme disk which causes it to boot faster, on my previous hardware which was core i5 and a hdd disk this ...I am using fedora 37 with pipewire 0.3.67, although the bug was present before.
I am using a laptop with intel core i7 12700h, and a nvme disk which causes it to boot faster, on my previous hardware which was core i5 and a hdd disk this never happened. I am also using wireplumber which might make a difference, however I don't think it is a session manager side bug, previously was using the media session.
Generally i am a screenreader user so have orca enabled on login screen and on the user account. Normally, when I enable orca after everything boots, it works properly. However, if I instead have it autostart, then usually i get no sound.
Sometimes, rarely, I get sound on login screen, and that is quite random, which makes me think it's a kind of race condition between pipewire and orca using it, or speech-dispatcher. I have many apps set to autostart after login and I never got orca talking after login when autostarted.
The sound returns after sound card is suspended. As in, the fairly recent changes that make pipewire suspend devices on idle make it work, because when I wait long enough for the suspend to happen, then orca suddenly starts talking. Of course before that actually started to happen, I had to disable orca, wait some time, then enable orca (no other sound producing apps are on at this moment).
I also know someone who said that plugging in an usb sound card and then disconnecting it, so making the sound switch to usb and back again, also makes it work.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3138HyperX DuoCast: The decibel volume range for element 'PCM' (-4000 dB - -600 d...2023-04-25T18:41:44ZNitin ReddyHyperX DuoCast: The decibel volume range for element 'PCM' (-4000 dB - -600 dB) has negative maximum. Disabling the decibel range.<!-- 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`):
## Description of Problem:
Whenever I boot my system, I am getting these errors in the kernel/boot logs
```
Apr 05 19:39:22 pop-os wireplumber[1427]: The decibel volume range for element 'PCM' (-4000 dB - -600 dB) has negative maximum. Disabling the decibel range.
Apr 05 19:39:22 pop-os wireplumber[1427]: The decibel volume range for element 'PCM' (-4000 dB - -600 dB) has negative maximum. Disabling the decibel range.
Apr 05 19:39:22 pop-os wireplumber[1427]: The decibel volume range for element 'PCM' (-4000 dB - -600 dB) has negative maximum. Disabling the decibel range.
Apr 05 19:39:22 pop-os wireplumber[1427]: The decibel volume range for element 'PCM' (-4000 dB - -600 dB) has negative maximum. Disabling the decibel range.
Apr 05 19:39:22 pop-os wireplumber[1427]: The decibel volume range for element 'PCM' (-4000 dB - -600 dB) has negative maximum. Disabling the decibel range.
```
## How Reproducible:
Every time
### Steps to Reproduce:
1. Just boot the machine
2.
3.
### Expected Results:
No errors are expected
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:[pw-dump.log](/uploads/92c9dd76a1e799efb13fc6d77037684d/pw-dump.log)
My input mic (HyperX DuoCast) volume is too low. If I set to 150% gain, the audio volume is in acceptable range.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3137No sound in labtop speakers on startup2023-04-11T16:08:20ZIvan KochergaNo sound in labtop speakers on startupHello. I have migrated from Pulse Audio to Pipewire on Manjaro Linux 22. I am a blind user. I need to use Orca's screen reader for work. When working with Pipevire, every time the system boots up, there is no sound in the laptop's built-...Hello. I have migrated from Pulse Audio to Pipewire on Manjaro Linux 22. I am a blind user. I need to use Orca's screen reader for work. When working with Pipevire, every time the system boots up, there is no sound in the laptop's built-in speakers. At the same time, if you connect wired headphones to the built-in port of the laptop or connect an external sound card, the sound in the headphones will appear. If you then turn off the headphones, the sound appears in the speakers of the laptop, but if you restart the system, it will disappear again. I'm using a Dell Vostro 5410 with Intel Core I 5 11300 H, Manjaro 22, 6.2.8 kernel, Pipewire 1.0.3.67, WirePlumber 0.4.14.1. Orca 43.1. Sound card Intel Tigerlake LP. I know that another person with Orca and ArchLinux has this problem.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3132Intermittent crashes on Steam startup2023-09-02T19:07:24ZMichael LelliIntermittent crashes on Steam startup<!-- 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.67
- 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.67
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: KDE Plasma 5.27.3
- Kernel version (`uname -r`): 6.2.8-arch1-1
## Description of Problem:
Reported on Steam's tracker but was also told it might be worth reporting here as well: https://github.com/ValveSoftware/steam-for-linux/issues/9060
This has been happening since at least early January, and on Pipewire 0.3.63 and later. Sometimes Steam will always crash during launching, in some PulseAudio/libaudio code.
## How Reproducible:
Occasionally. It seems to always happen sometimes after boot, but can go away if the Pipewire service is restarted: `systemctl --user restart pipewire.service`
### Steps to Reproduce:
1. Start Steam
### Actual Results:
Steam crashes
### Expected Results:
Backlog from a crash (all from the Steam runtime so may not be too useful):
```
#0 0xe8e9a987 in ?? () from /home/michael/.local/share/Steam/ubuntu12_32/libaudio.so
#1 0xf0b1e1bf in ?? () from /home/michael/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libpulse.so.0
#2 0xf050c25d in ?? () from /home/michael/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libpulsecommon-1.1.so
#3 0xf050c660 in pa_pdispatch_run () from /home/michael/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libpulsecommon-1.1.so
#4 0xf0b114dd in ?? () from /home/michael/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libpulse.so.0
#5 0xf0511c33 in ?? () from /home/michael/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libpulsecommon-1.1.so
#6 0xf04fbf98 in ?? () from /home/michael/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libpulsecommon-1.1.so
#7 0xf0b285a5 in pa_mainloop_dispatch () from /home/michael/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libpulse.so.0
#8 0xf0b28a83 in pa_mainloop_iterate () from /home/michael/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libpulse.so.0
#9 0xf0b28b54 in pa_mainloop_run () from /home/michael/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libpulse.so.0
#10 0xf0b39f3e in ?? () from /home/michael/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libpulse.so.0
#11 0xf05225b6 in ?? () from /home/michael/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libpulsecommon-1.1.so
#12 0xf7a87485 in start_thread (arg=<optimized out>) at pthread_create.c:442
#13 0xf7b24efc in clone3 () at ../sysdeps/unix/sysv/linux/i386/clone3.S:111
```
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3131Port detection not working on Roland STUDIO-CAPTURE2023-04-13T07:16:18ZLuke EndresPort detection not working on Roland STUDIO-CAPTURE<!-- 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.65
Linked with libpipewire 0.3.65
- Distribu...<!-- 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.65
Linked with libpipewire 0.3.65
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
Debian GNU/Linux 12 (bookworm)
- Desktop Environment:
GNOME Shell 43.3
- Kernel version (`uname -r`):
6.1.0-7-rt-amd64
## Description of Problem:
Gnome Settings Output Device contains nothing to select, while Input allows "Analog Input - STUDIO-CAPTURE" and "STUDIO-CAPTURE Pro". The only way to have output audio working is to use pavucontrol and select either of the STUDIO-CAPTURE Profile Configurations "Multichannel Output", or "Pro Audio". That "Multichannel Output" Profile disappeared after I ran JACK (ardour), and I only see again now on a fresh startup. The "Pro Audio" Profile, however, remains after running JACK, which is very gratifying.
Even with pavucontrol setup to correct the output issue, Gnome Settings doesn't allow to select an Output Device and it is empty.
## How Reproducible:
This is my only install to test, but it is continued behavior.
### Steps to Reproduce:
1. Open Gnome Settings
2. Output Device is empty
### Actual Results:
Gnome Settings Output Device can't be selected and is empty.
### Expected Results:
Gnome Settings Output Device should allow selecting the STUDIO-CAPTURE or perhaps "STUDIO-CAPTURE - Multichannel Output"
# Additional Info (as attachments):
[pw-dump.log](/uploads/a8b851a85dc0fd506942c4ae283f29b4/pw-dump.log)
- `pw-dump > pw-dump.log`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3130Fiio KA3 wrong default volume on a hidden multiplier (PCM1) in alsamixer2023-04-01T21:35:01ZSejselFiio KA3 wrong default volume on a hidden multiplier (PCM1) in alsamixer<!-- 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.67
- 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.67
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: Cinnamon 5.6.8
- Kernel version (`uname -r`): 6.2.8-zen1-1-zen
## Description of Problem:
When plugging in a FiiO KA3 for the first time, the **max** volume was surprisingly low. Compared it with Windows that I happened to have, where the max volume is significantly higher. The PCM1 channel in alsamixer was set to 60% rather than 100%. This is a hidden multiplier to the standard volume slider and is not exposed by the UI anywhere in pavucontrol, Cinnamon UI or anywhere else I could find.
![image](/uploads/05e9515f28c810529236b362f1d77d3e/image.png)
## How Reproducible:
Likely always, I hope.
### Steps to Reproduce:
1. Plug in a Fiio KA3 for the first time
2. Despair over low max volume
### Actual Results:
PCM1 volume is set to ~60%.
### Expected Results:
PCM1 volume is set to 100% by default or does not exist at all.
# Additional Info (as attachments):
- `[pw-dump.log](/uploads/8fc55bddffc47d297d0f4630c3a2eca5/pw-dump.log) > pw-dump.log`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3129Unable to connect to Sonos speakers via AirPlay2023-12-18T13:37:15ZRoland0206Unable to connect to Sonos speakers via AirPlayI'm facing issues trying to use my Sonos One SL speakers with PipeWire on my EndeavorOS Linux system. I have successfully installed and started PipeWire services, but when I try to load the RAOP (Remote Audio Output Protocol) module usin...I'm facing issues trying to use my Sonos One SL speakers with PipeWire on my EndeavorOS Linux system. I have successfully installed and started PipeWire services, but when I try to load the RAOP (Remote Audio Output Protocol) module using the pactl command, I receive the following error message: "Failure: No such entity".
I have already verified that my Sonos speakers are connected to the same network as my Linux system by pinging their IP address. However, when I try to load the RAOP module using the IP address of the Sonos speaker, I still receive the same error.
I'm not sure what I'm missing or if there is any additional configuration required to use Sonos speakers with PipeWire. Can someone please guide me on how to troubleshoot this issue?https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3126Alpha format isn't specified (premultiplied/straight)2023-03-30T13:19:05ZAsahi LinaAlpha format isn't specified (premultiplied/straight)## Description of Problem:
PipeWire currently does not seem to have working support for specifying whether alpha is premultiplied or not. There is `spa_video_flags` which has `SPA_VIDEO_FLAG_PREMULTIPLIED_ALPHA`, but it is never set in ...## Description of Problem:
PipeWire currently does not seem to have working support for specifying whether alpha is premultiplied or not. There is `spa_video_flags` which has `SPA_VIDEO_FLAG_PREMULTIPLIED_ALPHA`, but it is never set in `spa_format_video_raw_parse` and there isn't a `SPA_FORMAT_VIDEO_flags` (though there *is* a `SPA_TYPE_INFO_VideoFlags`?)
As far as I can tell, the current default convention is to use premultiplied alpha and nobody attempts to implement the distinction, so maybe this should instead be changed to a flag to use straight alpha, defaulting to false? Or just specify somewhere that alpha formats are assumed to be premultiplied? I couldn't find any prior documentation/discussion about this...
Edit: Cursor bitmap alpha mode is also unspecified. Both GNOME and KDE use premultiplied here also.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3122Support per-session PipeWire servers as clients to system-wide PipeWire server.2023-05-10T22:49:47Zkenji amanoSupport per-session PipeWire servers as clients to system-wide PipeWire server.I don't know whether this is already possible because I just started learning PipeWire.
I want to be able to play sound from system cronjobs through PipeWire, but I also want to play sound in desktop environments.
One system-wide PipeW...I don't know whether this is already possible because I just started learning PipeWire.
I want to be able to play sound from system cronjobs through PipeWire, but I also want to play sound in desktop environments.
One system-wide PipeWire server can do the job, but some things like portal require session d-bus which lives in each login session.
Thus, system-wide PipeWire server cannot use portal if per-session PipeWire servers are not clients to the system-wide PipeWire server.
Per-session pipewire servers should not add latency to system-wide pipewire server.
I could make system-wide PipeWire server and per-session PipeWire servers use ALSA dmix, but ALSA dmix adds latency. I want to minimize latency.