pipewire issueshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues2024-01-12T12:09:31Zhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3777Remove gh-pages branch2024-01-12T12:09:31ZP VRemove gh-pages branchThe gh-pages branch in the repository causes this site to appear: https://pipewire.github.io/pipewire/
It's very outdated and probably should be removed. It might also need to be manually removed on Github side https://github.com/PipeWir...The gh-pages branch in the repository causes this site to appear: https://pipewire.github.io/pipewire/
It's very outdated and probably should be removed. It might also need to be manually removed on Github side https://github.com/PipeWire/pipewire, not sure how the mirroring there works.
There are also other obsolete branches in the main repository
https://gitlab.freedesktop.org/pipewire/pipewire/-/branches/stalehttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3776OOM in `properties.c` not properly handled2024-01-10T17:22:34ZDemi Marie Obenourdemiobenour@gmail.comOOM in `properties.c` not properly handledIf the `pw_array_add()` call in `properties.c:add_func()` fails, the resulting error is not propogated to the callers. Furthermore, most callers are not prepared to handle a call to `pw_properties_*` failing.If the `pw_array_add()` call in `properties.c:add_func()` fails, the resulting error is not propogated to the callers. Furthermore, most callers are not prepared to handle a call to `pw_properties_*` failing.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3775[Q] Combining multiple sinks as default using pw-cmds2024-01-09T08:36:09Zcarlchenzekun[Q] Combining multiple sinks as default using pw-cmdsI am trying to setup multiple Le-ISOC (BAP) streams to different sinks.
Previously with pipewire-pulse I was able to use pactl load-module module-combine-sink sink_name=combined sink_properties=device.description=CombinedSink slaves="blu...I am trying to setup multiple Le-ISOC (BAP) streams to different sinks.
Previously with pipewire-pulse I was able to use pactl load-module module-combine-sink sink_name=combined sink_properties=device.description=CombinedSink slaves="bluez_output.CISlink1,bluez_output.CISlink2"
Now I am seeking any pw- commands which is equivalent to above commands to combine sinks seen by wpctl status.
Thanks,https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3774alsa-plugin: status timestamps a lot more imprecise than raw alsa2024-01-09T09:13:17ZZeno Endemannalsa-plugin: status timestamps a lot more imprecise than raw alsa- PipeWire version (`pipewire --version`): 1.0.0
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: KDE
- Kernel version (`uname -r`): 6.6.9-arch1-1
## Description of Proble...- PipeWire version (`pipewire --version`): 1.0.0
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: KDE
- Kernel version (`uname -r`): 6.6.9-arch1-1
## Description of Problem:
I am writing a fairly advanced alsa application that does not use the poll descriptors, but rather timeouts for scheduling. For that I enable timestamps (type `SND_PCM_TSTAMP_TYPE_MONOTONIC`) and rely on that the timing info I get via `snd_pcm_status_get_htstamp(status)` reasonably approximates the time point of the current stream position indicated by `snd_pcm_status_get_avail(status)`. When using my soundcard directly this works very well, but when going through the pipewire alsa-plugin, the precision drops very significantly (I have to increase the 'slack margins' quite a bit). I have also seen that sometimes I get a status where the timestamp value increased without the avail value increasing, which afaiu shouldn't happen and seems to indicate that there is a bug or misunderstanding about that timestamp.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3773Insane log levels (1000s per second) since recent changes in master - PEBKAC ...2024-01-08T17:00:03ZpallasweptInsane log levels (1000s per second) since recent changes in master - PEBKAC alert ;)Just a heads up for you devs in case this generates support issues - because I almost logged one until I figured it out just before I sent it.
As you're aware, there were a handful of changes to logging in recent commits. Previous confi...Just a heads up for you devs in case this generates support issues - because I almost logged one until I figured it out just before I sent it.
As you're aware, there were a handful of changes to logging in recent commits. Previous config files had a setting in them which set log.level to 3. But they either weren't working, and the commits fixed that, or level 3 increased greatly in verbosity with the commits. I had a minor issue today and went I went to check /var/log/messages, I couldn't open the log, it crashed the log viewer, because my last few messages files had swollen to be gigabytes in size, which I found to be courtesy of pipewire issuing literally thousands of messages per second.
I tracked it down to that property being set, thus avoiding logging a support issue I thought might be a bug - but since an existing config file and new pipewire = crashing PC from giant logs, this might rear its head again with other users. Thought I'd mention it and hopefully save you some time trying to troubleshoot, if you hear of similar symptoms in the near future as others try the new code.
Hope this helps :)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3772`pw_stream_trigger_process()` does not cause `.process` callback to be called2024-01-08T11:02:12ZDemi Marie Obenourdemiobenour@gmail.com`pw_stream_trigger_process()` does not cause `.process` callback to be calledI have a custom PipeWire audio sink that drives the graph via `pw_stream_trigger_process()`. Occasionally the `.process` callback does not get called and the graph hangs.
How can I determine the cause of this problem? Does PipeWire gu...I have a custom PipeWire audio sink that drives the graph via `pw_stream_trigger_process()`. Occasionally the `.process` callback does not get called and the graph hangs.
How can I determine the cause of this problem? Does PipeWire guarantee that each call to `pw_stream_trigger_process()` will result in at least one call to `.process`, or do I need to code my stream to handle no calls to `.process` being made until `pw_stream_trigger_process()` runs again? Or do I need to switch to a SPA plugin?https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3771Error: "failed to connect: Host is down"2024-01-09T08:54:07Zwan inkerError: "failed to connect: Host is down"Using pipewire 0.3.83 on ubuntu 23.10.
when i running the command which is "sudo pw-cli ls Node",Prompt this "Error: "failed to connect: Host is down".
I confirmed that pipewire, pipewire-pulse and wireplumber processes all exist. I do...Using pipewire 0.3.83 on ubuntu 23.10.
when i running the command which is "sudo pw-cli ls Node",Prompt this "Error: "failed to connect: Host is down".
I confirmed that pipewire, pipewire-pulse and wireplumber processes all exist. I don't know why it prompts "host is down"![捕获](/uploads/91e89ceadeb7e75dd75cb4d53038f4aa/捕获.PNG)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3770spa.audioadapter: 0x557539c461c8: scheduling stopped node2024-01-08T11:03:13Zmarin3rospa.audioadapter: 0x557539c461c8: scheduling stopped nodeI don't really know what this even is.
I have an Arch linux install made with archinstall script and I chosed pipewire as the audio server. I have sound with the usb soundcard which is a M Audio Mobile Pre. I installed Carla to try and ...I don't really know what this even is.
I have an Arch linux install made with archinstall script and I chosed pipewire as the audio server. I have sound with the usb soundcard which is a M Audio Mobile Pre. I installed Carla to try and use Ardour and Guitarix which I installed from the Arch Repository and as soon as I installed Carla the system would not even recognize the soundcard so I rollback to a snapshot I had of my system prior to installing Carla and while I have sound back, journalctl gives me that message back.
This is the first time I come here and my first post also so I don't really know what other information need be posted. Sometimes when I press play on youtube using firefox I get this nasty static noise.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3769pipewire crashes out of the blue2024-01-08T11:41:30ZK kpipewire crashes out of the bluePipewire crashes after several days. Says "Process (2032) pipewire crashed in impl_node_process()"
I have all the trace details if that's needed. Reason says "pipewire killed by SIGSEGV". User logs: spa.audioadapter: 0xblah: scheduling s...Pipewire crashes after several days. Says "Process (2032) pipewire crashed in impl_node_process()"
I have all the trace details if that's needed. Reason says "pipewire killed by SIGSEGV". User logs: spa.audioadapter: 0xblah: scheduling stopped node.
This is core backtrace:
```
{ "signal": 11
, "executable": "/usr/bin/pipewire"
, "stacktrace":
[ { "crash_thread": true
, "frames":
[ { "address": 140412193283510
, "build_id": "4990ac3bb799eea43248d87cea1dff619a486a5d"
, "build_id_offset": 241078
, "function_name": "impl_node_process"
, "file_name": "/usr/lib64/spa-0.2/audioconvert/libspa-audioconvert.so"
}
, { "address": 140412193176807
, "build_id": "4990ac3bb799eea43248d87cea1dff619a486a5d"
, "build_id_offset": 134375
, "function_name": "impl_node_process"
, "file_name": "/usr/lib64/spa-0.2/audioconvert/libspa-audioconvert.so"
}
, { "address": 140412520146191
, "build_id": "8711c7c087eea6882aa6b97c5eb3afda1dfb4882"
, "build_id_offset": 423183
, "function_name": "node_on_fd_events.lto_priv.0"
, "file_name": "/lib64/libpipewire-0.3.so.0"
}
, { "address": 140412517490454
, "build_id": "c39424a68dfe4b84c284e94d9d6a1fb7a8ff0c71"
, "build_id_offset": 36630
, "function_name": "loop_iterate"
, "file_name": "/usr/lib64/spa-0.2/support/libspa-support.so"
}
, { "address": 140412520022355
, "build_id": "8711c7c087eea6882aa6b97c5eb3afda1dfb4882"
, "build_id_offset": 299347
, "function_name": "do_loop"
, "file_name": "/lib64/libpipewire-0.3.so.0"
}
, { "address": 140412518332567
, "build_id": "788cdd41a15985bf8e0a48d213a46e07d58822df"
, "build_id_offset": 583831
, "function_name": "start_thread"
, "file_name": "/lib64/libc.so.6"
}
, { "address": 140412518884708
, "build_id": "788cdd41a15985bf8e0a48d213a46e07d58822df"
, "build_id_offset": 1135972
, "function_name": "__clone"
, "file_name": "/lib64/libc.so.6"
} ]
}
, { "frames":
[ { "address": 140412518894171
, "build_id": "788cdd41a15985bf8e0a48d213a46e07d58822df"
, "build_id_offset": 1145435
, "function_name": "sendmsg"
, "file_name": "/lib64/libc.so.6"
}
, { "address": 140412280747094
, "build_id": "c2f363d8bb732e7be41d72b10fd45aaa50dbeaee"
, "build_id_offset": 189526
, "function_name": "pw_protocol_native_connection_flush"
, "file_name": "/usr/lib64/pipewire-0.3/libpipewire-module-protocol-native.so"
}
, { "address": 140412280644088
, "build_id": "c2f363d8bb732e7be41d72b10fd45aaa50dbeaee"
, "build_id_offset": 86520
, "function_name": "connection_data"
, "file_name": "/usr/lib64/pipewire-0.3/libpipewire-module-protocol-native.so"
}
, { "address": 140412517490454
, "build_id": "c39424a68dfe4b84c284e94d9d6a1fb7a8ff0c71"
, "build_id_offset": 36630
, "function_name": "loop_iterate"
, "file_name": "/usr/lib64/spa-0.2/support/libspa-support.so"
}
, { "address": 140412520148923
, "build_id": "8711c7c087eea6882aa6b97c5eb3afda1dfb4882"
, "build_id_offset": 425915
, "function_name": "pw_main_loop_run"
, "file_name": "/lib64/libpipewire-0.3.so.0"
}
, { "address": 94503498831366
, "build_id": "891d629280bc34704f6b9888082d281a8445a157"
, "build_id_offset": 5638
, "function_name": "main"
, "file_name": "/usr/bin/pipewire"
}
, { "address": 140412517912906
, "build_id": "788cdd41a15985bf8e0a48d213a46e07d58822df"
, "build_id_offset": 164170
, "function_name": "__libc_start_call_main"
, "file_name": "/lib64/libc.so.6"
}
, { "address": 140412517913099
, "build_id": "788cdd41a15985bf8e0a48d213a46e07d58822df"
, "build_id_offset": 164363
, "function_name": "__libc_start_main@@GLIBC_2.34"
, "file_name": "/lib64/libc.so.6"
}
, { "address": 94503498831781
, "build_id": "891d629280bc34704f6b9888082d281a8445a157"
, "build_id_offset": 6053
, "function_name": "_start"
, "file_name": "/usr/bin/pipewire"
} ]
}
, { "frames":
[ { "address": 140412518886146
, "build_id": "788cdd41a15985bf8e0a48d213a46e07d58822df"
, "build_id_offset": 1137410
, "function_name": "epoll_wait"
, "file_name": "/lib64/libc.so.6"
}
, { "address": 140412517546872
, "build_id": "c39424a68dfe4b84c284e94d9d6a1fb7a8ff0c71"
, "build_id_offset": 93048
, "function_name": "impl_pollfd_wait"
, "file_name": "/usr/lib64/spa-0.2/support/libspa-support.so"
}
, { "address": 140412517490265
, "build_id": "c39424a68dfe4b84c284e94d9d6a1fb7a8ff0c71"
, "build_id_offset": 36441
, "function_name": "loop_iterate"
, "file_name": "/usr/lib64/spa-0.2/support/libspa-support.so"
}
, { "address": 140412520332759
, "build_id": "8711c7c087eea6882aa6b97c5eb3afda1dfb4882"
, "build_id_offset": 609751
, "function_name": "do_loop"
, "file_name": "/lib64/libpipewire-0.3.so.0"
}
, { "address": 140412518332567
, "build_id": "788cdd41a15985bf8e0a48d213a46e07d58822df"
, "build_id_offset": 583831
, "function_name": "start_thread"
, "file_name": "/lib64/libc.so.6"
}
, { "address": 140412518884708
, "build_id": "788cdd41a15985bf8e0a48d213a46e07d58822df"
, "build_id_offset": 1135972
, "function_name": "__clone"
, "file_name": "/lib64/libc.so.6"
} ]
} ]
}
```https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3768Data loop realtime kernel2024-01-14T15:05:09ZBryan SotemData loop realtime kernelHello,
The documentation for the pipewire.conf file configuration states https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire:
"The name of the shared library to use for the system functions for the data processing t...Hello,
The documentation for the pipewire.conf file configuration states https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire:
"The name of the shared library to use for the system functions for the data processing thread. This can typically be changed if the data thread is running on a realtime kernel such as EVL."
For the following option.
`context.data-loop.library.name.system = support/libspa-support`
I've installed a realtime kernel, but I have no clue about which value I should use instead of the default one.
I've tried finding, and couldn't find it anywhere.
What value should I put here, or where could one refer to to see possible values?
Thanks in advance!https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3767`trigger_done` callback does not get called sometimes2024-01-08T11:28:15ZDemi Marie Obenourdemiobenour@gmail.com`trigger_done` callback does not get called sometimes<!-- 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.0
- 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`): 1.0.0
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): `Fedora Linux 38 (Thirty Eight)`
- Desktop Environment: Qubes OS
- Kernel version (`uname -r`): `6.1.62-1.qubes.fc37.x86_64`
## Description of Problem:
The `trigger_done` callback does not always get called, especially if a client exits abnormally.
## How Reproducible:
Usually reproduces within 5 or less attempts.
### Steps to Reproduce:
1. Write a custom audio sink drives the graph, and which depends on `trigger_done` being called before it will trigger the graph again.
2. Run `while pw-play /usr/share/sounds/alsa/Front_Right.wav; do :; done`.
3. Press Ctrl-C.
4. Go back to step 2.
Eventually audio will stop playing. Logging reveals that `.trigger_done` is never called.
The only in-tree uses of `.trigger_done` appear to be two video examples and a test that `offsetof(struct pw_stream_events, trigger_done)` is correct. I suspect this is why nobody has found this bug before. However, the code I am currently working requires that `.trigger_done` be called — if it isn’t, the graph deadlocks.
The problem seems to only reproduce if the module is loaded _outside_ of the PipeWire Daemon. ~~If it is loaded in the PipeWire daemon, the bug doesn’t trigger.~~ The bug still triggers with `PIPEWIRE_DEBUG=E,mod.qubes-audio:T`, where `mod.qubes-audio` is the module I am working on. Since it is impacted by logging levels I suspect it is highly sensitive to timing.
### Actual Results:
`.trigger_done` is not called all of the time.
### Expected Results:
`.trigger_done` is always called, even if a client unexpectedly terminates.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3766Pipewire webrtc echo cancellation not working2024-01-09T08:54:58Zali vatankhahPipewire webrtc echo cancellation not workingHello, I am a newbie to pipewire. I'm writing a pipewire node (using pipewire version 1.0.0) to play a sound and record from microphone simultaneously, the audio spec is 8kHz sampling rate, 1 channel and `SPA_AUDIO_FORMAT_S16` format. th...Hello, I am a newbie to pipewire. I'm writing a pipewire node (using pipewire version 1.0.0) to play a sound and record from microphone simultaneously, the audio spec is 8kHz sampling rate, 1 channel and `SPA_AUDIO_FORMAT_S16` format. the app works and can play/record sound as well. the problem is where I enable `libpipewire-module-echo-cancel` and configure it to remove acoustic echo using webrtc as no sound is heard or recorded. I also changed the app to connect with `Echo Cancellation Sink` and `Echo Cancellation Source` nodes. the pipewire graph seems to be ok:
![pw](/uploads/cb147a8d60d67407ffe8735ce04d99d7/pw.png)
the output of pw-top: (there are errors in `Echo Cancellation Source` and `Echo Cancellation Playback` increasing with time)
```
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
R 48 2048 48000 6.5ms 10.5us 0.15 0.00 0 S32LE 2 48000 alsa_input.platform-sound.stereo-fallback
R 32 1680 8000 178.4us 136.3us 0.00 0.00 0 F32P 2 48000 + Echo Cancellation Capture
R 33 1680 8000 339.5us 27.0us 0.01 0.00 689 F32P 2 48000 + Echo Cancellation Source
R 34 1680 8000 134.6us 128.2us 0.00 0.00 0 F32P 2 48000 + Echo Cancellation Sink
R 35 1680 8000 429.4us 19.9us 0.01 0.00 689 F32P 2 48000 + Echo Cancellation Playback
R 47 0 0 43.0us 1.1ms 0.00 0.02 0 S32LE 2 48000 + alsa_output.platform-sound.stereo-fallback
R 67 0 0 1.3ms 1.2ms 0.03 0.03 1 S16LE 1 8000 + myapp
R 68 0 0 3.2ms 2.8ms 0.08 0.07 1 S16LE 1 8000 + myapp
```
pw-link -l :
```
Echo Cancellation Capture:input_FL
|<- alsa_input.platform-sound.stereo-fallback:capture_FL
Echo Cancellation Capture:input_FR
|<- alsa_input.platform-sound.stereo-fallback:capture_FR
Echo Cancellation Source:capture_FL
|-> myapp:input_FL
Echo Cancellation Source:capture_FR
|-> myapp:input_FR
Echo Cancellation Sink:playback_FL
|<- myapp:output_FL
Echo Cancellation Sink:playback_FR
|<- myapp:output_FR
Echo Cancellation Playback:output_FL
|-> alsa_output.platform-sound.stereo-fallback:playback_FL
Echo Cancellation Playback:output_FR
|-> alsa_output.platform-sound.stereo-fallback:playback_FR
alsa_output.platform-sound.stereo-fallback:playback_FL
|<- Echo Cancellation Playback:output_FL
alsa_output.platform-sound.stereo-fallback:playback_FR
|<- Echo Cancellation Playback:output_FR
alsa_input.platform-sound.stereo-fallback:capture_FL
|-> Echo Cancellation Capture:input_FL
alsa_input.platform-sound.stereo-fallback:capture_FR
|-> Echo Cancellation Capture:input_FR
myapp:input_FL
|<- Echo Cancellation Source:capture_FL
myapp:input_FR
|<- Echo Cancellation Source:capture_FR
myapp:output_FL
|-> Echo Cancellation Sink:playback_FL
myapp:output_FR
|-> Echo Cancellation Sink:playback_FR
```
the related configuration of pipewire:
```
{ name = libpipewire-module-echo-cancel
args = {
library.name = aec/libspa-aec-webrtc
node.latency = 1700/8000
# monitor.mode = false
capture.props = {
node.name = "Echo Cancellation Capture"
#audio.channels = 1
node.passive = true
target.object = "alsa_input.platform-sound.stereo-fallback"
}
source.props = {
node.name = "Echo Cancellation Source"
#audio.channels = 1
}
sink.props = {
node.name = "Echo Cancellation Sink"
#audio.channels = 1
}
playback.props = {
node.name = "Echo Cancellation Playback"
#audio.channels = 1
node.passive = true
target.object = "alsa_output.platform-sound.stereo-fallback"
}
}
}
```
I doubt to 8kHz sampling rate as aec3 seems not working with it, so changed to use aecm (`aec.args = {mobile = 1}`) but still not working.
another question is why the count of channels are shown 2 in all graphs and command outputs while the sound is mono channel and the app is written to work with mono channel as you can see:
```
params_play[0] = spa_format_audio_raw_build(&b_play, SPA_PARAM_EnumFormat,
&SPA_AUDIO_INFO_RAW_INIT(
.format = SPA_AUDIO_FORMAT_S16,
.channels = 1,
.rate = 8000 ));
```
I remind that the app worked before enabling echo cancellation but after enabling that, no sound is heard or recorded. can anyone help me to solve this problem? thanks.
note: I built pipewire for a embedded board with Yocto.
I also asked this question [here](https://stackoverflow.com/questions/77764650/pipewire-webrtc-echo-cancellation-not-working) in the case if here is irrelevant to ask for my problem.
[pw.dump](/uploads/b80823454c062792cc5af20aaf112f54/pw.dump)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3765Audio Distortion in Wine applications when no other sound is playing2024-01-08T09:37:09ZTomás PinhoAudio Distortion in Wine applications when no other sound is playing<!-- 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 1.0.0
Linked with libpipewire 1.0.0
```
- Di...<!-- 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 1.0.0
Linked with libpipewire 1.0.0
```
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
Manjaro Linux, fully updated
- Desktop Environment:
```
GNOME 45.2 (Wayland)
```
- Kernel version (`uname -r`):
```
6.6.8-2-MANJARO
```
## Description of Problem:
When a Windows application (all games I've tested, in this case Overwatch) is started through Wine (or Proton) and starts outputting audio by itself, the audio is extremely digitally distorted to the point of being unrecognizable from the original.
Interestingly, when the same application is started while another native application (browser playing a video) is already outputting audio, the audio suffers no distortion and keeps playing as normal, even after the originally audio playing application quits.
## How Reproducible:
Happens 100% of the time for me.
### Steps to Reproduce:
1. Use Steam to run a Windows game through Proton (Overwatch, Cyberpunk 2077, etc). I've tried Proton 8.0 and Experimental, both have the same issue. The same goes for applications ran through Bottle (Wine Staging).
### Actual Results:
Audio comes out digitally distorted.
### Expected Results:
Audio should suffer no distortion.
# Additional Info (as attachments):
`pw-top` screenshots
Playing alone:
![Screenshot_from_2024-01-05_16-12-22](/uploads/da456f6234a2da31e9f58c2fe8b5b183/Screenshot_from_2024-01-05_16-12-22.png)
Mixing with video playing in browser:
![Screenshot_from_2024-01-05_16-13-34](/uploads/25da6bc484275df50bff1ef5e3e5bd89/Screenshot_from_2024-01-05_16-13-34.png)
`pw-dump > pw-dump.log` while audio is distorting:
[pw-dump.log](/uploads/72759c5a4b47ed1aeb495dc7a5ed188d/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3764Audio device disappear from the list when using slack/teams/google chrome aud...2024-01-04T20:51:36ZBertrand ProvostAudio device disappear from the list when using slack/teams/google chrome audio (bad argument #1 to 'find')- PipeWire version (`pipewire --version`):
```plaintext
pipewire
Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48
```
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): `Ubuntu 22.04.3 LTS`
-...- PipeWire version (`pipewire --version`):
```plaintext
pipewire
Compiled with libpipewire 0.3.48
Linked with libpipewire 0.3.48
```
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): `Ubuntu 22.04.3 LTS`
- Desktop Environment: Awesome WM
- Kernel version (`uname -r`): `6.2.0-39-generic`
- BlueZ version (`bluetoothctl --version`): `bluetoothctl: 5.64`
- `lsusb`:
```plaintext
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 005 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 003 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 010: ID 0e8d:0616 MediaTek Inc. Wireless_Device
Bus 001 Device 004: ID 0db0:7696 Micro Star International USB Audio
Bus 001 Device 008: ID 046d:081b Logitech, Inc. Webcam C310
Bus 001 Device 013: ID 09eb:0131 IM Networks, Inc. Virtual HID
Bus 001 Device 011: ID 2f68:0042 Hoksi Technology DURGOD Taurus K310
Bus 001 Device 009: ID 09ea:0130 Generic Virtual HUB
Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 006: ID 17a0:0002 Samson Technologies Corp. Q1U dynamic microphone
Bus 001 Device 003: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hub
Bus 001 Device 002: ID 0bda:8771 Realtek Semiconductor Corp. Bluetooth Radio
Bus 001 Device 014: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 012: ID 1462:7d76 Micro Star International MYSTIC LIGHT
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```
- Bluetooth devices:
```plaintext
Device 60:AB:D2:3F:DD:BD Bose QC35 II
```
## Description of Problem:
When starting a call on slack, teams or when trying on the web version of those 2 the bluetooth device disappear from the list of the available devices. (No problem with discord)
## How Reproducible:
### Steps to Reproduce:
1.Go to the `Audio & Video` tab in Slack setting or do a test call on Teams.
### Actual Results:
The device disapear and the sound is redirected to Dummy Output
### Expected Results:
Sound should stay on the device
# Additional Info (as attachments):
It was working well before yesterday
In syslog I can those logs when I start a call
```plaintext
Jan 4 10:53:26 esula wireplumber[4866]: [string "policy-bluetooth.lua"]:121: bad argument #1 to 'find' (string expected, got nil)#012stack traceback:#012#011[C]: in function 'string.find'#012#011[string "policy-bluetooth.lua"]:121: in upvalue 'isBluez5AudioSink'#012#011[string "policy-bluetooth.lua"]:389: in function <[string "policy-bluetooth.lua"]:387>
Jan 4 10:53:26 esula wireplumber[4866]: [string "policy-bluetooth.lua"]:121: bad argument #1 to 'find' (string expected, got nil)#012stack traceback:#012#011[C]: in function 'string.find'#012#011[string "policy-bluetooth.lua"]:121: in function <[string "policy-bluetooth.lua"]:120>#012#011(...tail calls...)#012#011[string "policy-bluetooth.lua"]:326: in upvalue 'checkStreamStatus'#012#011[string "policy-bluetooth.lua"]:345: in function <[string "policy-bluetooth.lua"]:340>
Jan 4 10:53:26 esula wireplumber[4866]: [string "policy-bluetooth.lua"]:121: bad argument #1 to 'find' (string expected, got nil)#012stack traceback:#012#011[C]: in function 'string.find'#012#011[string "policy-bluetooth.lua"]:121: in function <[string "policy-bluetooth.lua"]:120>#012#011(...tail calls...)#012#011[string "policy-bluetooth.lua"]:326: in upvalue 'checkStreamStatus'#012#011[string "policy-bluetooth.lua"]:345: in function <[string "policy-bluetooth.lua"]:340>
Jan 4 10:53:26 esula wireplumber[4866]: [string "policy-bluetooth.lua"]:121: bad argument #1 to 'find' (string expected, got nil)#012stack traceback:#012#011[C]: in function 'string.find'#012#011[string "policy-bluetooth.lua"]:121: in function <[string "policy-bluetooth.lua"]:120>#012#011(...tail calls...)#012#011[string "policy-bluetooth.lua"]:326: in upvalue 'checkStreamStatus'#012#011[string "policy-bluetooth.lua"]:345: in upvalue 'handleStream'#012#011[string "policy-bluetooth.lua"]:366: in function <[string "policy-bluetooth.lua"]:365>
```
- `pw-dump > pw-dump.log`:[pw-dump.log](/uploads/6ddfa51d20473586cebc840b783c2552/pw-dump.log)
![Bugslack](/uploads/d4009e31589162a044a9ee4c91d57362/Bugslack.gif)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3763docs: unable to resolve reference to spa_video_multiview_meta and SPA_VIDEO_B...2024-01-05T09:08:17ZBarnabás Pőczedocs: unable to resolve reference to spa_video_multiview_meta and SPA_VIDEO_BUFFER_FLAG_MULTIPLE_VIEW```
/pipewire/spa/include/spa/param/video/multiview.h:72: warning: unable to resolve reference to 'spa_video_multiview_meta' for \ref command
/pipewire/spa/include/spa/param/video/multiview.h:106: warning: unable to resolve reference to ...```
/pipewire/spa/include/spa/param/video/multiview.h:72: warning: unable to resolve reference to 'spa_video_multiview_meta' for \ref command
/pipewire/spa/include/spa/param/video/multiview.h:106: warning: unable to resolve reference to 'SPA_VIDEO_BUFFER_FLAG_MULTIPLE_VIEW' for \ref command
```
And indeed, `spa_video_multiview_meta` has never existed as far as I can see. The same with `SPA_VIDEO_BUFFER_FLAG_MULTIPLE_VIEW`.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3762Playback jitters with Samsung Galaxy Buds2 Pro over LE Audio2024-03-16T16:45:42ZTom VincentPlayback jitters with Samsung Galaxy Buds2 Pro over LE Audio- PipeWire version: 1.0.0
- Distribution and distribution version: NixOS unstable
- Desktop Environment: GNOME 45.2
- Kernel version: 6.6.8
- BlueZ version: [7ad5669402c9acff8e4cc808edc12a41df36654e](https://github.com/bluez/bluez/commit...- PipeWire version: 1.0.0
- Distribution and distribution version: NixOS unstable
- Desktop Environment: GNOME 45.2
- Kernel version: 6.6.8
- BlueZ version: [7ad5669402c9acff8e4cc808edc12a41df36654e](https://github.com/bluez/bluez/commit/7ad5669402c9acff8e4cc808edc12a41df36654e) (git master)
- Adapter: AX210
- `lsusb`:
```
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 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 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0e8d:e616 MediaTek Inc. Wireless_Device
Bus 001 Device 002: ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```
- Bluetooth devices:
```
Device F6:9B:C7:EA:B7:EF MX Master
Device 18:26:54:C7:6C:9C Galaxy Buds2 Pro
Device 18:26:54:C7:6C:F0 Galaxy Buds2 Pro
Device CE:E0:0D:8D:CA:F9 MX Keys
```
## Description of Problem:
Similar to #3761, I experience frequent jitters/short breaks in playback using the Samsung Galaxy Buds2 Pro over LE Audio/bap.
## How Reproducible:
Any playback, particularly with the mouse (MX Master) connected. If I disconnect everything other than the ear buds, playback is *mostly* stable.
### Steps to Reproduce:
1. Enable [LE Audio + LC3 Support](https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/LE-Audio-+-LC3-support)
2. Connect earbuds
3. Start `WIREPLUMBER_DEBUG=5:spa.bluez5* wireplumber`
4. Start audio
### Actual Results:
Jitter/playback breaks up every few ms
### Expected Results:
Audio should play with no issues.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/4d13ca2631a64fa03886c06a9e30546c/pw-dump.log)
- [pipewire-bluez.log](/uploads/4405609614a5fd4cb3e8625e9b97f41e/pipewire-bluez.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3761Audio plays with breaks2024-01-04T14:51:48ZKlaas OetkenAudio plays with breaks- PipeWire version (`pipewire --version`): pipewire Compiled with libpipewire 1.0.0 Linked with libpipewire 1.0.0
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Pop!\_OS 22.04 LTS
- Desktop Environment: G...- PipeWire version (`pipewire --version`): pipewire Compiled with libpipewire 1.0.0 Linked with libpipewire 1.0.0
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Pop!\_OS 22.04 LTS
- Desktop Environment: Gnome 42.9
- Kernel version (`uname -r`): 6.6.6-76060606-generic
## Description of Problem:
Whenever I try to play audio on my machine I frequently hear short breaks (similar to listening to some music while running some heavy load on a single-core machine back in the 90s). I should note however that this is not a single-core computer from the 90s and it is mostly idling.
I have observed the output of `pw-top`, the `ERR` count goes up to several hundreds over the course of a minute. I don't know if the individual instances of these errors are logged somewhere - please let me know where I can find them and I will provide them.
## How Reproducible:
Always
### Steps to Reproduce:
1. Start computer
2. Play any audio using any software that plays audio
### Actual Results:
Audio plays, but frequently breaks up for a few milliseconds.
### Expected Results:
Audio should play with no issues.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/0f223a1ab24d4a0dfcbe04d1d0d865cf/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3760/etc/security/limits.d/25-pw-rlimits.conf has confusing comment2024-01-05T16:29:39ZRobert Edmonds/etc/security/limits.d/25-pw-rlimits.conf has confusing commentHi,
I see my Linux distro has shipped the following content in `/etc/security/limits.d/25-pw-rlimits.conf`:
```
# This file was installed by PipeWire project for its libpipewire-module-rt.so
# It's believed to be acceptable to have mat...Hi,
I see my Linux distro has shipped the following content in `/etc/security/limits.d/25-pw-rlimits.conf`:
```
# This file was installed by PipeWire project for its libpipewire-module-rt.so
# It's believed to be acceptable to have match rules that will never be true
# i.e. a group that does not exist.
#
@pipewire - rtprio 95
@pipewire - nice -19
@pipewire - memlock 4194304
```
Which is derived from https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/0fd058251429514c7e93ea0f1bf8fc6ca4fcc1ab/src/modules/module-rt/25-pw-rlimits.conf.in.
The comment "It's believed to be acceptable to have match rules that will never be true i.e. a group that does not exist" is confusing to me, because my system *does* have a `pipewire` group:
https://sources.debian.org/src/pipewire/1.0.0-1/debian/pipewire.README.Debian/#L99
```
The "pipewire" package creates a system group called "pipewire".
```
If this is the intended usage, could the comment in `25-pw-rlimits.conf` be clarified? Or is automatically creating the `pipewire` group a downstream "extra" and distros should also patch the comment themselves?
Thanks!https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3759Allow a stream to get its trigger_done() callback called on the realtime thread2024-01-04T10:30:55ZDemi Marie Obenourdemiobenour@gmail.comAllow a stream to get its trigger_done() callback called on the realtime threadI’m working on adding interrupt-driven scheduling to the [custom audio source and sink][1] used by [Qubes OS][2]. The sink works fine, but the source doesn’t. Logs indicate that the source xruns because it triggers the graph before it ...I’m working on adding interrupt-driven scheduling to the [custom audio source and sink][1] used by [Qubes OS][2]. The sink works fine, but the source doesn’t. Logs indicate that the source xruns because it triggers the graph before it has completed.
This can be fixed by not driving the graph again until the `trigger_done()` callback has fired. Unfortunately, the `trigger_done()` callback is called on the main thread, not the realtime thread. Therefore, this would cause the graph to be blocked until something happens on a non-realtime thread, which isn’t allowed.
SPA plugins can work around this by using the `process()` method instead. However, this would require my module to be rewritten as a SPA plugin, which is highly undesirable as SPA plugins require significantly more boilerplate.
A good solution to this problem would be a flag that causes `trigger_done()` to be called on the realtime thread.
[1]: https://github.com/QubesOS/qubes-gui-agent-linux/blob/5273125df18f9f358b0c556c336145da3d120d00/pipewire/qubes-pw-module.c
[2]: https://www.qubes-os.orghttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3758can't start pipewire-pulse in ubuntu23.102024-01-03T03:29:04Zwan inkercan't start pipewire-pulse in ubuntu23.10ubuntu 23.10 run pipewire 0.3.83 for le audio.
Log analysis shows that the socket node is occupied, but I don’t know why?
The following is the log of ubuntu booting pipewire
[](https://dpaste.com/7JPM3KCL4)ubuntu 23.10 run pipewire 0.3.83 for le audio.
Log analysis shows that the socket node is occupied, but I don’t know why?
The following is the log of ubuntu booting pipewire
[](https://dpaste.com/7JPM3KCL4)