pipewire issueshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues2023-11-01T00:02:14Zhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3594Audio is either 100% or off2023-11-01T00:02:14ZAndrea E. MontiAudio is either 100% or off- Pipewire: 0.3.83
- Distribution: EndeavourOS
- Desktop Environment: KDE Plasma
- Kernel version: 6.5.7-arch1-1
## Description of Problem:
Audio volume works as it was always 100%. It gets muted when I turn down to 0, but it is full vo...- Pipewire: 0.3.83
- Distribution: EndeavourOS
- Desktop Environment: KDE Plasma
- Kernel version: 6.5.7-arch1-1
## Description of Problem:
Audio volume works as it was always 100%. It gets muted when I turn down to 0, but it is full volume no matter which other level I choose.
Same as reported here
https://askubuntu.com/questions/1466286/lenovo-yoga-slim-7-pro-volume-cannot-be-changed
and here
https://askubuntu.com/questions/1119938/audio-volume-doesnt-change/1204558#1204558
I'm on a lenovo yoga 7 PRO, but has been reported (see in the links above) also on a thinkpad and an asus laptop.
### Fix (as suggested in the links above):
Editing `/usr/share/alsa-card-profile/mixer/paths/analog-output.conf.common` by adding these three lines at the beginning.
```
[Element Master]
switch = mute
volume = ignore
```
and reboot.
But the issue comes back after every update.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/35930.3.83: horrible sound2023-10-21T09:29:56ZCsaba R.0.3.83: horrible soundI installed pipewire 0.3.83. Pulse interface is OK, but alsa interface is wrong. (I'm not sure about that.)
Please listen to the attachment![pwbug](/uploads/cc5d66479ea8fb2dad0927f994214147/pwbug.wav)
[0.3.82-2](https://koji.fedoraproj...I installed pipewire 0.3.83. Pulse interface is OK, but alsa interface is wrong. (I'm not sure about that.)
Please listen to the attachment![pwbug](/uploads/cc5d66479ea8fb2dad0927f994214147/pwbug.wav)
[0.3.82-2](https://koji.fedoraproject.org/koji/buildinfo?buildID=2307379) is OK.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/35922 second delay when creating OpenAL context2023-10-20T08:00:19Zjazztickets2 second delay when creating OpenAL context<!-- 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.83 or master (b92b66cf5b2d273fb5ee98037aaa2b1157d29bae)
- Distribution and distr...<!-- 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.83 or master (b92b66cf5b2d273fb5ee98037aaa2b1157d29bae)
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: XFCE 4.18
- Kernel version (`uname -r`): 6.1.58-1-lts
## Description of Problem:
After upgrading to 0.3.83, there is a long delay when opening certain applications that use OpenAL on Linux. However, OpenAL programs that run in flatpak are fine. Only 'native' programs have the problem.
git bisect tells me `11320cf20394386a1e686af356a54c2b1154818b is the first bad commit`
## How Reproducible:
100%. I've tested this on 4 different Arch Linux computers.
### Steps to Reproduce:
The minimal program to reproduce this would be:
```
#include <alc.h>
int main(void) {
ALCdevice *device = alcOpenDevice(0);
ALCcontext *context = alcCreateContext(device, 0);
return 0;
}
```
Compile with `gcc main.c $(pkg-config openal --libs --cflags) -o altest`
### Actual Results:
```
time ./altest
real 0m2.006s
user 0m0.005s
sys 0m0.009s
```
### Expected Results:
```
time ./altest
real 0m0.036s
user 0m0.008s
sys 0m0.004s
```
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/6d0583920a799f5decd933ca7d337c10/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3591SONY WF-C500 huge latency (from 200ms to 500ms) using pipewire and wireplumber2024-02-02T05:30:41ZGabrieleSONY WF-C500 huge latency (from 200ms to 500ms) using pipewire and wireplumberFIX: [Hardware upgrade](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3591#note_2265088), Bluetooth 4.2 is insufficient for the WF-C500 (which are two separate units and the not sufficient capacity of Bluetooth 4.2 causes a s...FIX: [Hardware upgrade](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3591#note_2265088), Bluetooth 4.2 is insufficient for the WF-C500 (which are two separate units and the not sufficient capacity of Bluetooth 4.2 causes a stupidly high latency)
- PipeWire version (`pipewire --version`): 0.3.82
- 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.5.6-76060506-generic
- BlueZ version (`bluetoothctl --version`): 5.64
- `lsusb`:
```plaintext
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1770:ff00 MSI steel series rgb keyboard
Bus 001 Device 005: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 004: ID 5986:0683 Acer, Inc BisonCam, NB Pro
Bus 001 Device 003: ID 8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```
- Bluetooth devices:
```plaintext
Device 30:53:C1:D4:11:FF WF-C500
```
## Description of Problem:
Using the default values of Pipewire and Wireplumber, I can't fix the latency problem of those earbuds.
There's a latency that varies depending of what codec I'm using:
* AAC: 500ms
* SBC: 200ms maybe
* SBC-XQ: slightly more, maybe 250ms
IMPORTANT: A bluetooth speaker such as the JBL GO doesn't have this problem, I've even tested it while gaming. It's very strange.
BUT, connecting those earbuds is a pain, I can't connect them reliably, having to reset bluez almost every time to display the A2DP sink.
## How Reproducible:
Always
### Steps to Reproduce:
1. Connect the SONY WFC-500 earbuds
2. Open a game or watch a movie
3. Contemplate your life choices watching a weapon shooting before the sound gets reproduced
### Actual Results: Huge latency
### Expected Results: Low latency, at least pipewire should adapt everything
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/741ceb59a3cfa79e23796b5eb475eece/pw-dump.log)
- Bluetooth debug log, see [here](https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting#bluetooth):https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3590Unable to transmit sound in Bluetooth LE audio connected with pipewire.2024-01-13T11:44:12ZsilviubarbulescuUnable to transmit sound in Bluetooth LE audio connected with pipewire.- PipeWire version (`master commit` 42418bece59d8325a2e627877a35408bbdad5b2b):
- Distribution and distribution version (`Ubuntu 23.04`):
- Desktop Environment: ubuntu:GNOME
- Kernel version (`6.5.0-rc7+`):
- BlueZ version (bluez master o...- PipeWire version (`master commit` 42418bece59d8325a2e627877a35408bbdad5b2b):
- Distribution and distribution version (`Ubuntu 23.04`):
- Desktop Environment: ubuntu:GNOME
- Kernel version (`6.5.0-rc7+`):
- BlueZ version (bluez master on Github 0c757e8eeef69ff2b1eefa59e590f171c9fe1c88):
## Description of Problem:
I have a setup of Bluetooth LE audio connected with PipeWire.
Central is configured as bap_sink, peripheral as bap_source.
The problem is that after I create the connection, I'm unable to send sound from the peripheral(bap_source) to the central(bap_sink) because I'm unable to see the bluez_output sink on the peripheral.
$ pactl list short sinks 52 alsa_output.pci-0000_00_1f.3.analog-stereo PipeWire s32le 2ch 48000Hz SUSPENDED
From my investigation, the problem is stated from the way the pipe wire node is created on peripheral in the function emit_nodes from bluez5-device.c where the node is created as a dynamic node.
## How Reproducible:
Is always reproducible
### Steps to Reproduce:
1. On the central set \["bluez5.roles"\] = "\[bap_sink\]", on peripheral \["bluez5.roles"\] = "\[bap_source\]"
2. Create the connection between central and peripheral.
3. After the connection is created the endpoint and transports are created.
### Actual Results:
The problem is that after I create the connection, I'm unable to send sound from the peripheral(bap_source) to the central(bap_sink) because I'm unable to see the bluez_output sink on the peripheral.
$ pactl list short sinks
52 alsa_output.pci-0000_00_1f.3.analog-stereo PipeWire s32le 2ch 48000Hz SUSPENDED
### Expected Results:
I expect to see the bluez_output... node with pactl list short sinks command
Attached pipewire_log:
[log_pipewire (3).7z](/uploads/fe05d6765b7a834edd9d5c3d5117f1df/log_pipewire__3\_.7z)
The same problem appears if on central, peripheral both bap_sink and bap_source are configured. From the peripheral, I'm unable to see the output Bluez connection to the central.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3589Possible typo in args line in pipewire.conf.in at libpipewire-module-jackdbus...2023-10-20T17:29:48ZMark SchlegelPossible typo in args line in pipewire.conf.in at libpipewire-module-jackdbus-detect moduleI was using pipewire on Fedora 39 beta and noted this particular args line was inconsistently formatted to all the others:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/daemon/pipewire.conf.in#L180-181
```
{ na...I was using pipewire on Fedora 39 beta and noted this particular args line was inconsistently formatted to all the others:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/daemon/pipewire.conf.in#L180-181
```
{ name = libpipewire-module-jackdbus-detect
args {
```
I think there should be an "=" between "args" and "{"https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3588use-after-free when node is destroyed while async param set is in progress2023-10-18T17:10:24ZBarnabás Pőczeuse-after-free when node is destroyed while async param set is in progressSee:
```
[I][206213][51607.320387] pw.node | [ impl-node.c: 408 node_update_state()] (Mutter-78) creating -> suspended
[I][206213][51607.323619] pw.context | [ context.c: 1194 pw_context_recalc_graph()] 0x61a000000c80: ...See:
```
[I][206213][51607.320387] pw.node | [ impl-node.c: 408 node_update_state()] (Mutter-78) creating -> suspended
[I][206213][51607.323619] pw.context | [ context.c: 1194 pw_context_recalc_graph()] 0x61a000000c80: busy:0 reason:node activate
[I][206213][51607.355669] pw.node | [ impl-node.c: 2034 pw_impl_node_destroy()] (Mutter-78) destroy
[I][206213][51607.355819] pw.context | [ context.c: 1194 pw_context_recalc_graph()] 0x61a000000c80: busy:0 reason:active node destroy
=================================================================
==206213==ERROR: AddressSanitizer: heap-use-after-free on address 0x617000047ce0 at pc 0x7fb5978c2560 bp 0x7ffe99d16880 sp 0x7ffe99d16870
WRITE of size 8 at 0x617000047ce0 thread T0
#0 0x7fb5978c255f in spa_list_remove ../spa/include/spa/utils/list.h:61
#1 0x7fb5978c290c in spa_hook_remove ../spa/include/spa/utils/hook.h:385
#2 0x7fb5978dee81 in remove_busy_resource ../src/pipewire/impl-node.c:534
#3 0x7fb5978e0965 in resource_destroy ../src/pipewire/impl-node.c:614
#4 0x7fb59799fcd5 in pw_resource_destroy ../src/pipewire/resource.c:325
#5 0x7fb59785422f in pw_global_destroy ../src/pipewire/global.c:399
#6 0x7fb59777423a in registry_destroy ../src/pipewire/impl-core.c:107
#7 0x7fb59133efb8 in registry_demarshal_destroy ../src/modules/module-protocol-native/protocol-native.c:810
#8 0x7fb591306f42 in process_messages ../src/modules/module-protocol-native.c:383pw_context_recalc_graph()] 0x61a000000c80: busy:0 reason:active node destroy
#9 0x7fb59130883f in connection_data ../src/modules/module-protocol-native.c:454
#10 0x7fb5930cc18c in source_io_func ../spa/plugins/support/loop.c:512
#11 0x7fb5930cbbdb in loop_iterate ../spa/plugins/support/loop.c:496
#12 0x7fb5978a7de4 in pw_main_loop_run ../src/pipewire/main-loop.c:128
#13 0x56112f689722 in main ../src/daemon/pipewire.c:111
#14 0x7fb598245ccf (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
#15 0x7fb598245d89 in __libc_start_main (/usr/lib/libc.so.6+0x27d89) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
#16 0x56112f6882a4 in _start (/home/pb/temp/src/pipewire/build/src/daemon/pipewire+0x42a4) (BuildId: 2ed9678cd6b377f0dee04014fb5e5001474e37a3)
0x617000047ce0 is located 96 bytes inside of 704-byte region [0x617000047c80,0x617000047f40)
freed by thread T0 here:
#0 0x7fb5984dfdb2 in __interceptor_free /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:52
#1 0x7fb59077c6b4 in node_free ../src/modules/module-client-node/client-node.c:1369
#2 0x7fb59790dbd9 in pw_impl_node_destroy ../src/pipewire/impl-node.c:2082
#3 0x7fb5978e1ae1 in global_destroy ../src/pipewire/impl-node.c:677
#4 0x7fb597854028 in pw_global_destroy ../src/pipewire/global.c:396
#5 0x7fb59777423a in registry_destroy ../src/pipewire/impl-core.c:107
#6 0x7fb59133efb8 in registry_demarshal_destroy ../src/modules/module-protocol-native/protocol-native.c:810
#7 0x7fb591306f42 in process_messages ../src/modules/module-protocol-native.c:383
#8 0x7fb59130883f in connection_data ../src/modules/module-protocol-native.c:454
#9 0x7fb5930cc18c in source_io_func ../spa/plugins/support/loop.c:512
#10 0x7fb5930cbbdb in loop_iterate ../spa/plugins/support/loop.c:496
#11 0x7fb5978a7de4 in pw_main_loop_run ../src/pipewire/main-loop.c:128
#12 0x56112f689722 in main ../src/daemon/pipewire.c:111
#13 0x7fb598245ccf (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
previously allocated by thread T0 here:
#0 0x7fb5984e0cc1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7fb5907811e0 in pw_impl_client_node_new ../src/modules/module-client-node/client-node.c:1657
#2 0x7fb59072e31b in create_object ../src/modules/module-client-node.c:79
#3 0x7fb59791b006 in pw_impl_factory_create_object ../src/pipewire/impl-factory.c:254
#4 0x7fb597778632 in core_create_object ../src/pipewire/impl-core.c:328
#5 0x7fb59133c80a in core_method_demarshal_create_object ../src/modules/module-protocol-native/protocol-native.c:706
#6 0x7fb591306f42 in process_messages ../src/modules/module-protocol-native.c:383
#7 0x7fb59130883f in connection_data ../src/modules/module-protocol-native.c:454
#8 0x7fb5930cc18c in source_io_func ../spa/plugins/support/loop.c:512
#9 0x7fb5930cbbdb in loop_iterate ../spa/plugins/support/loop.c:496
#10 0x7fb5978a7de4 in pw_main_loop_run ../src/pipewire/main-loop.c:128
#11 0x56112f689722 in main ../src/daemon/pipewire.c:111
#12 0x7fb598245ccf (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658)
SUMMARY: AddressSanitizer: heap-use-after-free ../spa/include/spa/utils/list.h:61 in spa_list_remove
Shadow bytes around the buggy address:
0x617000047a00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x617000047a80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x617000047b00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x617000047b80: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
0x617000047c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x617000047c80: fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd
0x617000047d00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x617000047d80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x617000047e00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x617000047e80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x617000047f00: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==206213==ABORTING
Félbeszakítva (core készült)
```
This is because the `pw_impl_node` and the contained `spa_node` objects are destroyed before the `impl-node.c:resource_data` objects that refer to them. This is especially problematic if an async param set is in progress ([`impl-node.c:node_set_param()`](https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/8735d07c0ab132be3ae1f903033c4c558d0b3c57/src/pipewire/impl-node.c#L573)) because in that case the `resource_data` will be on a `spa_hook_list` that has already been destroyed (in this case: in `client-node.c:node_free()`). So when the resource is eventually destroyed, `impl-node.c:remove_busy_resource()` will call `spa_hook_remove()`, which leads to the use-after-free seen above.
I believe something like the following fixes this issue but I think there should be a better solution.
<details>
```diff
diff --git a/src/pipewire/impl-node.c b/src/pipewire/impl-node.c
index 6bfa26b16..a8bacfc24 100644
--- a/src/pipewire/impl-node.c
+++ b/src/pipewire/impl-node.c
@@ -39,6 +39,7 @@ struct impl {
struct spa_list param_list;
struct spa_list pending_list;
+ struct spa_list resources;
unsigned int cache_params:1;
unsigned int pending_play:1;
@@ -49,6 +50,7 @@ struct impl {
#define pw_node_resource_param(r,...) pw_node_resource(r,param,0,__VA_ARGS__)
struct resource_data {
+ struct spa_list link;
struct pw_impl_node *node;
struct pw_resource *resource;
@@ -608,12 +610,17 @@ static const struct pw_node_methods node_methods = {
.send_command = node_send_command
};
-static void resource_destroy(void *data)
+static void resource_data_clear(struct resource_data *d)
{
- struct resource_data *d = data;
remove_busy_resource(d);
spa_hook_remove(&d->resource_listener);
spa_hook_remove(&d->object_listener);
+ spa_list_remove(&d->link);
+}
+
+static void resource_destroy(void *data)
+{
+ resource_data_clear(data);
}
static void resource_pong(void *data, int seq)
@@ -655,6 +662,8 @@ global_bind(void *object, struct pw_impl_client *client, uint32_t permissions,
&data->object_listener,
&node_methods, data);
+ spa_list_append(&SPA_CONTAINER_OF(this, struct impl, this)->resources, &data->link);
+
pw_log_debug("%p: bound to %d", this, resource->id);
pw_global_add_resource(global, resource);
@@ -1347,6 +1356,7 @@ struct pw_impl_node *pw_context_create_node(struct pw_context *context,
spa_list_init(&impl->param_list);
spa_list_init(&impl->pending_list);
+ spa_list_init(&impl->resources);
this = &impl->this;
this->context = context;
@@ -2069,6 +2079,10 @@ void pw_impl_node_destroy(struct pw_impl_node *node)
spa_list_consume(port, &node->output_ports, link)
pw_impl_port_destroy(port);
+ struct resource_data *d;
+ spa_list_consume(d, &impl->resources, link)
+ resource_data_clear(d);
+
if (node->global) {
spa_hook_remove(&node->global_listener);
pw_global_destroy(node->global);
```
</details>https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3587Elgato Wave XLR profiles where both input and output are active breaks input2023-10-17T22:12:14ZDaktylElgato Wave XLR profiles where both input and output are active breaks input- PipeWire version (`pipewire --version`): 0.3.82
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Garuda Linux
- Desktop Environment: KDE PLasma 5
- Kernel version (`uname -r`): 6.5.7-zen2-1-zen
## Descri...- PipeWire version (`pipewire --version`): 0.3.82
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Garuda Linux
- Desktop Environment: KDE PLasma 5
- Kernel version (`uname -r`): 6.5.7-zen2-1-zen
## Description of Problem:
When selecting any mode that allows audio output in addition to the mic input for the XLR in PipeWire's settings, the input produces no audio 9 times out of 10.
## How Reproducible:
Fairly reproducible, testable using Discord's "Let's Check" mic testing feature. Actual instances of it working seem random. It may break, fix itself, then break again without ever changing the audio profile. Switching purely to the "Mono Input" profile for the Wave XLR produces a working microphone every single time.
### Steps to Reproduce:
1. Open Discord and set input to Wave XLR input
2. Turn on Mic Test
3. Listen and watch levels meter for mic input while switching between different profiles in the audio settings.
### Actual Results:
9/10 times there is no audio from the mic if you are also using audio output on the device.
### Expected Results:
Audio input should work as expected in any profile/mode, not just the input-only mode
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/73e075be437143d71a54ad51bd2183cb/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3586Vistual Surround sink 7.1 breaks after volume change2023-10-19T16:18:17ZX6205Vistual Surround sink 7.1 breaks after volume changeWhen i change volume, virtual surround sink 7.1 stops outputting audio to all channels except right and left channels. Other are silent.
I have updated PipeWire from 0.3.79 to 0.3.82 from this Ubuntu 22.04 repository
https://launchpad....When i change volume, virtual surround sink 7.1 stops outputting audio to all channels except right and left channels. Other are silent.
I have updated PipeWire from 0.3.79 to 0.3.82 from this Ubuntu 22.04 repository
https://launchpad.net/~pipewire-debian/+archive/ubuntu/pipewire-upstream?field.series_filter=jammyhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3585pipewire-jack hangs when used in the SDL3 tests2023-10-17T11:09:10ZMaarten DBpipewire-jack hangs when used in the SDL3 testsHello,
When using the `jack` audio driver in the SDL3 tests, the tests frequently hang and need to be killed using SIGQUIT (CTRL+`\`).
It does not happen every time, but often.
[This is the SDL issue](https://github.com/libsdl-org/SDL/...Hello,
When using the `jack` audio driver in the SDL3 tests, the tests frequently hang and need to be killed using SIGQUIT (CTRL+`\`).
It does not happen every time, but often.
[This is the SDL issue](https://github.com/libsdl-org/SDL/issues/8348), where we determined this got to be an issue with pipewire-jack.
## Reproducer
1. `git clone https://github.com/libsdl-org/SDL /tmp/SDL -b main --depth 1`
2. `cmake -S /tmp/SDL -B /tmp/sdl_build -DSDL_TESTS=ON`
3. `cmake --build /tmp/sdl_build`
4. `SDL_AUDIO_DRIVER=jack /tmp/sdl_build/test/testaudio`
5. Create a logical device by dragging a device with the right mouse button
6. If the app does not hang, close the app and goto step 4
(the testaudio test application is introduced in [this video](https://www.youtube.com/watch?v=MLau3hWJBeE))
Backtrace
```
#0 0x00007ff754eab219 in __futex_abstimed_wait_common64
(private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x13e109c) at futex-internal.c:57
#1 __futex_abstimed_wait_common
(futex_word=futex_word@entry=0x13e109c, 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 0x00007ff754eab29f in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x13e109c, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3 0x00007ff754eadbb9 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x13e1098, cond=0x13e1070)
at pthread_cond_wait.c:503
#4 ___pthread_cond_wait (cond=cond@entry=0x13e1070, mutex=mutex@entry=0x13e1048) at pthread_cond_wait.c:618
#5 0x00007ff74bfb115b in pw_thread_loop_wait (loop=0x13e1020) at ../src/pipewire/thread-loop.c:429
#6 0x00007ff75069432a in do_sync (client=0x13d9380) at ../pipewire-jack/src/pipewire-jack.c:1235
#7 0x00007ff7506a0a56 in jack_connect
(client=0x13d9380, source_port=0x7ff72c008c30 "Built-in Audio Analog Stereo:capture_FR", destination_port=0x7ff73000ed28 "SDL Application-59:sdl_jack_input_1") at ../pipewire-jack/src/pipewire-jack.c:5725
#8 0x00007ff75516659d in JACK_OpenDevice (device=0x1367610)
at /home/maarten/projects/SDL/src/audio/jack/SDL_jackaudio.c:392
#9 0x00007ff755032962 in OpenPhysicalAudioDevice (device=0x1367610, inspec=0x0)
at /home/maarten/projects/SDL/src/audio/SDL_audio.c:1463
#10 0x00007ff755032c7d in SDL_OpenAudioDevice_REAL (devid=18, spec=0x0)
at /home/maarten/projects/SDL/src/audio/SDL_audio.c:1546
#11 0x00007ff755052b8c in SDL_OpenAudioDevice (a=4294967294, b=0x0)
at /home/maarten/projects/SDL/src/dynapi/SDL_dynapi_procs.h:913
#12 0x0000000000406eaf in DeviceThing_ondrag (thing=0x135ac90, button=3, x=215.398438, y=231.898438)
at /home/maarten/projects/SDL/test/testaudio.c:771
#13 0x00000000004080ef in Loop () at /home/maarten/projects/SDL/test/testaudio.c:1110
#14 0x0000000000408688 in main (argc=1, argv=0x7ffff64d0bc8) at /home/maarten/projects/SDL/test/testaudio.c:1269
```
Using pipewire 0.3.82, packaged by Fedora 38
Thanks!https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3584Corrupted audio from Roland USB audio devices since 0.3.812023-10-18T16:04:23ZErik GustavssonCorrupted audio from Roland USB audio devices since 0.3.81- PipeWire version (`pipewire --version`): 0.3.82 (first noticed with 0.3.81, problem also persists in latest master if I managed to test it correctly)
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Pop!\...- PipeWire version (`pipewire --version`): 0.3.82 (first noticed with 0.3.81, problem also persists in latest master if I managed to test it correctly)
- 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.4.6-76060406-generic
## Description of Problem:
Audio captured from my Roland MC-101 and TR-6S (synthesizers with multichannel USB audio) have very frequent dropouts. They work fine under 0.3.80.
First suspected this was because these devices only support fixed sample rates that differ from the pipewire rate, but changing the pipewire rate didn't fix the problem.
## How Reproducible:
100%
### Steps to Reproduce:
1. Connect one or more capture channels from one of the devices to an output or an application (Ardour via Jack).
2. Listen to output or record
3.
### Actual Results:
Distorted audio with what appears to be blocks of zero data of length equal to the current quantum.
### Expected Results:
Distortion-free audio
# Additional Info (as attachments):
* Screenshot from recording in Ardour (extreme closeup). Top is with 0.3.81, bottom is with 0.3.80. The dropout appears to be 256 samples, which is the quantum I'm using.
* Simple connection I used to replicate the problem.
* pw-top output from 0.3.80 and 0.3.81 when running the above. Most notable difference to me is that there are additional devices active in 0.3.81 and above.
* Errors from systemd log (small note, when I notice these I was running with quant 1024).
[journalctl.txt](/uploads/a9bb5837a2eaa20b1a71fc42f201efb2/journalctl.txt)
[pwtop_error.txt](/uploads/c3568bce8c80d2c4b560f9911c93f867/pwtop_error.txt)
[pwtop_ok](/uploads/830706d8f8c4d7c5d1a5de540166e41c/pwtop_ok)
- ![dropouts.png](/uploads/f39d396337592e21b9cd519aeb83b639/dropouts.png)
![helvum.png](/uploads/f88e7646a1c093e378273710aaea868a/helvum.png)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3583Crackling audio if anything is played for 15 seconds after gamescope spawn2023-10-16T16:32:55ZMarco RodolfiCrackling audio if anything is played for 15 seconds after gamescope spawn<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): Compiled with libpipewire 0.3.82
- Distribution and distribution version (`PRETTY_NA...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): Compiled with libpipewire 0.3.82
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Fedora Linux 38.20231015.0 (Bazzite)
- Desktop Environment: GameMode (GameScope session)
- Kernel version (`uname -r`): 6.5.6-200.fc38.x86_64
## Description of Problem:
I'm not sure it's an issue with pipewire or GameScope yet, but since it happens on both bluetooth audio and integrated audio is either one of the two. As soon as gamescope is spawned after a reboot or after switching from desktop to game mode, the audio begins to stutter incredibly heavily for at least 15 seconds. If the audio is used during that period for playing any audio the stutters will keep repeating until a pause of around 15 seconds is done. After that, audio is perfect (I'm not sure if I ever got it back after a gamescope reboot, it might have happened once, but I might misremembering it).
## How Reproducible:
100% after a gamescope restart
### Steps to Reproduce:
1. Boot up Steam Deck with a modern kernel (6.5) and wait to go into gamemode or go back to gamemode
2. Press buttons to trigger audio playback from the sound menu
### Actual Results:
The audio is basically unintelligible from the amount of stutters and skip presents
### Expected Results:
The audio is played perfectly fine.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pwlog.log](/uploads/9b72c92dfc5e316ce15be193fcc2f9f3/pwlog.log)
- pw-top output in two states:
- Broken: ![crackling_speaker](/uploads/4fbbf40a360739dfd1d8b5c245ef9871/crackling_speaker.png)
- Non broken: ![non_crackling_speaker](/uploads/6861a0ddcb54c92300c32ab6cbd2490c/non_crackling_speaker.png)
Let me know if you need additional debugging steps.
Marco.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3582[Feature request] Implement functionality similar to PulseAudio's module-allo...2023-10-16T15:15:11ZMarkus Koller[Feature request] Implement functionality similar to PulseAudio's module-allow-passthroughFrom https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-allow-passthrough:
> This module ensures that passthrough streams are always allowed to play on sinks. The default policy in PulseAudio is to o...From https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-allow-passthrough:
> This module ensures that passthrough streams are always allowed to play on sinks. The default policy in PulseAudio is to only allow exclusive access if nothing else is currently using the sink. With this module, all the existing streams are muted (by being re-routed to the null sink) when a passthrough stream comes in, allowing the passthrough stream to exclusively use the sink.
>
> This is particularly useful with media centers and HTPC boxes (e.g. Kodi media center) where we usually always want to be able to start a video even if an external notification sound happened to be playing at the same time.
This is quite a big quality-of-life improvement on a HTPC that's also used for other desktop purposes. Before PulseAudio implemented this, I always had to make sure that no other client was blocking passthrough (e.g. my music player being paused instead of stopped, or having an open browser tab with a YouTube video).https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3575MIDI input stopped working (master)2023-10-16T07:37:02ZMarcin KoziołMIDI input stopped working (master)- PipeWire version (`pipewire --version`): master after 6fefd49a8a212e827b0413b05ed5f73f1bd72876
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Ubuntu 23.04
- Desktop Environment: Gnome shell
- Kernel ver...- PipeWire version (`pipewire --version`): master after 6fefd49a8a212e827b0413b05ed5f73f1bd72876
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Ubuntu 23.04
- Desktop Environment: Gnome shell
- Kernel version (`uname -r`): 6.2.0-1014-lowlatency
## Description of Problem:
I'm not able to play using MIDI keyboard
## How Reproducible:
always
### Steps to Reproduce:
1. build master branch
2. open carla/ardour with some plugins, try to play using MIDI keyboard
### Actual Results:
1. MIDI events aren't passed to plugin
2. Clicking on virtual keyboard (for example in Carla's patchbay, when plugin is selected) works
### Expected Results:
I should be able to use USB Midi keyboard
# Additional Info
After git bisect:
➜ pipewire git:( c94d5d9d3) git bisect good\
6fefd49a8a212e827b0413b05ed5f73f1bd72876 is the first bad commit commit 6fefd49a8a212e827b0413b05ed5f73f1bd72876 Author: Wim Taymans wtaymans@redhat.com Date: Sat Oct 14 12:23:39 2023 +0200
```plaintext
jack: use a private writable mapping on input
See #3571
```https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3574choppy audio in recording when using loopback module2023-10-16T16:32:55Zjazzticketschoppy audio in recording when using loopback module<!-- 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.81+ to master (2bef05742842ede4ce018d9a31d72e42c09be185)
- Distribution and dist...<!-- 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.81+ to master (2bef05742842ede4ce018d9a31d72e42c09be185)
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: XFCE 4.18
- Kernel version (`uname -r`): 6.1.57-1-lts
## Description of Problem:
I use libpipewire-module-loopback to create a sink that I can redirect my game's audio output to. This allows me to record just the game's audio in OBS. After upgrading to pipewire 0.3.81, I noticed that the audio in the recording is choppy. The audio is fine through the speakers as I'm playing the game though.
git bisect tells me the 'bad' commit was cc0eb1ba0dea6d0d5e3586e1267e2b6dd7ac3795
## How Reproducible:
100%
### Steps to Reproduce:
1. Create a sink using the attached ~/.config/pipewire/pipewire.conf.d/20-loopback.conf config file:
[20-loopback.conf](/uploads/435d523eb5251b0109ce66ca08be77ff/20-loopback.conf)
2. Start the game and switch its output to the new 'game' sink
3. Use OBS to record a video and make sure the audio device is set to record from 'game'
### Actual Results:
Choppy audio:
![pipewire_bad](/uploads/903680b13aa2922721d2dcfed1879189/pipewire_bad.mp3)
### Expected Results:
Good audio:
![pipewire_good](/uploads/d7cd60ae40942f428a410b623ab1bc8c/pipewire_good.mp3)
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/679daf84632c22da9de7086f08d29557/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3573getsockopt(SCO_OPTIONS) failed, loading defaults2023-10-16T06:36:34ZAsela Fernandogetsockopt(SCO_OPTIONS) failed, loading defaults- PipeWire version (`pipewire --version`):
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Debian GNU/Linux 12 (bookworm)
- Desktop Environment: No window manager
- Kernel version (`uname -r`): 6.1.0-rpi4-...- PipeWire version (`pipewire --version`):
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Debian GNU/Linux 12 (bookworm)
- Desktop Environment: No window manager
- Kernel version (`uname -r`): 6.1.0-rpi4-rpi-v8
- BlueZ version (`bluetoothctl --version`): 5.66
- `lsusb`:
```
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 1235:8211 Focusrite-Novation Scarlett Solo (3rd Gen.)
Bus 001 Device 003: ID 0eef:0005 D-WAV Scientific Co., Ltd WS170120
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```
- Bluetooth devices:
```
Device F0:39:XX:XX:XX:XX AceSailor S21
```
## Description of Problem:
With ofono, the MTU for the SCO audio path is not negotiated and the default of 48 is used which is too small. This results in choppy audio.
If ofono is disabled the MTU is negotiated fine and the audio is perfect.
In either case A2DP audio is fine.
Pulseaudio also had this issue in v14.x however they increased the default MTU from 48 to 144 to fix this.
https://github.com/pulseaudio/pulseaudio/blob/13ef02da1bc55b8a36ff35ca5f9d15cf7495932a/src/modules/bluetooth/backend-ofono.c#L331
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/plugins/bluez5/backend-ofono.c?ref_type=heads#L96
## How Reproducible:
Reproducible
### Steps to Reproduce:
1. Install ofono: ```sudo apt -y install ofono```
2. Modify dbus config to ensure the user can send information to ofono (/etc/dbus-1/system.d/ofono.conf)
3. Enable ofono ```sudo systemctl enable ofono```
4. Configure wireplumber to use ofono backend ```sed -i '/bluez5.hfphsp-backend/s/--//;s/native/ofono/' /etc/wireplumber/bluetooth.lua.d/50-bluez-config.lua```
5. Reboot and login
6. Connect the hfp_ag service with a phone
7. Make a phone call
### Actual Results:
wireplumber: getsockopt(SCO_OPTIONS) failed, loading defaults
### Expected Results:
Expect wireplumber to have obtained the MTU from the ofono socket
# Additional Info (as attachments):
```
ofonod --version
1.31
```
```
systemctl --user status wireplumber
Oct 15 21:56:01 MR2 systemd[767]: Started wireplumber.service - Multimedia Service Session Manager.
Oct 15 21:56:02 MR2 wireplumber[784]: SPA handle 'api.libcamera.enum.manager' could not be loaded; is it installed?
Oct 15 21:56:02 MR2 wireplumber[784]: PipeWire's libcamera SPA missing or broken. libcamera not supported.
Oct 15 21:56:03 MR2 wireplumber[784]: Trying to use legacy bluez5 API for LE Audio - only A2DP will be supported. Please upgrade bluez5.
Oct 15 21:56:29 MR2 wireplumber[784]: getsockopt(SCO_OPTIONS) failed, loading defaults <---- Happens as call is made
Oct 15 21:56:45 MR2 wireplumber[784]: sco-sink: write failure: -9 (Bad file descriptor) <-- Happens as the call is terminated
```
```
systemctl --user status pipewire
Oct 15 21:56:01 MR2 systemd[767]: Started pipewire.service - PipeWire Multimedia Service.
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video14' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video15' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video21' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video22' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video14' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video15' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video21' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
Oct 15 21:56:03 MR2 pipewire[783]: spa.v4l2: '/dev/video22' VIDIOC_ENUM_FRAMEINTERVALS: Inappropriate ioctl for device
```
During a phone call
```
wpctl status
PipeWire 'pipewire-0' [0.3.65, asela@MR2, cookie:684911199]
└─ Clients:
31. pipewire [0.3.65, asela@MR2, pid:785]
33. WirePlumber [0.3.65, asela@MR2, pid:784]
34. WirePlumber [export] [0.3.65, asela@MR2, pid:784]
90. wpctl [0.3.65, asela@MR2, pid:826]
Audio
├─ Devices:
│ 53. Scarlett Solo (3rd Gen.) [alsa]
│ 54. Built-in Audio [alsa]
│ 55. Built-in Audio [alsa]
│ 77. AceSailor S21 [bluez5]
│
├─ Sinks:
│ 32. Built-in Audio Digital Stereo (HDMI) [vol: 0.40]
│ * 69. Scarlett Solo (3rd Gen.) Analog Stereo [vol: 1.00]
│
├─ Sink endpoints:
│
├─ Sources:
│ * 70. Scarlett Solo (3rd Gen.) Analog Stereo [vol: 1.00]
│
├─ Source endpoints:
│
└─ Streams:
78. bluez_input.F0_39_XX_XX_XX_XX.0
79. output_FR > Scarlett Solo USB:playback_FR [active]
82. output_FL > Scarlett Solo USB:playback_FL [active]
80. bluez_output.F0_39_XX_XX_XX_XX.1
81. input_FL < Scarlett Solo USB:capture_FL [active]
83. monitor_FL
84. input_FR < Scarlett Solo USB:capture_FR [active]
85. monitor_FR
Video
├─ Devices:
│ 39. rpivid [v4l2]
│ 40. bcm2835-codec-decode [v4l2]
│ 41. bcm2835-codec-encode [v4l2]
│ 42. bcm2835-codec-isp [v4l2]
│ 43. bcm2835-codec-image_fx [v4l2]
│ 44. bcm2835-codec-encode_image [v4l2]
│ 45. bcm2835-isp [v4l2]
│ 46. bcm2835-isp [v4l2]
│ 47. bcm2835-isp [v4l2]
│ 48. bcm2835-isp [v4l2]
│ 49. bcm2835-isp [v4l2]
│ 50. bcm2835-isp [v4l2]
│ 51. bcm2835-isp [v4l2]
│ 52. bcm2835-isp [v4l2]
│
├─ Sinks:
│
├─ Sink endpoints:
│
├─ Sources:
│ 61. bcm2835-isp (V4L2)
│ 63. bcm2835-isp (V4L2)
│ 65. bcm2835-isp (V4L2)
│ 67. bcm2835-isp (V4L2)
│
├─ Source endpoints:
│
└─ Streams:
Settings
└─ Default Configured Node Names:
```https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3572UBSAN: left shift of negative value -64, store to misaligned address2023-10-16T11:34:17ZP VUBSAN: left shift of negative value -64, store to misaligned addressRunning the test suite with UBSan enabled emits some complaints:
```
$ ./builddir/spa/plugins/audiomixer/test-mix-ops
got get CPU flags 19419
test_s8_0
test_s8_1
test_s8_4
test_u8_0
test_u8_1
test_u8_4
test_s16_0
test_s16_1
test_s16_4
t...Running the test suite with UBSan enabled emits some complaints:
```
$ ./builddir/spa/plugins/audiomixer/test-mix-ops
got get CPU flags 19419
test_s8_0
test_s8_1
test_s8_4
test_u8_0
test_u8_1
test_u8_4
test_s16_0
test_s16_1
test_s16_4
test_u16_0
test_u16_1
test_u16_4
test_s24_0
test_s24_1
test_s24_4
../spa/plugins/audiomixer/mix-ops.h:46:26: runtime error: left shift of negative value -64
#0 0x5609f9efd46d in s24_to_s32 ../spa/plugins/audiomixer/mix-ops.h:46
#1 0x5609f9efd46d in mix_s24_c ../spa/plugins/audiomixer/mix-ops-c.c:41
#2 0x5609f9eff83f in run_test ../spa/plugins/audiomixer/test-mix-ops.c:48
#3 0x5609f9f020c5 in test_s24 ../spa/plugins/audiomixer/test-mix-ops.c:125
#4 0x5609f9f06c47 in main ../spa/plugins/audiomixer/test-mix-ops.c:263
#5 0x7ff170c46149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: 7dd93cb9991a89f0ec53d9443a0b78ad952269bc)
#6 0x7ff170c4620a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) (BuildId: 7dd93cb9991a89f0ec53d9443a0b78ad952269bc)
#7 0x5609f9efd864 in _start (/home/pauli/prj/external/pipewire/builddir/spa/plugins/audiomixer/test-mix-ops+0x10864) (BuildId: e3eadde5566317598a0a5aaeb70c2e6e23b9d1ea)
```
```
$ ./builddir/spa/plugins/audioconvert/test-fmt-ops
got CPU flags 19419
test test_f32_s8:
test test_f32d_s8:
test test_f32_s8d:
test test_f32d_s8d:
test test_s8_f32:
test test_s8d_f32:
test test_s8_f32d:
test test_s8d_f32d:
test test_f32_u8:
test test_f32d_u8:
test test_f32_u8d:
test test_f32d_u8d:
test test_u8_f32:
test test_u8d_f32:
test test_u8_f32d:
test test_u8d_f32d:
test test_f32_u16:
test test_f32d_u16:
test test_u16_f32d:
test test_u16_f32:
test test_f32_s16:
test test_f32d_s16:
test test_f32_s16d:
test test_f32d_s16d:
test test_f32_s16_sse2:
test test_f32d_s16_sse2:
../spa/plugins/audioconvert/fmt-ops-sse2.c:1151:35: runtime error: store to misaligned address 0x559099f3db66 for type 'int32_t', which requires 4 byte alignment
0x559099f3db66: note: pointer points here
ff 7f ff 7f 00 00 00 00 00 00 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 00 00 00 00 00
^
#0 0x559099e87319 in conv_f32d_to_s16_2s_sse2 ../spa/plugins/audioconvert/fmt-ops-sse2.c:1151
#1 0x559099e87319 in conv_f32d_to_s16_sse2 ../spa/plugins/audioconvert/fmt-ops-sse2.c:1241
#2 0x559099e3e9dd in run_test ../spa/plugins/audioconvert/test-fmt-ops.c:90
#3 0x559099e3f522 in test_f32_s16 ../spa/plugins/audioconvert/test-fmt-ops.c:213
#4 0x559099e436f3 in main ../spa/plugins/audioconvert/test-fmt-ops.c:755
#5 0x7f2a25c46149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: 7dd93cb9991a89f0ec53d9443a0b78ad952269bc)
#6 0x7f2a25c4620a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) (BuildId: 7dd93cb9991a89f0ec53d9443a0b78ad952269bc)
#7 0x559099e39604 in _start (/home/pauli/prj/external/pipewire/builddir/spa/plugins/audioconvert/test-fmt-ops+0x69604) (BuildId: f06f441b668c61295a3a84772591bed796ad0bdb)
```
Don't know if these are false alarms.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3571Audio corruption when connecting one source to multiple sinks, and a sink ove...2023-10-17T16:23:14Znyanpasu64Audio corruption when connecting one source to multiple sinks, and a sink overwrites memory<!-- 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.82
- 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.82
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: KDE Wayland
- Kernel version (`uname -r`): 6.5.6-arch2-1
## Description of Problem:
When a node's output source is connected to multiple nodes with sinks, and one JACK or PipeWire node overwrites its input buffers in-place, the audio gets corrupted in the other nodes as well.
## How Reproducible:
Always (if you launch the corrupting app before other listeners).
### Steps to Reproduce:
I've found multiple ways (both through everyday use and synthetic test cases) to trigger this bug.
#### Minimal corruptor
1. Clone and build https://github.com/nyanpasu64/jack-corruptor.
2. Run a program (like Audacity or REAPER) which records from the microphone.
3. Run `jack-corruptor` to overwrite the default input port (mic?) with -0.5, then watch as audio becomes garbled in the recording program (randomly alternating between -0.5 and actual audio).
#### Easy Effects corrupting audio
1. Enable an Easy Effects chain.
2. For the first effect in the chain (listening to "Easy Effects Sink" monitor_FL/FR), set the input gain to any nonzero number (I used negative).
3. Begin recording audio in Audacity, then use pavucontrol to have it listen to "Monitor of Easy Effects Sink" as well.
4. Replay the audio and note it's garbled (randomly alternating between the gain value and actual audio).
#### REAPER corrupting audio
1. Run `pw-loopback --name "loop1" --capture-props='media.class=Audio/Sink' --playback-props='media.class=Audio/Source'`, and route a microphone into its sink (input).
2. Launch REAPER (with JACK backend) and have it listen to loop1's source (output).
3. Arm a track for recording, then mute it to disable software playthrough. (This also causes REAPER to zero out input buffers.)
4. Try recording audio from the microphone in another program (eg. close/reopen Firefox, then open Google Voice and call an echo test number like `(804) 222-1111, press 3`).
Audio remains garbled and mostly silent.
- Closing REAPER but leaving loop1 running does not fix this.
- If you instead disconnect and reconnect the microphone to loop1 (with or without REAPER still listening to loop1), the issue stops (even though the previous and final states are the "same").
### Actual Results:
Whether it's legal or not, it's common for apps to overwrite input audio it receives from JACK or PipeWire. This also affects other apps listening to the same source node. I think this is because all sink nodes (and possibly the source node producing audio) share the same audio buffer through shared memory mapping.
Why does the issue not recur when I disconnect and reconnect the corrupting sink? I think the first sink that connects to a source (output) is the first one to get polled when it's ready, and any changes it makes to the audio buffer are likely to be heard by other clients. If you stop and restart the app corrupting memory (eg. reconnect microphone -> loop1), this link gets placed at the end of the list of sinks polled when a source (output) is ready, and other sinks will likely finish reading memory by the time your app gets called and starts corrupting memory.
Why does the microphone get corrupted, even when REAPER is listening to loop1 rather than the microphone? I suppose `pw-loopback` shares its input and output buffers? IDK.
### Expected Results:
If one app overwrites input audio, it should not corrupt the audio heard by other apps. This could be implemented using copy-on-write shared memory, read-only shared memory (though this will break existing apps dependent on mutating input buffers), or copying memory to each sink rather than merely mapping it in.
I don't know which fixes have acceptable CPU/memory/backwards-compat penalties.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/48b90140aab1a89193de11f8415a6b5f/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3570PipeWire refuses to use ALSA cards with any subdevice in use2023-10-15T16:57:12ZHector MartinPipeWire refuses to use ALSA cards with any subdevice in use`spa/plugins/alsa/alsa-udev.c` has a check (`check_pcm_device_availability`) that refuses to probe the entire ALSA card if *any* subdevice is in use.
For Apple laptops, the layout of our subdevices is:
* hw:0,0: Headphone jack (capture...`spa/plugins/alsa/alsa-udev.c` has a check (`check_pcm_device_availability`) that refuses to probe the entire ALSA card if *any* subdevice is in use.
For Apple laptops, the layout of our subdevices is:
* hw:0,0: Headphone jack (capture/playback)
* hw:0,1: Speakers (playback)
* hw:0,2: Speaker Sense (capture)
Speaker sense is opened persistently by an out of band daemon (`speakersafetyd`) and the kernel side is set up to feed it data (and actually power up the hardware) only when the speaker playback is started. That means that subdevice is always busy, and pipewire then refuses to use the entire card.
This trivial patch fixes the issue, but I don't understand the reasoning behind this check in the first place. The code even notes that with certain kernel config settings, the check cannot be done and always succeeds. Perhaps we should just get rid of this entirely? What purpose does it serve?
This is a blocker for enabling audio on Asahi systems (sorry for only noticing now, I wasn't expecting plugging in speakersafetyd to a separate subdevice to affect PipeWire...).
```
diff --git a/spa/plugins/alsa/alsa-udev.c b/spa/plugins/alsa/alsa-udev.c
index 3048d7363..b84db3ddd 100644
--- a/spa/plugins/alsa/alsa-udev.c
+++ b/spa/plugins/alsa/alsa-udev.c
@@ -349,6 +349,9 @@ static int check_pcm_device_availability(struct impl *this, struct card *card,
spa_log_debug(this->log, "card %u has %d PCM device(s)",
card->card_nr, *num_pcm_devices);
+
+ return 0;
+
/*
* Check if some pcm devices of the card are busy. Check it via /proc, as we
* don't want to actually open any devices using alsa-lib (generates uncontrolled
```https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3569Need to reload pipewire service to have sound2023-10-28T16:07:20ZNguyễn Hoàng HưngNeed to reload pipewire service to have sound<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.80
- 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.80
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Manjaro Linux
- Desktop Environment: xfce4
- Kernel version (`uname -r`): 6.1.55-1-MANJARO
## Description of Problem (this issue will only happen one time when booted up):
I switched from pulseaudio to pipewire, by installing manjaro-pipewire. Now, whenever I connect to a new bluetooth speaker, I need to reload pipewire service for it to have sound.
## How Reproducible:
I can reproduce every time (when computer boots up). after that, every's fine 'til the next time computer boots up
### Steps to Reproduce:
1. connect to bluetooth speaker
2. no sound
3. restart pipewire
4. sound show up
### Actual Results:
### Expected Results:
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: