pipewire issueshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues2023-07-09T18:13:27Zhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3248Bluetooth audio source plays without sound randomly2023-07-09T18:13:27ZFrom SkyBluetooth audio source plays without sound randomly- PipeWire version (`pipewire --version`):0.3.71
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):Arch Linux
- Desktop Environment: GNOME
- Kernel version (`uname -r`):6.3.3-arch1-1
- BlueZ version (`bluetoo...- PipeWire version (`pipewire --version`):0.3.71
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):Arch Linux
- Desktop Environment: GNOME
- Kernel version (`uname -r`):6.3.3-arch1-1
- BlueZ version (`bluetoothctl --version`):5.66
- Bluetooth devices:Bus 001 Device 005: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
## Description of Problem:
I use my computer as a bluetooth speaker for my Android phone,since it's the default behavior when connecting a phone to computer with bluetooth, both pulseaudio and pipewire. Recently I found when I start to play some media on my phone, sometime there's no sound, and the other times it goes well. I can't remember which version of which software make things different, but it seems the issue didn't show in the past.
There's a way to reproduce stably:
1. connect phone to computer with bluetooth.
2. play some media(video, music) on the phone. It may start to play normally, and a output node and connections shows in helvum application.
3. pause the media on the phone. the node will disappear in 2~3 seconds later.
4. when the node disappear, start to play again at the same time, there will be no sound, but video and process bar will be still active on the phone. In helvum, the node will shows for a while, and then disappear rapidly, when video still playing on my phone.
5. If repeating play and pause after the node disappear, the sound may start to play again.
Besides, there's also other conditions will cause the problem, such as play media quickly after connecting may lead to it. I tried to change some config for wireplumber or bluetooth, but solved nothing.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3247No output on Airplay 1 device (raop)2023-12-10T13:55:08Zobli ratNo output on Airplay 1 device (raop)<!-- 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`):0\.3...<!-- 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`):0\.3.71
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): TUXEDO OS 2
- Desktop Environment: KDE Plasma
- Kernel version (`uname -r`): 6.2.0-10007-tuxedo
- `lsusb`:
```Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1c4f:0048 SiGma Micro Usb Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 004: ID 8087:0029 Intel Corp. AX200 Bluetooth
Bus 002 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 002 Device 002: ID 04f2:b71a Chicony Electronics Co., Ltd HD Webcam
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```
## Description of Problem:
I have a multiroom audio device, compatible airport 1 and upnp/dnla.
```<dlna:X_DLNADOC>DMR-1.50</dlna:X_DLNADOC>
<deviceType>urn:schemas-upnp-org:device:MediaRenderer:1</deviceType>
<friendlyName>link1</friendlyName>
<manufacturer>Linkplay Technology Inc.</manufacturer>
<manufacturerURL>http://www.muzohifi.com</manufacturerURL>
<modelDescription>MUZO Cobblestone</modelDescription>
<modelName>MUZO Cobblestone</modelName>
<modelURL>http://www.muzohifi.com</modelURL>
<UDN>uuid:FF280014-1F91-4F11-A113-5BF9FF280014</UDN>
<modelNumber>V01-Dec 10 2021 </modelNumber>
<serialNumber>00001</serialNumber>
<ssidName>AudioPro_LINK1_339715</ssidName>
<uuid>FF2800141F914F11A1135BF9</uuid>
<qq:X_QPlay_SoftwareCapability xmlns:qq="http://www.tencent.com">QPlay:2</qq:X_QPlay_SoftwareCapability>
```
From my phone with Bubbleupnp, i can send my music to my old hifi. But on my linux laptop, when i load `pactl load-module module-raop-discover`, my laptop can see the sink "link 1" but no sound output on my hifi.
## How Reproducible:
1. Load `module-roap-discover`
2. Try to play audio (from Firefox, Lollypop,...)
### Actual Results:
no audio output
# Additional Info (as attachments):
[pw-dump.log](/uploads/347924eaa2deae3a8ac3ff5a8c6ddea8/pw-dump.log)
- ![pipewire](/uploads/5459415fba37c1c8120a0d3ab90cc4c9/pipewire.jpg)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3246Upgrading from pipewire pipewire-1:0.3.70 to pipewire-1:0.3.71 causes audio a...2023-07-04T04:01:02ZEvert VorsterUpgrading from pipewire pipewire-1:0.3.70 to pipewire-1:0.3.71 causes audio application to hang<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 1:0.3.70
```
Operating System: Arch Linux
KDE Plasma Version: 5.27.5
KDE Frameworks...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 1:0.3.70
```
Operating System: Arch Linux
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.106.0
Qt Version: 5.15.9
Kernel Version: 6.3.3-AMD-znver2 (64-bit)
Graphics Platform: Wayland
Processors: 8 × AMD Ryzen 7 4700U with Radeon Graphics
Memory: 36.9 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: LENOVO
Product Name: 20T8001JUS
System Version: ThinkPad E15 Gen 2
```
## Description of Problem:
Audacity hangs when called from Kdenlive
## How Reproducible:
Always
### Steps to Reproduce:
1. Set both Audacity and Kdenlive to use pipewire as audio backend
2. Set Audacity to be the sound editor in Kdnelive
3. Right-click on some sound file in the Project Bin in Kdenlive, and select "Edit"
### Actual Results:
Before the upgrade, Audacity would start and load the file requested. After the upgrade, the audacity process would fire up, but not display a UI until either Kdenlive is exited, or the audio backend in kdenlive is changed to something other than pipewire.
### Expected Results:
Audacity to start up as it used to do with pipewire 1:0.3.70
# Additional Info (as attachments):
- `pw-dump > pw-dump.log` during the hanging: [pw-dump.log](/uploads/55536fa6b5997bce2e2147ce9eb58525/pw-dump.log)
- pw-dump log after kdenlive has been shut down, and audacity popped up and was shut down too: [pw-dump_after.log](/uploads/03f906405b58dad6314168682dd97b80/pw-dump_after.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3241api.alsa.period-size is not respected2023-05-25T11:10:36ZMichele Sorcinelliapi.alsa.period-size is not respectedI'm using the following configuration:
```lua
local rule = {
matches = {
{
{
'node.name',
'equals',
'alsa_output.usb-Focusrite_Scarlett_2i2_USB_Y8AUM280954FBA-00.HiFi__scarlett2i_stereo_out_USB_0_0_1_...I'm using the following configuration:
```lua
local rule = {
matches = {
{
{
'node.name',
'equals',
'alsa_output.usb-Focusrite_Scarlett_2i2_USB_Y8AUM280954FBA-00.HiFi__scarlett2i_stereo_out_USB_0_0_1__sink',
},
},
{
{
'node.name',
'equals',
'alsa_input.usb-Focusrite_Scarlett_2i2_USB_Y8AUM280954FBA-00.HiFi__scarlett2i_mono_in_USB_0_0__source',
},
},
{
{
'node.name',
'equals',
'alsa_input.usb-Focusrite_Scarlett_2i2_USB_Y8AUM280954FBA-00.HiFi__scarlett2i_mono_in_USB_0_1__source',
},
},
},
apply_properties = {
-- reduce latency
['api.alsa.period-size'] = 128,
},
}
table.insert(alsa_monitor.rules, rule)
```
And indeed when the node are registered, they get registered with 128 as buffer size:
```
$ pw-dump | grep 'period-size": '
"api.alsa.period-size": 128,
"api.alsa.period-size": 128,
"api.alsa.period-size": 128,
```
However, as soon as I connect something to the sink, the sink period size changes to 480 instead.
```
pw-dump | grep 'period-size": '
"api.alsa.period-size": 480,
"api.alsa.period-size": 128,
"api.alsa.period-size": 128,
```
```
$ cat /proc/asound/card*/*/*/hw_params
closed
closed
closed
closed
closed
closed
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 480
buffer_size: 24000
```
I've attached the full pw-dump output for reference.
[pw-dump.json](/uploads/01a8cdbdb393afe44acf1730a26b35c4/pw-dump.json) (pipewire 0.3.70)
P.S: I've tested this on 0.3.70, as well as using the master git branch
Here's the [pw-dump.json](/uploads/2c9be1fcc354755c917e9baeea02b65d/pw-dump.json) when running from master (b74f2e19a740c243de2476c9f7f07336c1209ff0).https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3237Screencasting is broken from 0135a1fc053b07bc3376b5140d927d31e54f8829 onwards...2023-05-30T04:59:30ZAidan HarrisScreencasting is broken from 0135a1fc053b07bc3376b5140d927d31e54f8829 onwards (master)![screencasting_broken](/uploads/7ecbee50131d33322b5f781d7af32f26/screencasting_broken.png)
```
0135a1fc053b07bc3376b5140d927d31e54f8829 is the first bad commit
commit 0135a1fc053b07bc3376b5140d927d31e54f8829
Author: Wim Taymans <wtayman...![screencasting_broken](/uploads/7ecbee50131d33322b5f781d7af32f26/screencasting_broken.png)
```
0135a1fc053b07bc3376b5140d927d31e54f8829 is the first bad commit
commit 0135a1fc053b07bc3376b5140d927d31e54f8829
Author: Wim Taymans <wtaymans@redhat.com>
Date: Sun May 21 15:43:22 2023 +0200
client-node: signal graph complete
Use the writefd for waking up the server when the graph completed. Make
this emit the complete event so that the profiler can capture the
data.
src/modules/module-client-node/client-node.c | 7 ++-----
src/modules/module-client-node/remote-node.c | 26 ++++++++++++++++++++++++++
2 files changed, 28 insertions(+), 5 deletions(-)
bisect found first bad commithttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3236Simple Gstreamer pipeline with pipewiresrc and pipewiresink seems to corrupt ...2023-05-24T09:24:00ZVictor FloreaSimple Gstreamer pipeline with pipewiresrc and pipewiresink seems to corrupt the video<!-- 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.68
- 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.68
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Ubuntu 22.04.2 LTS
- Desktop Environment: GNOME 42.5
- Kernel version (`uname -r`): 5.19.0-42-generic
## Description of Problem:
I am starting with Pipewire / Gstreamer and I'm trying to set up 2 simple Gstreamer pipelines:
- One that takes in a video feed from a webcam, using pipewire src, then outputs it using pipewiresink. This will eventually have some processing in it, but for now I am just trying to get pipewire working,
- One that has a pipewire src that connects to the previous pipeline's pipewiresink, and uses autovideosink to display it
Here are the commands used:
```
gst-launch-1.0 pipewiresrc path=56 client-name=A_IN ! videoconvert ! pipewiresink mode=provide client-name=A_OUT
```
```
gst-launch-1.0 pipewiresrc path=66 ! videoconvert ! autovideosink
```
I noticed the QUANT and RATE look quite different between the webcam and the A_OUT. Not sure if this is expected.
```
S ID QUANT RATE WAIT BUSY W/Q B/Q ERR FORMAT NAME
S 28 0 0 --- --- --- --- 0 Dummy-Driver
S 29 0 0 --- --- --- --- 0 Freewheel-Driver
S 48 0 0 --- --- --- --- 0 Midi-Bridge
R 56 1 30 27.0us 1.2us 0.00 0.00 0 YUY2 640x480 v4l2_input.pci-0000_00_14.0-usb-0_10_1.0
R 47 0 0 16.8us 3.8us 0.00 0.00 0 YUY2 640x480 + A_IN
S 60 0 0 --- --- --- --- 0 alsa_input.usb-046d_0825_55647490-02.mono-fallb
S 62 0 0 --- --- --- --- 0 alsa_output.pci-0000_01_00.1.hdmi-stereo-extra1
S 63 0 0 --- --- --- --- 0 alsa_output.usb-C-Media_Electronics_Inc._USB_Pn
S 64 0 0 --- --- --- --- 0 alsa_input.usb-C-Media_Electronics_Inc._USB_PnP
R 66 1024 48000 87.2us 1.7us 0.00 0.00 0 YUY2 640x480 A_OUT
R 44 0 0 20.1us 8.4us 0.00 0.00 0 YUY2 640x480 + gst-launch-1.0
```
I was unsure if I should use videoconvert in this case, but the behaviour is the same with and without them.
## How Reproducible:
Happens every time
### Steps to Reproduce:
1. `gst-launch-1.0 pipewiresrc path=56 client-name=A_IN ! videoconvert ! pipewiresink mode=provide client-name=A_OUT`
2. `gst-launch-1.0 pipewiresrc path=44 ! videoconvert ! autovideosink`
### Actual Results:
Instead of the autovideosink showing the camera feed, the view looks as if it takes one horizontal line of the image and expands it vertically:
![image](/uploads/822842b10f0171c5632da17fecaf2942/image.png)
### Expected Results:
I expected to get a video feed from the web camera
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/622188b99b90301c992beb0656c3a12b/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3235Not getting battery percentage for bluetooth audio devices2024-03-16T16:50:02ZNavroop SinghNot getting battery percentage for bluetooth audio devices- PipeWire version (`pipewire --version`): 0.3.65
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Ubuntu 23.04
- Desktop Environment: GNOME 44
- Kernel version (`uname -r`): 6.2.0-20-generic
- BlueZ versio...- PipeWire version (`pipewire --version`): 0.3.65
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Ubuntu 23.04
- Desktop Environment: GNOME 44
- Kernel version (`uname -r`): 6.2.0-20-generic
- BlueZ version (`bluetoothctl --version`): 5.66
- `lsusb`:
```
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 13d3:56c9 IMC Networks HP TrueVision HD Camera
Bus 001 Device 004: ID 0bda:b00a Realtek Semiconductor Corp. Realtek Bluetooth 4.2 Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```
- Bluetooth devices:
```
Device D4:8A:39:AB:5E:BA F41
Device 11:23:24:98:5D:A0 Rockerz 650
Device 18:95:52:32:A8:7A realme Buds Wireless 2
```
## Description of Problem:
I am not getting battery percentage for my Bluetooth headphones (Rockerz 650 (11:23:24:98:5D:A0)) neither in settings nor using upower -d.
For other devices like my phone when connected through bluetooth, it displays the battery percentage.
Also the battery percentage is visible for these headphone when connected on Windows on same PC and also on android.
When I run the debug log command: `WIREPLUMBER_NO_PW_LOG=1 PIPEWIRE_DEBUG=4 wireplumber 2>&1 | grep --line-buffered -Ei '^\[?[EW]\]?|spa\.bluez5' > pipewire-bluez.log`, the battery percentage was visible in the settings, but not otherwise.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:
[pw-dump.log](/uploads/c623c36bfbb7fdec346244f2d203d7d1/pw-dump.log)
- Bluetooth debug log, see [here](https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting#bluetooth):
[pipewire-bluez.log](/uploads/4bca4375badca6e916df3a53dd93ba5b/pipewire-bluez.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3233Center channel upmixing not working (Regression since 0.3.66)2023-05-22T14:28:29ZZelberorCenter channel upmixing not working (Regression since 0.3.66)<!-- 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.70
- 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.70
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: KDE Plasma 5.27.5
- Kernel version (`uname -r`): 6.2.13-arch1-1
## Description of Problem:
When upmixing from a stereo source (e.g. Spotify) to a 5.1 output device, the center channel does not play any audio.
But the rear channels get upmixed as expected.
I use the following config in all of /etc/pipewire/client-rt.conf.d, client.conf.d, pipewire-pulse.conf.d:
```
stream.properties = {
#node.latency = 1024/48000
#node.autoconnect = true
resample.quality = 8
channelmix.disable = false
channelmix.normalize = false
channelmix.mix-lfe = false
channelmix.upmix = true
channelmix.upmix-method = simple
channelmix.lfe-cutoff = 0
channelmix.fc-cutoff = 0
channelmix.rear-delay = 12.0
channelmix.stereo-widen = 0.0
channelmix.hilbert-taps = 100
audio.format = S32LE
}
```
I don't have any config files in my ~/.config/pipewire... directory
With channelmix.mix-lfe set to true the lfe channel also seems to stay silent.
**When using a 5.1 capable software, the center channel works as expected.**
For example in the KDE sound tester the center speaker properly outputs audio.
Also routing a sound stream in Carla to the center channel works.
**Note that with pipewire version 0.3.65 and the exact same config the center channel upmixing works.**
As soon as I switch to 0.3.66 or up, the center channel stays silent.
## How Reproducible:
### Steps to Reproduce:
1. Set the Output device to Digital Surround 5.1.
2. Play audio from a stereo source like Spotify
3. Don't hear the center channel
# Additional Info (as attachments):
- `pw-dump > pw-dump.log` for version 0.3.70: [0.3.70-pwdump.log](/uploads/092a9cb4698f2f7bedb6c59210139240/0.3.70-pwdump.log)
- `pw-dump > pw-dump.log` for version 0.3.65: [0.3.65-pwdump.log](/uploads/2e7fb9c3beab1278a24c056b2a50ab9f/0.3.65-pwdump.log)
- carla screenshot (same for both versions): ![carla-screenshot](/uploads/a5e453e0c94f4bcfa851d74462e679db/carla-screenshot.png)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3232'Random' assertion caused by libpipewire crashed Music Player Daemon (MPD)2023-05-21T22:20:43ZGuilherme'Random' assertion caused by libpipewire crashed Music Player Daemon (MPD)- PipeWire version (`pipewire --version`): 0.3.70
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: KDE Plasma 5.27
- Kernel version (`uname -r`): 6.1.29
## Description of ...- PipeWire version (`pipewire --version`): 0.3.70
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: KDE Plasma 5.27
- Kernel version (`uname -r`): 6.1.29
## Description of Problem:
Music Player Daemon (MPD) recently crashed for me, and after [I reported the crash on the MPD bug tracker](https://github.com/MusicPlayerDaemon/MPD/issues/1812), the developer mentioned this could be caused by libpipewire.
As I mentioned in the MPD bug report, I was able to get a stack trace, but I'm not sure if it's useful (feel free to close this if it isn't):
```
Thread 9 (Thread 0x7f15e41650c0 (LWP 640)):
#0 0x00007f15f4c34266 in epoll_wait (epfd=4, events=0x7ffd09f46500, maxevents=16, timeout=60438) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1 0x000055ef5dcb9fd0 in EpollFD::Wait(epoll_event*, int, int) (timeout=<optimized out>, maxevents=16, events=0x7ffd09f46500, this=0x7ffd09f47438) at ../mpd-0.23.12/src/io/FileDescriptor.hxx:104
#2 EpollBackend::ReadEvents(int) (timeout_ms=<optimized out>, this=0x7ffd09f47438) at ../mpd-0.23.12/src/event/EpollBackend.hxx:60
#3 EventLoop::Wait(std::chrono::duration<long, std::ratio<1l, 1000000000l> >) (timeout=Python Exception <class 'gdb.error'>: value has been optimized out
, this=0x7ffd09f46ba8) at ../mpd-0.23.12/src/event/Loop.cxx:252
#4 EventLoop::Run() (this=0x7ffd09f46ba8) at ../mpd-0.23.12/src/event/Loop.cxx:343
#5 0x000055ef5dc81706 in MainConfigured(CommandLineOptions const&, ConfigData const&) (options=..., raw_config=...) at ../mpd-0.23.12/src/Main.cxx:576
#6 0x000055ef5dc827bc in MainOrThrow(int, char**) (argc=<optimized out>, argv=0x7ffd09f48b88) at ../mpd-0.23.12/src/Main.cxx:691
#7 0x000055ef5dc794ce in mpd_main(int, char**) (argv=<optimized out>, argc=<optimized out>) at ../mpd-0.23.12/src/Main.cxx:697
#8 main(int, char**) (argc=<optimized out>, argv=<optimized out>) at ../mpd-0.23.12/src/Main.cxx:709
Thread 8 (LWP 702):
#0 0x0000000000000000 in ()
Thread 7 (Thread 0x7f15e3dae6c0 (LWP 692)):
#0 0x00007f15f4c34266 in epoll_wait (epfd=6, events=0x7f15e3dad440, maxevents=16, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1 0x000055ef5dcb9fd0 in EpollFD::Wait(epoll_event*, int, int) (timeout=<optimized out>, maxevents=16, events=0x7f15e3dad440, this=0x7ffd09f47ce8) at ../mpd-0.23.12/src/io/FileDescriptor.hxx:104
#2 EpollBackend::ReadEvents(int) (timeout_ms=<optimized out>, this=0x7ffd09f47ce8) at ../mpd-0.23.12/src/event/EpollBackend.hxx:60
#3 EventLoop::Wait(std::chrono::duration<long, std::ratio<1l, 1000000000l> >) (timeout=Python Exception <class 'gdb.error'>: value has been optimized out
, this=0x7ffd09f47458) at ../mpd-0.23.12/src/event/Loop.cxx:252
#4 EventLoop::Run() (this=0x7ffd09f47458) at ../mpd-0.23.12/src/event/Loop.cxx:343
#5 0x000055ef5dcb4c21 in BoundMethod<void () noexcept>::operator()() const (this=<optimized out>, this=<optimized out>) at ../mpd-0.23.12/src/util/BindMethod.hxx:78
#6 Thread::Run() (this=<optimized out>) at ../mpd-0.23.12/src/thread/Thread.cxx:63
#7 Thread::ThreadProc(void*) (ctx=<optimized out>) at ../mpd-0.23.12/src/thread/Thread.cxx:92
#8 0x00007f15f4bb044b in start_thread (arg=<optimized out>) at pthread_create.c:444
#9 0x00007f15f4c33d64 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
Thread 6 (Thread 0x7f15e25ab6c0 (LWP 695)):
#0 0x00007f15f780d15b in III_huffdecode (part3_length=<optimized out>, sfbwidth=<optimized out>, channel=<optimized out>, xr=0x7f15e2597860, ptr=0x7f15e2598230) at /usr/src/debug/libmad/libmad-0.15.1b/layer3.c:1284
#1 III_decode (ptr=ptr@entry=0x7f15e2598230, frame=frame@entry=0x7f15e2598568, si=si@entry=0x7f15e2598240, nch=nch@entry=2, md_len=md_len@entry=381) at /usr/src/debug/libmad/libmad-0.15.1b/layer3.c:2479
#2 0x00007f15f780fba5 in mad_layer_III (stream=0x7f15e25984f0, frame=0x7f15e2598568) at /usr/src/debug/libmad/libmad-0.15.1b/layer3.c:2736
#3 0x00007f15f7811566 in mad_frame_decode (frame=0x7f15e2598568, stream=0x7f15e25984f0) at /usr/src/debug/libmad/libmad-0.15.1b/frame.c:467
#4 0x000055ef5dd051fc in MadDecoder::DecodeNextFrame(bool, Tag*) (this=this@entry=0x7f15e25984f0, skip=<optimized out>, tag=tag@entry=0x7f15e25984e0) at ../mpd-0.23.12/src/decoder/plugins/MadDecoderPlugin.cxx:403
#5 0x000055ef5dd06465 in MadDecoder::LoadNextFrame() (this=<optimized out>) at ../mpd-0.23.12/src/decoder/plugins/MadDecoderPlugin.cxx:913
#6 MadDecoder::Read() (this=0x7f15e25984f0) at ../mpd-0.23.12/src/decoder/plugins/MadDecoderPlugin.cxx:937
#7 MadDecoder::RunDecoder() (this=0x7f15e25984f0) at ../mpd-0.23.12/src/decoder/plugins/MadDecoderPlugin.cxx:964
#8 mad_decode(DecoderClient&, InputStream&) (client=<optimized out>, input_stream=<optimized out>) at ../mpd-0.23.12/src/decoder/plugins/MadDecoderPlugin.cxx:971
#9 0x000055ef5dc84a1e in DecoderPlugin::StreamDecode(DecoderClient&, InputStream&) const (is=..., client=..., this=0x55ef5ddb1ac0 <mad_decoder_plugin>) at ../mpd-0.23.12/src/decoder/DecoderPlugin.hxx:202
#10 decoder_stream_decode(DecoderPlugin const&, DecoderBridge&, InputStream&, std::unique_lock<std::mutex>&) (plugin=..., bridge=..., input_stream=..., lock=...) at ../mpd-0.23.12/src/decoder/Thread.cxx:119
#11 0x000055ef5dc8edee in TryDecoderFile (plugin=..., input_stream=..., suffix="mp3", path_fs=..., bridge=...) at ../mpd-0.23.12/src/decoder/Thread.cxx:349
#12 operator() (plugin=..., __closure=<synthetic pointer>) at ../mpd-0.23.12/src/decoder/Thread.cxx:430
#13 decoder_plugins_try<decoder_run_file(DecoderBridge&, char const*, Path)::<lambda(const DecoderPlugin&)> > (f=...) at ../mpd-0.23.12/src/decoder/DecoderList.hxx:72
#14 decoder_run_file (path_fs=..., uri_utf8=0x55ef5df3c970 "/mnt/Music/Joey Bada$$/2015 - B4.DA.$$/14 - O.C.B.mp3", bridge=...) at ../mpd-0.23.12/src/decoder/Thread.cxx:428
#15 DecoderUnlockedRunUri (path_fs=..., real_uri=0x55ef5df3c970 "/mnt/Music/Joey Bada$$/2015 - B4.DA.$$/14 - O.C.B.mp3", bridge=...) at ../mpd-0.23.12/src/decoder/Thread.cxx:448
#16 decoder_run_song (path_fs=..., uri=0x55ef5df3c970 "/mnt/Music/Joey Bada$$/2015 - B4.DA.$$/14 - O.C.B.mp3", song=..., dc=...) at ../mpd-0.23.12/src/decoder/Thread.cxx:510
#17 decoder_run(DecoderControl&) (dc=...) at ../mpd-0.23.12/src/decoder/Thread.cxx:551
#18 0x000055ef5dc8f649 in DecoderControl::RunThread() (this=0x7f15e2dab3a0) at ../mpd-0.23.12/src/decoder/Thread.cxx:576
#19 BindMethodDetail::WrapperGenerator<void (DecoderControl::*)() noexcept, &DecoderControl::RunThread>::Invoke(void*) (_instance=0x7f15e2dab3a0) at ../mpd-0.23.12/src/util/BindMethod.hxx:130
#20 0x000055ef5dcb4c21 in BoundMethod<void () noexcept>::operator()() const (this=<optimized out>, this=<optimized out>) at ../mpd-0.23.12/src/util/BindMethod.hxx:78
#21 Thread::Run() (this=<optimized out>) at ../mpd-0.23.12/src/thread/Thread.cxx:63
#22 Thread::ThreadProc(void*) (ctx=<optimized out>) at ../mpd-0.23.12/src/thread/Thread.cxx:92
#23 0x00007f15f4bb044b in start_thread (arg=<optimized out>) at pthread_create.c:444
#24 0x00007f15f4c33d64 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
Thread 5 (Thread 0x7f15e2dac6c0 (LWP 694)):
#0 0x00007f15f4bacf0e in __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x55ef5de9d9d4) at futex-internal.c:57
#1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x55ef5de9d9d4, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2 0x00007f15f4bacf8f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x55ef5de9d9d4, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3 0x00007f15f4baf7a0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55ef5de9d980, cond=0x55ef5de9d9a8) at pthread_cond_wait.c:503
#4 ___pthread_cond_wait (cond=0x55ef5de9d9a8, mutex=0x55ef5de9d980) at pthread_cond_wait.c:618
#5 0x00007f15f4ed9e11 in __gthread_cond_wait (__mutex=<optimized out>, __cond=0x55ef5de9d9a8) at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:865
#6 std::__condvar::wait(std::mutex&) (__m=<optimized out>, this=0x55ef5de9d9a8) at /usr/src/debug/gcc/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/std_mutex.h:171
#7 std::condition_variable::wait(std::unique_lock<std::mutex>&) (this=this@entry=0x55ef5de9d9a8, __lock=...) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/condition_variable.cc:41
#8 0x000055ef5dc99b0d in PlayerControl::Wait(std::unique_lock<std::mutex>&) (lock=..., this=0x55ef5de9d938) at ../mpd-0.23.12/src/player/Control.hxx:377
#9 PlayerControl::WaitOutputConsumed(std::unique_lock<std::mutex>&, unsigned int) (threshold=64, lock=..., this=0x55ef5de9d938) at ../mpd-0.23.12/src/player/Control.cxx:54
#10 PlayerControl::WaitOutputConsumed(std::unique_lock<std::mutex>&, unsigned int) (this=this@entry=0x55ef5de9d938, lock=..., threshold=threshold@entry=64) at ../mpd-0.23.12/src/player/Control.cxx:49
#11 0x000055ef5dc9f96c in PlayerControl::LockWaitOutputConsumed(unsigned int) (threshold=64, this=0x55ef5de9d938) at ../mpd-0.23.12/src/player/Control.hxx:437
#12 Player::PlayNextChunk() (this=0x7f15e2dab2d0) at ../mpd-0.23.12/src/player/Thread.cxx:836
#13 Player::Run() (this=0x7f15e2dab2d0) at ../mpd-0.23.12/src/player/Thread.cxx:1078
#14 do_play (buffer=..., dc=..., pc=...) at ../mpd-0.23.12/src/player/Thread.cxx:1158
#15 PlayerControl::RunThread() (this=0x55ef5de9d938) at ../mpd-0.23.12/src/player/Thread.cxx:1184
#16 0x000055ef5dcb4c21 in BoundMethod<void () noexcept>::operator()() const (this=<optimized out>, this=<optimized out>) at ../mpd-0.23.12/src/util/BindMethod.hxx:78
#17 Thread::Run() (this=<optimized out>) at ../mpd-0.23.12/src/thread/Thread.cxx:63
#18 Thread::ThreadProc(void*) (ctx=<optimized out>) at ../mpd-0.23.12/src/thread/Thread.cxx:92
#19 0x00007f15f4bb044b in start_thread (arg=<optimized out>) at pthread_create.c:444
#20 0x00007f15f4c33d64 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
Thread 4 (Thread 0x7f15e08346c0 (LWP 11653)):
#0 0x00007f15f4c34266 in epoll_wait (epfd=24, events=events@entry=0x7f15e0833120, maxevents=32, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1 0x00007f15fa15e779 in impl_pollfd_wait (object=<optimized out>, pfd=<optimized out>, ev=0x7f15e08332f0, n_ev=<optimized out>, timeout=<optimized out>) at ../pipewire/spa/plugins/support/system.c:137
#2 0x00007f15fa150213 in loop_iterate (object=0x7f15cc00b728, timeout=-1) at ../pipewire/spa/plugins/support/loop.c:409
#3 0x00007f15f73f84cf in do_loop (user_data=0x7f15cc009250) at ../pipewire/src/pipewire/data-loop.c:61
#4 0x00007f15f4bb044b in start_thread (arg=<optimized out>) at pthread_create.c:444
#5 0x00007f15f4c33d64 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
Thread 3 (Thread 0x7f15e19aa6c0 (LWP 696)):
#0 futex_wait (private=0, expected=2, futex_word=0x7f15cc000b98) at ../sysdeps/nptl/futex-internal.h:146
#1 __GI___lll_lock_wait (futex=futex@entry=0x7f15cc000b98, private=0) at lowlevellock.c:49
#2 0x00007f15f4bb391a in lll_mutex_lock_optimized (mutex=0x7f15cc000b98) at pthread_mutex_lock.c:48
#3 ___pthread_mutex_lock (mutex=mutex@entry=0x7f15cc000b98) at pthread_mutex_lock.c:128
#4 0x00007f15f743b863 in do_lock (this=this@entry=0x7f15cc000b70) at ../pipewire/src/pipewire/thread-loop.c:52
#5 0x00007f15f743bb4d in pw_thread_loop_lock (loop=0x7f15cc000b70) at ../pipewire/src/pipewire/thread-loop.c:362
#6 0x000055ef5dcf344e in PipeWire::ThreadLoopLock::ThreadLoopLock(pw_thread_loop*) (_loop=0x7f15cc000b70, this=<synthetic pointer>) at ../mpd-0.23.12/src/lib/pipewire/ThreadLoop.hxx:45
#7 PipeWireOutput::Play(void const*, unsigned long) (this=0x55ef5decc1d0, chunk=0x7f15e19ab048, size=4024) at ../mpd-0.23.12/src/output/plugins/PipeWireOutputPlugin.cxx:842
#8 0x000055ef5dce5f10 in FilteredAudioOutput::Play(void const*, unsigned long) (size=<optimized out>, data=<optimized out>, this=<optimized out>) at ../mpd-0.23.12/src/output/Filtered.cxx:179
#9 AudioOutputControl::PlayChunk(std::unique_lock<std::mutex>&) (lock=..., this=0x55ef5decc690) at ../mpd-0.23.12/src/output/Thread.cxx:268
#10 AudioOutputControl::InternalPlay(std::unique_lock<std::mutex>&) (lock=..., this=0x55ef5decc690) at ../mpd-0.23.12/src/output/Thread.cxx:323
#11 AudioOutputControl::Task() (this=0x55ef5decc690) at ../mpd-0.23.12/src/output/Thread.cxx:447
#12 BindMethodDetail::WrapperGenerator<void (AudioOutputControl::*)() noexcept, &AudioOutputControl::Task>::Invoke(void*) (_instance=0x55ef5decc690) at ../mpd-0.23.12/src/util/BindMethod.hxx:130
#13 0x000055ef5dcb4c21 in BoundMethod<void () noexcept>::operator()() const (this=<optimized out>, this=<optimized out>) at ../mpd-0.23.12/src/util/BindMethod.hxx:78
#14 Thread::Run() (this=<optimized out>) at ../mpd-0.23.12/src/thread/Thread.cxx:63
#15 Thread::ThreadProc(void*) (ctx=<optimized out>) at ../mpd-0.23.12/src/thread/Thread.cxx:92
#16 0x00007f15f4bb044b in start_thread (arg=<optimized out>) at pthread_create.c:444
#17 0x00007f15f4c33d64 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
Thread 2 (Thread 0x7f15e35ad6c0 (LWP 693)):
#0 0x00007f15f4c34266 in epoll_wait (epfd=8, events=0x7f15e35ac440, maxevents=16, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1 0x000055ef5dcb9fd0 in EpollFD::Wait(epoll_event*, int, int) (timeout=<optimized out>, maxevents=16, events=0x7f15e35ac440, this=0x7ffd09f485a8) at ../mpd-0.23.12/src/io/FileDescriptor.hxx:104
#2 EpollBackend::ReadEvents(int) (timeout_ms=<optimized out>, this=0x7ffd09f485a8) at ../mpd-0.23.12/src/event/EpollBackend.hxx:60
#3 EventLoop::Wait(std::chrono::duration<long, std::ratio<1l, 1000000000l> >) (timeout=Python Exception <class 'gdb.error'>: value has been optimized out
, this=0x7ffd09f47d18) at ../mpd-0.23.12/src/event/Loop.cxx:252
#4 EventLoop::Run() (this=0x7ffd09f47d18) at ../mpd-0.23.12/src/event/Loop.cxx:343
#5 0x000055ef5dcb4c21 in BoundMethod<void () noexcept>::operator()() const (this=<optimized out>, this=<optimized out>) at ../mpd-0.23.12/src/util/BindMethod.hxx:78
#6 Thread::Run() (this=<optimized out>) at ../mpd-0.23.12/src/thread/Thread.cxx:63
#7 Thread::ThreadProc(void*) (ctx=<optimized out>) at ../mpd-0.23.12/src/thread/Thread.cxx:92
#8 0x00007f15f4bb044b in start_thread (arg=<optimized out>) at pthread_create.c:444
#9 0x00007f15f4c33d64 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
Thread 1 (Thread 0x7f15e11a96c0 (LWP 697)):
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007f15f4bb22d3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007f15f4b62a08 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007f15f4b4b538 in __GI_abort () at abort.c:79
#4 0x00007f15e08f5adf in assert_single_pod (builder=<optimized out>) at ../pipewire/src/modules/module-protocol-native.c:1375
#5 assert_single_pod (builder=0x7f15cc071c70) at ../pipewire/src/modules/module-protocol-native.c:1368
#6 impl_ext_end_proxy (proxy=<optimized out>, builder=0x7f15cc071c70) at ../pipewire/src/modules/module-protocol-native.c:1385
#7 0x00007f15e08fa7f3 in core_event_demarshal_ping (data=<optimized out>, msg=<optimized out>) at ../pipewire/src/modules/module-protocol-native/protocol-native.c:348
#8 0x00007f15e08f2d6b in process_remote (impl=impl@entry=0x7f15cc08a6b0) at ../pipewire/src/modules/module-protocol-native.c:946
#9 0x00007f15e08f3410 in on_remote_data (data=0x7f15cc08a6b0, fd=28, mask=1) at ../pipewire/src/modules/module-protocol-native.c:980
#10 0x00007f15fa15035d in loop_iterate (object=<optimized out>, timeout=<optimized out>) at ../pipewire/spa/plugins/support/loop.c:439
#11 0x00007f15f743b9ba in do_loop (user_data=0x7f15cc000b70) at ../pipewire/src/pipewire/thread-loop.c:286
#12 0x00007f15f4bb044b in start_thread (arg=<optimized out>) at pthread_create.c:444
#13 0x00007f15f4c33d64 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
```
I'm also fairly certain that this crash never happened with PipeWire 0.3.69 (and older).
## How Reproducible:
0/5. I couldn't reproduce the crash anymore, even though I remember the exact steps I took:
1. Added two songs from the same album to the MPD queue using [Cantata](https://github.com/CDrummond/cantata/)
2. Tried to play the first song using Cantata (double-clicked on it)
3. Cantata disconnects because MPD crashed
### Steps to Reproduce:
N/A
### Actual Results:
libpipewire causes an assertion crashing MPD
### Expected Results:
No assertion/crash
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/9e3c41269a798922d5841138ec850ff6/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3231Prevent changing channel number (zero-indexing vs one-indexing)2023-12-10T12:49:12ZMark KnoopPrevent changing channel number (zero-indexing vs one-indexing)- PipeWire version (`pipewire --version`): 0.3.71
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Fedora Linux 38 (Workstation Edition)
- Desktop Environment: Sway
- Kernel version (`uname -r`): 6.2.15-300...- PipeWire version (`pipewire --version`): 0.3.71
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Fedora Linux 38 (Workstation Edition)
- Desktop Environment: Sway
- Kernel version (`uname -r`): 6.2.15-300.fc38.x86_64
## Description of Problem:
PipeWire re-numbers client ports to start at 1 even when the client numbers its own ports starting at 0. This is confusing, and doubly so when using with devices in "Pro Audio" profile, which numbers ports starting at AUX0.
It would be great if there were a way to turn this feature off or override it in some way.
## How Reproducible: 100%
### Steps to Reproduce:
1. Start a client which uses zero-indexed channels (e.g. SuperCollider)
2. Observe channel ports named out_1, out_2, etc...
### Actual Results
"info": {
"direction": "input",
"change-mask": [ "props", "params" ],
"props": {
"format.dsp": "32 bit float mono audio",
"node.id": 108,
"object.id": 110,
"object.path": "SuperCollider:input_0",
"object.serial": 122,
"port.alias": "SuperCollider:in_1",
"port.direction": "in",
"port.id": 0,
"port.name": "in_1"
},
### Expected Results:
"info": {
"direction": "input",
"change-mask": [ "props", "params" ],
"props": {
"format.dsp": "32 bit float mono audio",
"node.id": 108,
"object.id": 110,
"object.path": "SuperCollider:input_0",
"object.serial": 122,
"port.alias": "SuperCollider:in_0",
"port.direction": "in",
"port.id": 0,
"port.name": "in_0"
},
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/1ca50b4b387f7871bbd58d19533ddab6/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3230A way to combine several connected headsets2023-07-06T12:07:38ZpromeneurA way to combine several connected headsetsWith Bluetooth 5.2 there is a new feature.
We can connect several headsets according several persons can hear the song coming from VLC for example.
I get two headsets connected with bluetooth kde management, but pipewire only offers to ...With Bluetooth 5.2 there is a new feature.
We can connect several headsets according several persons can hear the song coming from VLC for example.
I get two headsets connected with bluetooth kde management, but pipewire only offers to select one headset at the same time.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3228[enhancement] displaying bluetooth codecs type for smartphone2023-05-21T18:01:14Zpromeneur[enhancement] displaying bluetooth codecs type for smartphoneHello
It would be a good thing to know what codec is in use when connecting a smartphone.Hello
It would be a good thing to know what codec is in use when connecting a smartphone.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3227bluetooth, no way to choose the codec2023-05-19T11:40:03Zpromeneurbluetooth, no way to choose the codecSamsung S7, android 8.0, bluetooth 4.2
OpenSUSE tumbleweed, pipewire 0.3.70, bluetooth 5.2
I play a video with VLC at my phone.
I hear well the sound at my PC.
There is nowhere a hamburger menu to select the codec as for example sbc, ...Samsung S7, android 8.0, bluetooth 4.2
OpenSUSE tumbleweed, pipewire 0.3.70, bluetooth 5.2
I play a video with VLC at my phone.
I hear well the sound at my PC.
There is nowhere a hamburger menu to select the codec as for example sbc, ldac, aptx.
In the past, there was a menu to select the codec.
See the capture
![no_codec_choice_1](/uploads/f33143edbbf504bf266f14b2cbb25847/no_codec_choice_1.png)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3226Setting PIPEWIRE_LATENCY lower than 1024 no longer works with Qemu Jack drive...2023-05-31T17:20:42Zaqxa1Setting PIPEWIRE_LATENCY lower than 1024 no longer works with Qemu Jack driver [regression]<!-- 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.71 (including master)
- Distribution and distribution version (`PRETTY_NAME` f...<!-- 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.71 (including master)
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Gentoo Linux
- Desktop Environment: Sway
- Kernel version (`uname -r`): 6.3.2-extra2+
## Description of Problem:
Setting a client specific quantum lower than 1024 with Qemu's Jack driver results in no sound and setting >=1024 results in crackling sound (tested up to 4096). With 0.3.70 or earlier I could use a 512 quantum with glitch-free audio.
## How Reproducible:
100% of the time when using Qemu 7.2.0 + libvirt 9.3.0 + Qemu jack driver with Windows and Linux guests.
### Steps to Reproduce:
1. Launch a VM configured to use Qemu's jack driver (https://looking-glass.io/wiki/Using_JACK_and_PipeWire)
2. Test audio in guest (e.g. run speaker test etc)
### Actual Results:
No audio with `PIPEWIRE_LATENCY=512/48000` or lower. Crackling audio with `PIPEWIRE_LATENCY=1024` or higher and when not configuring PIPEWIRE_LATENCY.
### Expected Results:
Mostly glitch free audio with `PIPEWIRE_LATENCY=512` or higher.
### Workaround:
Set global quantum with `pw-metadata -n settings 0 clock.force-quantum 512`. Must be set before VM is launched. Or revert to pipewire-0.3.70 or earlier.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw_dump.log](/uploads/2bcbb794b5632519fc417d4a0deb3743/pw_dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3225Turn off hw-volume feature on Audio Pro A262023-05-20T09:26:31ZGhost UserTurn off hw-volume feature on Audio Pro A26- 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)`
...- 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 --version`): `GNOME Shell 43.4`
- Kernel version (`uname -r`): `6.1.0-9-amd64`
- BlueZ version (`bluetoothctl --version`): `bluetoothctl: 5.66`
- `lsusb`: (appears irrelevant; two USB hubs and one multitouch interface)
- Bluetooth devices:
```
$ bluetoothctl devices
Device 7C:96:D2:XX:XX:XX Audio Pro_A26
```
## Description of Problem:
After pairing and device connection, volume can be adjusted and the hardware emits a 'blip' sound to demonstrate the updated volume level with each adjustment.
However, after the device is disconnected and reconnected (by disabling and re-enabling the 'bluetooth' option in GNOME, in this case), the volume output by the device is reset to 100% (potentially resulting in high-volume output if audio playback was in progress).
## How Reproducible:
Occurs reliably after every disconnect and reconnect.
### Steps to Reproduce:
1. Pair with the Audio Pro A26 using the GNOME control panel bluetooth settings area.
2. Connect to the device (this should occur automatically after pairing, and the device should be confirmed as an audio output).
3. Adjust the volume to below 100%.
4. Disconnect from the device (either by disabling bluetooth entirely, or by disconnecting from the individual device in the control panel -- either approach reproduces the problem).
5. Reconnect to the device.
### Actual Results:
Audio output volume for the device is reset to 100% (both as displayed within the GNOME desktop environment, and as the output level of the audio produced by the speakers).
### Expected Results:
The volume level selected during step three of the steps-to-reproduce should be restored, so that the audio output volume remains at the level chosen by the user previously.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:[pw-dump.log](/uploads/1b3762d0dbbcb9c498780e318d90a024/pw-dump.log)
- Bluetooth debug log: [pipewire-bluez.log](/uploads/5a672ed41d4a103e5639aed192829d25/pipewire-bluez.log)
### Patch
```
From 3d881074de2c034e424b9a5d0d9bddbdd29ea912 Mon Sep 17 00:00:00 2001
From: James Addison <jay@jp-hosting.net>
Date: Wed, 17 May 2023 22:53:15 +0100
Subject: [PATCH] Audio Pro A26: disable hw-volume feature, because volume was
being reset to 100% on each reconnect
---
spa/plugins/bluez5/bluez-hardware.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/spa/plugins/bluez5/bluez-hardware.conf b/spa/plugins/bluez5/bluez-hardware.conf
index 9004675ea..83b3212f0 100644
--- a/spa/plugins/bluez5/bluez-hardware.conf
+++ b/spa/plugins/bluez5/bluez-hardware.conf
@@ -30,6 +30,7 @@ bluez5.features.device = [
{ name = "Air 1 Plus", no-features = [ hw-volume-mic ] },
{ name = "AirPods", no-features = [ msbc-alt1, msbc-alt1-rtl ] },
{ name = "AirPods Pro", no-features = [ msbc-alt1, msbc-alt1-rtl ] },
+ { name = "Audio Pro_A26", address = "~^7c:96:d2:", no-features = [ hw-volume ]}, # doesn't remember volume
{ name = "AXLOIE Goin", no-features = [ msbc-alt1, msbc-alt1-rtl ] },
{ name = "BAA 100", no-features = [ hw-volume ] }, # Buxton BAA 100, doesn't remember volume, #pipewire-1449
{ name = "D50s", address = "~^00:13:ef:", no-features = [ hw-volume ] }, # volume has no effect, #pipewire-1562
--
2.39.2
```
Edit: add bluetooth debug log
Edit 2: add missing space (there should be two spaces before the comment marker)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3224dbusless libpipewire-module-rt fails in 0.3.712023-05-17T15:12:34ZJason A. Donenfelddbusless libpipewire-module-rt fails in 0.3.71I just updated from 0.3.68 to 0.3.71, to this unpleasant surprise on my system-wide daemon:
```
May 17 15:41:27 martino pipewire[21328]: mod.rt: regular realtime scheduling not available (Portal/RTKit fallback disabled)
May 17 15:41:27 ...I just updated from 0.3.68 to 0.3.71, to this unpleasant surprise on my system-wide daemon:
```
May 17 15:41:27 martino pipewire[21328]: mod.rt: regular realtime scheduling not available (Portal/RTKit fallback disabled)
May 17 15:41:27 martino pipewire[21328]: pw.conf: 0x55f11af4c810: could not load mandatory module "libpipewire-module-rt": Operation not supported
May 17 15:41:27 martino wireplumber[21329]: 0x55ad80728080: can't load dbus library: support/libspa-dbus
May 17 15:41:27 martino pipewire[21328]: default: failed to create context: Operation not supported
May 17 15:41:27 martino wireplumber[21329]: regular realtime scheduling not available (Portal/RTKit fallback disabled)
May 17 15:41:27 martino systemd[1]: pipewire.service: Main process exited, code=exited, status=161/n/a
May 17 15:41:27 martino systemd[1]: pipewire.service: Failed with result 'exit-code'.
```
My pipewire.conf is:
```
context.properties = {
support.dbus = false
core.daemon = true
core.name = pipewire-0
}
context.spa-libs = {
api.alsa.* = alsa/libspa-alsa
}
context.modules = [
{ name = libpipewire-module-rt
args = {
nice.level = -11
}
}
{ name = libpipewire-module-protocol-native }
{ name = libpipewire-module-profiler }
{ name = libpipewire-module-metadata }
{ name = libpipewire-module-client-node }
{ name = libpipewire-module-client-device }
{ name = libpipewire-module-access }
{ name = libpipewire-module-adapter }
{ name = libpipewire-module-link-factory }
{ name = libpipewire-module-protocol-pulse
args = {
server.address = [
{ address = "tcp:0.0.0.0:4713"
client.access = "unrestricted"
}
]
}
}
]
```
I had to remove the libpipewire-module-rt section for it to start.
The goal is a minimal system-wide pulseaudio tunnel server.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/32237.1 Virtual Surround Sink No Output.2023-05-17T19:43:10ZShaunTheQuietGamer7.1 Virtual Surround Sink No Output.Currently trying to get the `sink-virtual-surround-7.1-hesuvi.conf` example config working. Got it to the point where the sink exists, but when i send audio through it, there's no output and the following pops up in `systemctl --user sta...Currently trying to get the `sink-virtual-surround-7.1-hesuvi.conf` example config working. Got it to the point where the sink exists, but when i send audio through it, there's no output and the following pops up in `systemctl --user status pipewire`.
```
May 16 12:20:49 natrix pipewire[8736]: mod.client-node: 0x558d3c472440: error seq:1527 -2 (can't start graph: No such file or directory)
May 16 12:20:49 natrix pipewire[8736]: pw.core: 0x558d3c2f19a0: error -5 for resource 2: start failed
May 16 12:20:49 natrix pipewire[8736]: mod.client-node: 0x558d3c472440: error seq:1527 -5 (start failed)
May 16 12:20:53 natrix pipewire[8736]: mod.filter-chain: cannot create plugin instance: No such file or directory
May 16 12:20:53 natrix pipewire[8736]: pw.node: (effect_input.virtual-surround-7.1-hesuvi-0) start node error -5: Input/output error
May 16 12:20:53 natrix pipewire[8736]: mod.client-node: node 0x558d3c3ae720: start failed
May 16 12:20:53 natrix pipewire[8736]: pw.core: 0x558d3c2f19a0: error -2 for resource 2: can't start graph: No such file or directory
May 16 12:20:53 natrix pipewire[8736]: mod.client-node: 0x558d3c472440: error seq:1538 -2 (can't start graph: No such file or directory)
May 16 12:20:53 natrix pipewire[8736]: pw.core: 0x558d3c2f19a0: error -5 for resource 2: start failed
May 16 12:20:53 natrix pipewire[8736]: mod.client-node: 0x558d3c472440: error seq:1538 -5 (start failed)
```
`PIPEWIRE_DEBUG=3 pipewire -c filter-chain.conf 2> log.txt` is [attached](/uploads/b543f99e19b087d8efb03360a10a5fc0/log.txt).https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3221pipewire-pulse often hangs as another device wakes up from sleep when using n...2023-11-30T09:42:57ZJulespipewire-pulse often hangs as another device wakes up from sleep when using native-protocol-tcp and zeroconf-{publish,discover} on both devices- PipeWire version (`pipewire --version`): 3.70.0
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: i3wm
- Kernel version (`uname -r`): `6.3.1-zen2-1-zen`
## Description of...- PipeWire version (`pipewire --version`): 3.70.0
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: i3wm
- Kernel version (`uname -r`): `6.3.1-zen2-1-zen`
## Description of Problem:
When using the following configuration on two devices on the same LAN:
```
context.exec = [
{ path = "pactl" args = "load-module module-native-protocol-tcp" }
{ path = "pactl" args = "load-module module-zeroconf-publish" }
{ path = "pactl" args = "load-module module-zeroconf-discover" }
]
```
pipewire-pulse might hang as another device wakes up after being suspended. This causes all the programs that use PulseAudio (like Firefox, pavucontrol-qt, pactl...) to hang too as a consequence.
## How Reproducible:
### Steps to Reproduce:
1. Apply following config to two devices on the same LAN:
```
context.exec = [
{ path = "pactl" args = "load-module module-native-protocol-tcp" }
{ path = "pactl" args = "load-module module-zeroconf-publish" }
{ path = "pactl" args = "load-module module-zeroconf-discover" }
]
```
2. Suspend one of the devices, and turn it back on
### Actual Results:
After a few seconds pipewire-pulse might hang on the device that wasn't suspended, and programs that use PulseAudio will hang too until they supposedly timeout. After a bit of time (1~5 minutes) things might get back in order.
### Expected Results:
No hang.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3220Output of a Virtual Sink won't make any audio plugin go out of suspend.2023-05-24T09:24:00ZAndrej Halvelandandrej.halv@gmail.comOutput of a Virtual Sink won't make any audio plugin go out of suspend.<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version: master 26e9a4ce1333b371a548f09e098e6c69a757e8ef
- Distribution and distribution version (`PRETTY_NAME` from...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version: master 26e9a4ce1333b371a548f09e098e6c69a757e8ef
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: KDE Plasma 5.27.5 (Wayland)
- Kernel version (`uname -r`): 6.3.1-arch2-1
## Description of Problem:
After commit https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/9664787cffb3eec096b257f52f7420afc6e381f6 the output of a Virtual Sink won't make any plugin connected to the output of the Virtual Sink go out of suspend.
I also made some observations since https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3100#note_1864217
1. Bypassing the Virtual Sink by sending the audio signal from Spotify straight to the audio plugin (that's right after the Virtual Sink) makes everything work again, and also makes the sound card suspend if nothing is playing.
2. Bypassing the plugins by connecting the output of the Virtual Sink straight to the Sound Card makes audio work again, but the sound card will never suspend.
## How Reproducible:
Always
### Steps to Reproduce:
1. Create a Virtual Sink using `pactl load-module module-null-sink media.class=Audio/Sink sink_name="Carla" channel_map=stereo`
2. Start Carla with `PIPEWIRE_PROPS='{ node.passive=true node.always-process=false }' carla-jack-multi`
3. Add some kind of LSP Plugin (havent tried anything else) and connect it between a the Virtual Sink and your sound card
4. Play any audio to the Virtual Sink
### Actual Results:
No audio output. Plugins stay suspended.
### Expected Results:
Audio should start playing, and if nothing plays the sound card should enter suspend.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/73e94b99b953af1b85f9959b06d7b26b/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3219Streaming over network is choppy while the screen is recorded on Gnome2023-09-22T13:46:32ZStrangiatoStreaming over network is choppy while the screen is recorded on GnomeHi
I use Pipewire to redirect the audio output of my laptop to the speakers connected to my desktop computer over network.
If I record the laptop screen with the native recorder of Gnome (we can trigger it by pressing the printscreen k...Hi
I use Pipewire to redirect the audio output of my laptop to the speakers connected to my desktop computer over network.
If I record the laptop screen with the native recorder of Gnome (we can trigger it by pressing the printscreen key) while my laptop streams audio, the audio becomes extremely choppy. The audio becomes choppy regardless the laptop streams it with ROC or native-protocol-tcp modules. journal and dmesg logs do not print any suspicious message
while the audio is choppy. I'm not sure if this problem is a pipewire issue because it does not occur if I record the screen with OBS Studio 29.0.2-5. I'm reporting because I prefer the simplier screen recorder of Gnome.
laptop: Arch Linux, Gnome 44.1, pipewire 1:0.3.70-2
desktop: Arch Linux, KDE Plasma 5.27.5, pipewire 1:0.3.70-2