pipewire issueshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues2023-07-03T07:52:36Zhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3322No audio after laptop resumes from suspend2023-07-03T07:52:36ZjasonjgwNo audio after laptop resumes from suspendThis appears to be a regression as of 0.3.72; earlier versions worked correctly.
I'm running Arch Linux (x86-64). Upon resuming from suspend, there is no audio output and the following error message appears repeatedly in the logs:
Jul 0...This appears to be a regression as of 0.3.72; earlier versions worked correctly.
I'm running Arch Linux (x86-64). Upon resuming from suspend, there is no audio output and the following error message appears repeatedly in the logs:
Jul 02 08:24:49 jpw pipewire[1635]: spa.alsa: front:0: snd_pcm_mmap_begin error: Streams pipe error
The audio device is an Intel HD Audio controller on the main board of the machine.
Restarting Pipewire restores audio output, so my working assumption is that the problem isn't in the kernel's ALSA driver. The only relevant update recently was with Pipewire itself. I'm also using Wireplumber.
In addition, I'm running the Orca screen reader, in case that makes any difference. I don't know what other details should be included in this report. I couldn't find any other obviously relevant errors in the logs.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3321Internal sound stop working after suspend2023-07-08T21:23:14ZGerardo Femat DelgadoInternal sound stop working after suspend<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
pipewire
Compiled with libpipewire 0.3.72
Linked with libpipewire 0.3.72
- Distribu...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
pipewire
Compiled with libpipewire 0.3.72
Linked with libpipewire 0.3.72
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
Fedora Linux 38 (Workstation Edition)
- Desktop Environment:
Gnome wayland
- Kernel version (`uname -r`):
6.3.8-200.fc38.x86_64
## Description of Problem:
I have a laptop in pipewire 0.3.72-2.fc38 after I suspend the laptop the internal speakers stop working and the jack 3.5 combo. I have no clue why.
I tested connecting devices like HDMI to TV and bluethoot headset. With them selected I suspend, and then they work fine. But if i suspend with the internal device selected like my output and wake the PC pipewire stop working in every device.
For solving I need to restart pipewire with systemctl restart pipewire.service.
The release that works grate under fedora is 0.3.67-1.fc38.
## How Reproducible:
Install all fedora updates, suspend the device with internal sound selected while playing something through output, wake up the system and the sound stop working.
### Steps to Reproduce:
1. Playing something.
2. Suspend the device.
3. Wake up the device.
### Actual Results:
The sound stop working after suspend and wake up the device.
### Expected Results:
Solve the problem while the 0.3.67-1 release works grate under fedora.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:
[pw-dump.log](/uploads/0416b4852844929e28fa497b5dbbf55a/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3320Having PulseAudio Volume Control open (`pavucontrol`) with "Show volume meter...2023-07-19T09:21:04ZAlex FollandHaving PulseAudio Volume Control open (`pavucontrol`) with "Show volume meters" enabled causes `pipewire-pulse` service to crash**Steps to reproduce**
1. Verify `pavucontrol` is not running.
2. Start the computer or run `systemctl --user restart pipewire-pulse pipewire`.
3. Verify the current `pipewire-pulse` status is `running` with `systemctl --user status pip...**Steps to reproduce**
1. Verify `pavucontrol` is not running.
2. Start the computer or run `systemctl --user restart pipewire-pulse pipewire`.
3. Verify the current `pipewire-pulse` status is `running` with `systemctl --user status pipewire-pulse`
4. Run `pavucontrol`.
5. If the "Show volume meters" setting is disabled in PulseAudio Volume Control, enable it.
6. Check the status of `pipewire-pulse` again with `systemctl --user status pipewire-pulse`.
**Expected behavior**
The systemd `pipewire-pulse.service` status remains `running`.
**Observed behavior**
The systemd `pipewire-pulse.service` status becomes `failed`. No audio can be heard from PulseAudio client applications.
**Output of `systemctl --user status --lines=50 pipewire-pulse`**
```
× pipewire-pulse.service - PipeWire PulseAudio
Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; disabled; preset: enabled)
Active: failed (Result: core-dump) since Sat 2023-07-01 19:12:21 PDT; 1h 27min ago
Duration: 625ms
TriggeredBy: × pipewire-pulse.socket
Process: 11998 ExecStart=/usr/bin/pipewire-pulse (code=dumped, signal=SEGV)
Main PID: 11998 (code=dumped, signal=SEGV)
CPU: 46ms
Jul 01 19:12:21 alex-pc systemd[1751]: pipewire-pulse.service: Main process exited, code=dumped, status=11/SEGV
Jul 01 19:12:21 alex-pc systemd[1751]: pipewire-pulse.service: Failed with result 'core-dump'.
Jul 01 19:12:21 alex-pc systemd[1751]: pipewire-pulse.service: Scheduled restart job, restart counter is at 5.
Jul 01 19:12:21 alex-pc systemd[1751]: Stopped PipeWire PulseAudio.
Jul 01 19:12:21 alex-pc systemd[1751]: pipewire-pulse.service: Start request repeated too quickly.
Jul 01 19:12:21 alex-pc systemd[1751]: pipewire-pulse.service: Failed with result 'core-dump'.
Jul 01 19:12:21 alex-pc systemd[1751]: Failed to start PipeWire PulseAudio.
```
**Full backtrace extracted from output of `coredumpctl gdb [process id]` with `bt full` entered**
```
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/bin/pipewire-pulse'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007ff51784d9b7 in _mm_andnot_ps (__B=..., __A=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/include/xmmintrin.h:254
254 return __builtin_ia32_andnps (__A, __B);
[Current thread is 1 (Thread 0x7ff5180826c0 (LWP 12000))]
(gdb) bt full
#0 0x00007ff51784d9b7 in _mm_andnot_ps (__B=..., __A=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/include/xmmintrin.h:254
n = <optimized out>
in = {<optimized out>, <optimized out>, <optimized out>, <optimized out>}
ma = {1.14088554e+33, 4.70911493e+33, 8.7824836e+32, 7.09570584e+22}
mask = {-0, -0, -0, -0}
#1 peaks_abs_max_sse (peaks=<optimized out>, src=0x7ff518579fdc, n_samples=4294966963, max=<optimized out>) at ../pipewire/spa/plugins/audioconvert/peaks-ops-sse.c:90
n = <optimized out>
in = {<optimized out>, <optimized out>, <optimized out>, <optimized out>}
ma = {1.14088554e+33, 4.70911493e+33, 8.7824836e+32, 7.09570584e+22}
mask = {-0, -0, -0, -0}
#2 0x00007ff517832a8a in resample_peaks_process (r=0x5635b091ca28, src=0x7ff518081940, in_len=0x7ff5180810fc, dst=0x5635b091cb20, out_len=0x7ff5180810f8)
at ../pipewire/spa/plugins/audioconvert/resample-peaks.c:44
s = 0x7ff518579040
d = 0x7ff5175f4020
m = <optimized out>
pd = 0x5635b0881c00
c = 0
i = <optimized out>
o = 1
end = <optimized out>
i_count = 0
o_count = 1
#3 0x00007ff51783dc45 in impl_node_process (object=<optimized out>) at ../pipewire/spa/plugins/audioconvert/audioconvert.c:2940
in_len = 1024
out_len = 50
src_datas = {0x7ff518579040, 0x0 <repeats 36 times>, 0x7ff51923427a <epoll_wait+106>, 0x0, 0x100000000, 0x7ff518081aa0, 0xffffffff00000020, 0x0, 0x7ff519434c59 <impl_pollfd_wait+121>, 0xb0901d2800000001, 0x5635, 0x0 <repeats 11 times>, 0x7ff519434b23 <impl_pollfd_add+51>, 0x0, 0x1919222b71, 0x5635b096c658, 0xbdd7efbcebb51c00, 0x7ff518081b70, 0x7ff519423207 <loop_add_source+71>, 0x5635b06efd00}
in_datas = <optimized out>
dst_datas = {0x5635b0a5c5a0, 0x0 <repeats 64 times>}
remap_src_datas = {0x0 <repeats 65 times>}
remap_dst_datas = {0x0 <repeats 65 times>}
out_datas = 0x5635b091cb20
dst_remap = <optimized out>
i = <optimized out>
j = <optimized out>
n_src_datas = <optimized out>
n_dst_datas = <optimized out>
n_mon_datas = <optimized out>
remap = <optimized out>
n_samples = <optimized out>
max_in = <optimized out>
n_out = 50
max_out = 50
quant_samples = <optimized out>
port = <optimized out>
ctrlport = <optimized out>
buf = <optimized out>
out_bufs = {0x5635b09216e8, 0x0 <repeats 64 times>}
bd = <optimized out>
dir = <optimized out>
tmp = <optimized out>
res = <optimized out>
in_passthrough = <optimized out>
mix_passthrough = <optimized out>
resample_passthrough = <optimized out>
out_passthrough = <optimized out>
in_avail = <optimized out>
flush_in = true
flush_out = true
draining = <optimized out>
in_empty = <optimized out>
io = <optimized out>
ctrlio = <optimized out>
ctrl = <optimized out>
__func__ = "impl_node_process"
#4 0x00007ff517817dc6 in impl_node_process (object=0x5635b0907f18) at ../pipewire/spa/plugins/audioconvert/audioadapter.c:1497
_f = <optimized out>
_res = <optimized out>
_n = <optimized out>
this = 0x5635b0907f18
status = <optimized out>
fstatus = <optimized out>
retry = <optimized out>
__func__ = "impl_node_process"
#5 0x00007ff519375669 in process_node (data=0x5635b0901710) at ../pipewire/src/pipewire/impl-node.c:1217
_f = <optimized out>
_res = <optimized out>
_n = <optimized out>
this = 0x5635b0901710
a = 0x7ff518f64000
status = <optimized out>
p = <optimized out>
data_system = 0x5635b06f2fb0
nsec = <optimized out>
cmd = 1
this = 0x5635b0901710
__func__ = "node_on_fd_events"
#6 node_on_fd_events (source=<optimized out>) at ../pipewire/src/pipewire/impl-node.c:1289
cmd = 1
this = 0x5635b0901710
__func__ = "node_on_fd_events"
#7 0x00007ff5194275b6 in loop_iterate (object=0x5635b06f3048, timeout=<optimized out>) at ../pipewire/spa/plugins/support/loop.c:483
s = <optimized out>
impl = 0x5635b06f3048
ep = {{events = 1, data = 0x5635b0901d28}, {events = 0, data = 0x0} <repeats 31 times>}
e = <optimized out>
i = 0
nfds = 1
#8 0x00007ff519357892 in do_loop (user_data=0x5635b06f2ee0) at ../pipewire/src/pipewire/data-loop.c:65
__clframe = {__cancel_routine = <optimized out>, __cancel_arg = <optimized out>, __do_it = <optimized out>, __cancel_type = <optimized out>}
this = 0x5635b06f2ee0
res = <optimized out>
cb = <optimized out>
m = <optimized out>
data = <optimized out>
iterate = <optimized out>
__func__ = "do_loop"
#9 0x00007ff5191b044b in start_thread (arg=<optimized out>) at pthread_create.c:444
ret = <optimized out>
pd = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140690664915312, 3042552264352246699, -120, 11, 140733411438560, 140690638512128, -3038978420961268821, -3038976351447897173}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#10 0x00007ff519233d64 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
```https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3319A2DP sink profiles are unavailable2023-07-02T12:05:44ZMn SnA2DP sink profiles are unavailableAfter updating the system last night, I am facing this issue. The pipewire version is 0.3.72.
I cannot connect to my bluetooth speaker (which only supports SBC codec). I learned from [Headset via PipeWire](https://wiki.archlinux.org/tit...After updating the system last night, I am facing this issue. The pipewire version is 0.3.72.
I cannot connect to my bluetooth speaker (which only supports SBC codec). I learned from [Headset via PipeWire](https://wiki.archlinux.org/title/Bluetooth_headset#Headset_via_PipeWire), I found that A2DP sink profiles (which is used by SBC codex) are missing, that's why after connecting the speaker it abruptly disconnects because it cannot access those codecs. I was able to connect my another bluetooth headset which uses mSBC codex (which doesn't use A2DP sink profiles), when I tried to use it with SBC codex it gives the same error like that of bluetooth speaker , which before the update can be done. I also reinstalled pipewire and pipewire-pulse but the issue persists.
I ran `pactl list | grep A2DP ` but there was no output
I tested this in a live iso which has pipewire version 0.3.57, the speaker (which only uses SBC codex) was working fine and the A2DP sink profiles were there but when I tried upgrade pipewire to 0.3.72, the same issue arises and the A2DP sink profiles became unavailable.
journal log : [here](https://gitlab.com/-/snippets/2565163/raw/main/journal-log.txt)
pw-dump log : [here](https://gitlab.com/-/snippets/2565162/raw/main/snippetfile1.txt)
OS: Arch Linux
Kernel: 6.3.9-arch1-1
DE: Plasma 5.27.6
pipewire version = 0.3.72https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3317Unexpected internal conversion?2023-07-30T13:08:40ZTaiko2kUnexpected internal conversion?- PipeWire version: 0.3.71
- Distribution: Arch Linux
- Desktop Environment: GNOME
- Kernel version: 6.3.7-arch1-1
## Description of Problem:
I have an application with the following pipeline: MyApp > MiniAudio Library > Pipewire Puls...- PipeWire version: 0.3.71
- Distribution: Arch Linux
- Desktop Environment: GNOME
- Kernel version: 6.3.7-arch1-1
## Description of Problem:
I have an application with the following pipeline: MyApp > MiniAudio Library > Pipewire Pulse > Pipiwire. While this works and there is nothing wrong with the sound of the audio itself, when running `pw-top`, I noticed there is an unexpected conversion going on that I'm trying to track down. I am supplying miniaudio with F32 at various samplerates, somewhere along the line this gets converted to S24 at often undesired samplerates.
![Screenshot_from_2023-06-30_12-56-05](/uploads/dcf38b4928812e275e26b968c610c252/Screenshot_from_2023-06-30_12-56-05.png)
In this screenshot, my application tauon.py is outputting F32@192hz to miniaudio. I would expect the format line to read as F32LE 2 192000, but in this example its reading as S24LE 2 44100. It seems to often take on the previous default samplerate of the device before I reconnect. (For example if I were to disconnect then reconnect, then the next unexpected new samplerete of my app reported by pw would take on 96000hz) (Not sure why in this case its also converting 192k to 96k since I'm pretty sure my device supports it, but that's a separate issue)
I contacted the developer of miniaudio but they said they they think it might be an internal Pipewire issue. Any ideas on what could be going on here?
[dump.txt](/uploads/0d6804a3a02f08c751f0605121b8b2a7/dump.txt)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3316Audio randomly cuts out for no reason2023-09-19T07:26:27ZGhost UserAudio randomly cuts out for no reason<!-- 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.72
- 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.72
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Void Linux
- Desktop Environment: Sway
- Kernel version (`uname -r`): 6.3.8
## Description of Problem:
Audio works great, very happy with pipewire thus far. The problem is that when I listen to Spotify, or some other audio source for a while, the audio just cuts out randomly. The audio doesn't return for around 1-2 minutes, or until I increase/decrease the volume; in both cases pipewire jumps back into life and continues to play audio just fine; atleast until the audio cuts out again at some random time.
I've noticed the problem occurs when Spotify stops playing one track and goes onto the next track, for example, when playing a playlist.
I've tried adding the following to /etc/wireplumber/main.lua.d/51-disable-suspension.lua with little success: [51-disable-suspension.lua](/uploads/e68ce97c94e6dba2b6a69831f2cd946f/51-disable-suspension.lua)
## How Reproducible:
### Steps to Reproduce:
1. Listen to music on Spotify for a while and you'll eventually come across this issue where Spotify continues to play, but pipewire stops producing audio
2. Either wait a bit for the audio to return, or increase/decrease the volume to make pipewire jump back into action
3. I noticed the audio sometimes specifically cuts out when Spotify stops playing one track and goes onto the next track, for example, when playing a playlist.
### Actual Results:
Audio cuts out randomly for a random unspecified amount of time
### Expected Results:
Audio doesn't cut out during playback
# Additional Info (as attachments):
[additional-errors.log](/uploads/a53bc4ded790936d65c4f49c557830c3/additional-errors.log)
[void-sway-pipewire-install.txt](/uploads/e1fcc868775c8603161669a1cd1cd4e3/void-sway-pipewire-install.txt)
- `pw-dump > pw-dump.log`:
[pw-dump.log](/uploads/7c5842645e1856fd2ed84a7dde35e30c/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3315No sound when resuming from suspend on 0.3.722023-07-15T21:30:00ZTasos SahanidisNo sound when resuming from suspend on 0.3.72<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version: 0.3.72 and master
- Distribution and distribution version: Ubuntu 20.04.6
- Kernel version: 6.3.9
- Sound c...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version: 0.3.72 and master
- Distribution and distribution version: Ubuntu 20.04.6
- Kernel version: 6.3.9
- Sound card: 01:02.0 Multimedia audio controller: Creative Labs EMU10k1 [Sound Blaster Live! Series] (rev 07)
## Description of Problem:
When resuming from S3, audio playback stops and pipewire spams the following line over and over.
```
[E][05922.833311] spa.alsa | [ alsa-pcm.c: 2264 spa_alsa_write()] front:0: snd_pcm_mmap_begin error: Streams pipe error
[E][05922.848323] spa.alsa | [ alsa-pcm.c: 2264 spa_alsa_write()] iec958:1: snd_pcm_mmap_begin error: Streams pipe error
```
Restarting pipewire only is enough to restore audio.
Bisecting indicated the following commit:
```
29e6544baeb18fc194eabec6e351e905cf4aa0a0 is the first bad commit
commit 29e6544baeb18fc194eabec6e351e905cf4aa0a0
Author: Wim Taymans <wtaymans@redhat.com>
Date: Mon Jun 5 16:49:58 2023 +0200
alsa: enable htimestamp mode
Use snd_pcm_htimestamp to get both the available space and the timestamp
when this was calculated. We can then use this to get a better estimate
of the delay in the device against the graph start and get a more
reliable delay between capture and playback.
spa/plugins/alsa/alsa-pcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
```
Reverting this commit on top of master "fixes" the issue.
## How Reproducible:
Always
### Steps to Reproduce:
1. Have presumably an emu10k1 card
2. Suspend to RAM
3. Resume
### Actual Results:
No audio and the same error messages are being spammed.
### Expected Results:
Working audio and no message spam.
# Additional Info (as attachments):
[pw-dump.log](/uploads/9660ea77f923cba491c3be490fcd25c4/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3314Document side effects of pw_stream_destroy2023-06-27T13:13:28ZJonas ÅdahlDocument side effects of pw_stream_destroypw_stream_destroy() may call back into the `process_stream` vfunc (or could at least). The documentation says nothing of value that lets one be prepared for it, or whether it should be considered a bug or not. Should probably spell it ou...pw_stream_destroy() may call back into the `process_stream` vfunc (or could at least). The documentation says nothing of value that lets one be prepared for it, or whether it should be considered a bug or not. Should probably spell it out anyhow.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3313Build failure with pipewire-0.3.72 (netjack2/peer.c:524: undefined reference ...2023-06-26T16:48:55ZSam JamesBuild failure with pipewire-0.3.72 (netjack2/peer.c:524: undefined reference to `opus_custom_encode_float')Not looked into this yet, although it's obviously related to (not necessarily caused by) 3be07c7de237d1d79de13cf73b8bd8e9eb1392cf.
```
FAILED: src/modules/libpipewire-module-netjack2-driver.so
x86_64-pc-linux-gnu-gcc -m32 -mfpmath=sse ...Not looked into this yet, although it's obviously related to (not necessarily caused by) 3be07c7de237d1d79de13cf73b8bd8e9eb1392cf.
```
FAILED: src/modules/libpipewire-module-netjack2-driver.so
x86_64-pc-linux-gnu-gcc -m32 -mfpmath=sse -o src/modules/libpipewire-module-netjack2-driver.so src/modules/libpipewire-module-netjack2-driver.so.p/module-netjack2-driver.c.o -Wl,--as-needed -Wl,--no-undefine
d -shared -fPIC -Wl,--start-group -Wl,-soname,libpipewire-module-netjack2-driver.so -O2 -pipe -march=native -fdiagnostics-color=always -frecord-gcc-switches -Wreturn-type -ggdb3 -Wl,-O1 -Wl,--as-needed -Wl,--
defsym=__gentoo_check_ldflags__=0 -Wl,-z,pack-relative-relocs -ggdb3 '-Wl,-rpath,$ORIGIN/../pipewire:XX' -Wl,-rpath-link,/var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/src/pi
pewire src/pipewire/libpipewire-0.3.so.0.372.0 -lm -ldl -Wl,--end-group -pthread
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: src/modules/libpipewire-module-netjack2-driver.so.p/module-netjack2-driver.c.o: in function `netjack2_send_opus':
/var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/../pipewire-0.3.72/src/modules/module-netjack2/peer.c:524: undefined reference to `opus_custom_encode_float'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: src/modules/libpipewire-module-netjack2-driver.so.p/module-netjack2-driver.c.o: in function `netjack2_cleanup':
/var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/../pipewire-0.3.72/src/modules/module-netjack2/peer.c:212: undefined reference to `opus_custom_encoder_destroy'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/../pipewire-0.3.72/src/modules/module-netjack2/peer
.c:219: undefined reference to `opus_custom_decoder_destroy'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/../pipewire-0.3.72/src/modules/module-netjack2/peer
.c:224: undefined reference to `opus_custom_mode_destroy'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: src/modules/libpipewire-module-netjack2-driver.so.p/module-netjack2-driver.c.o: in function `netjack2_recv_opus':
/var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/../pipewire-0.3.72/src/modules/module-netjack2/peer.c:891: undefined reference to `opus_custom_decode_float'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: src/modules/libpipewire-module-netjack2-driver.so.p/module-netjack2-driver.c.o: in function `netjack2_init':
/var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/../pipewire-0.3.72/src/modules/module-netjack2/peer.c:158: undefined reference to `opus_custom_mode_create'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/../pipewire-0.3.72/src/modules/module-netjack2/peer.c:169: undefined reference to `opus_custom_encoder_ctl'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/../pipewire-0.3.72/src/modules/module-netjack2/peer.c:171: undefined reference to `opus_custom_encoder_ctl'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/../pipewire-0.3.72/src/modules/module-netjack2/peer.c:173: undefined reference to `opus_custom_encoder_ctl'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/../pipewire-0.3.72/src/modules/module-netjack2/peer.c:175: undefined reference to `opus_custom_encoder_ctl'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/../pipewire-0.3.72/src/modules/module-netjack2/peer.c:166: undefined reference to `opus_custom_encoder_create'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/media-video/pipewire-0.3.72/work/pipewire-0.3.72-abi_x86_32.x86/../pipewire-0.3.72/src/modules/module-netjack2/peer.c:182: undefined reference to `opus_custom_decoder_create'
collect2: error: ld returned 1 exit status
```
Full log: [build.log](/uploads/bfe2e336f1bb66bfcb448ae49cc06116/build.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3308pw-top showing different frequency to /proc/asound/card3/stream02023-06-26T09:47:52ZFumo Vitepw-top showing different frequency to /proc/asound/card3/stream0
- PipeWire version: 0.3.48
- Distribution and distribution version: KDE Neon 5.27
- Desktop Environment: KDE
- Kernel version: 5.19.0-45-generic
## Description of Problem:
pw-top shows for example playing 96kHz for an audio device, usi...
- PipeWire version: 0.3.48
- Distribution and distribution version: KDE Neon 5.27
- Desktop Environment: KDE
- Kernel version: 5.19.0-45-generic
## Description of Problem:
pw-top shows for example playing 96kHz for an audio device, using cat /proc/asound/card3/stream0 only shows the default clock rate that has been set in pipewire.conf. Thus making it seem like pipewire is down- / upsampling all audio that isn't exactly 96kHz if 96kHz is set as the default.
## How Reproducible:
I don't know.
### Steps to Reproduce:
1.Install pipewire
2.Set multiple allowed clock rates in pipewire.conf [(I used this guide)](https://lowtechlinux.com/2022/04/26/go-full-pipewire-on-ubuntu-22-04-and-all-family-derivatives/)
3.play any media file that isn't the default clock rate
4.use pw-top and cat /proc/asound/yourcard/stream0
5.compare the values
### Actual Results:
pw-top shows a different frequency
### Expected Results:
pw-top showing the same frequency
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:[pw-dump.log](/uploads/55a8a7bf63a658d644a33246466521ac/pw-dump.log)
- `pw-top, when a 44.1kHz file is playing`:[pw-top.txt](/uploads/ea802c063a2d5306549ef97b23cdcdab/pw-top.txt)
- `cat /proc/asound/card3/stream0, at the same time`: [cat_proc_asound_card3_stream0.txt](/uploads/bb9f40508cdb1dafe165b34966a314d1/cat_proc_asound_card3_stream0.txt)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3307Repeated Input/output error.2023-06-26T09:50:39ZAshesh AmbastaRepeated Input/output error.<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
```
pipewire
Compiled with libpipewire 0.3.71
Linked with libpipewire 0.3.71
```
- ...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
```
pipewire
Compiled with libpipewire 0.3.71
Linked with libpipewire 0.3.71
```
- Bitwig version: 4.4.10
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
```
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="23.05.1194.b6c73c5fe53"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 23.05 (Stoat)"
SUPPORT_END="2023-12-31"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="23.05 (Stoat)"
VERSION_CODENAME=stoat
VERSION_ID="23.05"
```
- Desktop Environment: xmonad
- Kernel version (`uname -r`): 6.1.34
## Description of Problem:
I've been noticing issues with `bitwig`. The issue seems to happen when a synth has been playing for a few minutes.
Bitwig's audio stops and it displays the message indicating that the audio appears to be "hung".
When I inspect the `pipewire` logs; I see:
```
Jun 23 18:18:57 pegasus pipewire[2689]: pw.link: 0x5573121fe330: port 0x55731386caf0 can't set io:1 (Spa:Enum:IO:Buffers): Input/output error
Jun 23 18:18:57 pegasus pipewire[2689]: pw.link: 0x5573122aa160: port 0x557311fb97a0 can't set io:1 (Spa:Enum:IO:Buffers): Input/output error
Jun 23 18:18:57 pegasus pipewire[2689]: pw.link: 0x557311fba470: port 0x5573121385d0 can't set io:1 (Spa:Enum:IO:Buffers): Input/output error
Jun 23 18:18:57 pegasus pipewire[2689]: pw.link: 0x5573122aa160: port 0x557311fb97a0 can't set io:1 (Spa:Enum:IO:Buffers): Input/output error
Jun 23 18:18:57 pegasus pipewire[2689]: pw.link: 0x557311fba470: port 0x5573121385d0 can't set io:1 (Spa:Enum:IO:Buffers): Input/output error
Jun 23 18:18:57 pegasus pipewire[2689]: pw.link: 0x557311fba470: port 0x5573121385d0 can't set io:1 (Spa:Enum:IO:Buffers): Input/output error
```
I'm not sure what that means.
## How Reproducible:
Very, I just need to run `pw-jack bitwig-studio` and the problem happens pretty regularly.
### Steps to Reproduce:
1. Open `bitwig`.
2. Loop over some synth.
### Actual Results:
Pipewire starts logging errors, audio stops, once even X seems to have crashed (keyboard became unresponsive within X).
### Expected Results:
Audio shouldn't hang.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: https://gist.github.com/asheshambasta/c36ac3b5ea8a4389d7772c4885648646https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3306Cannot control playback volume from pulseaudio tools.2023-06-23T14:28:38ZDit KozmajCannot control playback volume from pulseaudio tools.PipeWire 0.3.71\
Pipewire-pulse 0.3.71\
Wireplumber\
Kernel version 6.1.0-1014-oem
## Description of the problem
After the update from pulseaudio to pipewire, and keeping the default configuration, there is an issue related to the volum...PipeWire 0.3.71\
Pipewire-pulse 0.3.71\
Wireplumber\
Kernel version 6.1.0-1014-oem
## Description of the problem
After the update from pulseaudio to pipewire, and keeping the default configuration, there is an issue related to the volume control from the pulseaudio tools.
## How Reproducible:
When using pulseaudio tools like paplay to play audio from terminal, the --volume option doesn't affect the volume in any way.
For example:
```
~# paplay --volume=60000 some_audio.wav
~# paplay --volume=10000 some_audio.wav
~# paplay --volume=0 some_audio.wav
```
play the audio with the same volume in the output. There is no difference.\
Playing the same files, using in this case the pipewire tools, like pw-play:
```
~# pw-play --volume 0,05 some_audio.wav
~# pw-play --volume 0,5 some_audio.wav
~# pw-play --volume 1 some_audio.wav
```
the volume change as expected.
## Question:
As pipewire-pulse is a drop-in replacement for the PulseAudio daemon, I check the pipewire-pulse documentation and configuration files, but didn't find anything to allow volume control.
Is possible from pulseaudio tools to control volume of the playback or record? Or this feature is not implemented? Or I'm missing something in the configuration files?https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3305Bluetooth LE Audio support (BAP Profile)2023-07-14T09:16:46ZPeter RobinsonBluetooth LE Audio support (BAP Profile)Bluetooth LE is a low powered variation of Bluetooth with less bandwidth. BT-LE (previously BT-Smart) arrived as part of BT 4.0.
LE Audio, AKA Auracast, was introduced in 2020 as part of Bluetooth 5.2, adds support for multiple sources ...Bluetooth LE is a low powered variation of Bluetooth with less bandwidth. BT-LE (previously BT-Smart) arrived as part of BT 4.0.
LE Audio, AKA Auracast, was introduced in 2020 as part of Bluetooth 5.2, adds support for multiple sources (one headset multiple hosts) and multiple destinations (broadcast/multicast to multiple endpoints) generally Multi-Stream Audio and Broadcast Audio.
It's default codec is LC3 (Low Complexity Communication Codec) which has [https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4376 MR4376] in progress in gstreamer.
The core pieces are now upstream in bluez git to support BAP (the Audio profile), BIG (Broadcast Isochronous Group), BIS (Broadcast Isochronous Stream).
BAP seems to be the piece that pipewire would support similar to A2DP/HSP/HFP so it seems all the dependent pieces are falling into place to be able support this in pipewire.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3299client side environment variable PIPEWIRE_AUTOCONNECT= is missing documentati...2023-06-26T09:53:17ZDreamcat 4client side environment variable PIPEWIRE_AUTOCONNECT= is missing documentation, seems broken. But would really love it to work!!! (tears of desperation)<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version: `0.3.71`
- Distribution and distribution version: `Ubuntu 23.04`
- Desktop Environment: KDE Plasma, `plasma...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version: `0.3.71`
- Distribution and distribution version: `Ubuntu 23.04`
- Desktop Environment: KDE Plasma, `plasmashell 5.27.5`
- Kernel version (`uname -r`): `6.3.8-x64v3-xanmod1`
## Description of Problem:
**Long story short:**
Can the environment variable `PIPEWIRE_AUTOCONNECT` be set to `true` value on a per-client application basis? When the global server configuration is set to `false`? This this an undocumented feature currently. But can it be fixed / improved / and documented? And can it have a true both ways settable functionality? Because ATM it seems like it does not work. Or was never fully implemented to be both ways.
However I would dearly love to try out this feature. To see how well it resolves my issues here.
**Detailed description:**
Definately cannot use here `node.autoconnect = true` in my global pipewire daemon / server settings. It just causes far too many crashes. Either my DAW's audio engine to crash, or other types of client crashes. This is just how it is for the set(s) of applications I am currently running. And that is not going to change very much.
Now this is where things gets difficult:
Since many client programs will do a whole routine whereby they probe / test the available audio endpoints when they startup for the first time ever. And so (most of those times) am there chasing, trying to catch those nodes appearing before they timeout in qpwgraph. Which is never successful or even possible. Since for most of these programs, they will have a very short duration timeouts (not to delay program load times too much). And although visible it seem that every created test node is left just hanging there, suspended or frozen state (waiting to be connected). But in reality, the client app has already have internally timed that one out, and moved on to creating the next variation(s) of test node(s). Many times with some other channels configurations etc. To test for the surround etc. It cannot be intervened manually.
This translated into a critical need to first launch a program with `node.autoconnect` property = true. To pass these challenges for the client. Even though my DAW's audio engine might crash. But anyhow let the client program and pwgraph to go through those probe tearup / teardown test dummy nodes. And have pipewire always trying to be autoconnecting them up the default virtual sink. As soon as they appear. But then (for all other stable, long term clients, and all other default behaviour). Have `node.autoconnect` property set false. Just in the global server settings.
Can we have this? Is this an achievable goal (dynamically runtime). Without having to restart the whole pipewire server? Because if yes, then you already created some `PIPEWIRE_AUTOCONNECT` env var to be set... on starting of the client process? If could have that settable to a `TRUE` state. or `1` instead of `0`. Things like this. But it's not ever been documented.
## How Reproducible:
YES 100%. Here is how:
### Steps to Reproduce:
Server Pre-configuration:
1. Set the property `node.autoconnect = false` into all pipewire server configurations
Control case, to check the server pre-configuration:
2. Launch client program, WITHOUT any special overrides. To double check it's defaulting to `false` setting at runtime.
2.2. For example: `paplay long-enough-lasting-sound.ding.mp3`
3. Then go to another terminal (while the client application is still running). And check the client's properties by greping / searching within the whole `pw-dump` command. For example:
```sh
clear
_program_name="paplay"
pw-dump | grep -C20 -i $_program_name | grep -C20 -i autoconnect
```
So that was the default global case tested (should `=false`).
If not `=false`, then you cannot yet proceed to perform the actual test case.
Actual Test Case:
1. Set env variable `PIPEWIRE_AUTOCONNECT=true` on the client program at process creation. For example:
```sh
PIPEWIRE_AUTOCONNECT=true paplay long-enough-lasting-sound.ding.mp3
```
2. Check output of `pw-dump` below:
### Actual Results:
```sh
"application.process.host": "apex",
"application.process.id": 528958,
"application.process.machine-id": "d9bcdde265724512acdd4fed8edd4a9a",
"application.process.session-id": 4,
"application.process.user": "id",
"audio.adapt.follower": "",
"client.api": "pipewire-pulse",
"client.id": 444,
"clock.quantum-limit": 8192,
"factory.id": 6,
"factory.mode": "split",
"library.name": "audioconvert/libspa-audioconvert",
"media.artist": "Zoo",
"media.class": "Stream/Output/Audio",
"media.comment": "LAME settings: 320 kbps qval=2",
"media.date": 1984,
"media.format": "MPEG-1/2 Audio",
"media.name": "11-12 Where Have All the Good Times.mp3",
"media.software": "LAME 3.98 (Max 0.9.1)",
"media.title": "Where Have All the Good Times Gone?",
"node.autoconnect": false, <------------------------------- HERE <==========================
"node.latency": "256/96000",
"node.lock-quantum": true,
"node.name": "paplay", <----------------------------------- HERE <==========================
"node.pause-on-idle": false,
"node.rate": "1/44100",
"node.want-driver": true,
"object.id": 254,
"object.register": false,
"object.serial": 1612,
"pulse.server.type": "unix",
"stream.is-live": true,
"window.x11.display": ":0"
},
"params": {
"EnumFormat": [
{
"mediaType": "audio",
"mediaSubtype": "raw",
"format": "F32LE",
"rate": 44100,
```
And to double check it was set `PIPEWIRE_AUTOCONNECT=true` within the client's process environment space:
```sh
θ62° [id:~] [venv] 2 $ ps -aux | grep -i paplay
id 538659 0.0 0.0 84284 6568 pts/1 S+ 15:32 0:00 paplay 11-12 Where Have All the Good Times.mp3
θ64° [id:~] [venv] 1 $ grep --binary-files=text -i -o "pipewire_autoconnect=...." /proc/538659/environ
PIPEWIRE_AUTOCONNECT=true
```
### Expected Results:
Well (for this feature)... would dearly like it to behave in the following way:
For the stream property `"node.autoconnect": true,` to appear in the output of `pw-dump` for that client process. If it's environment variable was set to be `PIPEWIRE_AUTOCONNECT=true`
# Additional Info (as attachments):
- `[pw-dump.log](/uploads/de51197833e4bdcb028d60b780765f07/pw-dump.log)`:
Attached.
# References / Links
https://github.com/PipeWire/pipewire/blob/master/src/pipewire/stream.c#L2010
https://github.com/PipeWire/pipewire/blob/master/NEWS#L3669
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/964#note_858741https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3297Incorrect buffer size in Carla with Jack2023-06-19T14:56:11ZTasos SahanidisIncorrect buffer size in Carla with Jack- PipeWire version (`pipewire --version`): 0.3.71 (including ce71b37b58d5e251ae7acda0799f696688df11c2) but also with latest master (abb300750f65c362eb100891f71a418c01b07d01).
## Description of Problem:
PW seems to tell Carla to always e...- PipeWire version (`pipewire --version`): 0.3.71 (including ce71b37b58d5e251ae7acda0799f696688df11c2) but also with latest master (abb300750f65c362eb100891f71a418c01b07d01).
## Description of Problem:
PW seems to tell Carla to always expect a buffer size of 1024, but it sends data of other sizes, depending on what the graph is running at. This workflow functioned correctly with 0.3.70.
Bisecting it revealed 045cb95a27534c694c9c0df0c8d668fd85207766 to be the first bad commit.
## How Reproducible:
Always
### Steps to Reproduce:
1. Make sure the graph isn't running at 1024 quantum
2. Open Carla with Jack and host a plugin (in my case noise-suppression-for-voice LV2)
3. Observe the log
### Actual Results:
If quantum < 1024, then the following is spammed:
```
Carla assertion failure: "nframes == pData->bufferSize" in file CarlaEngineJack.cpp, line 2249, v1 256, v2 1024
```
If quantum > 1024:
```
Carla assertion failure: "nframes == pData->bufferSize" in file CarlaEngineJack.cpp, line 2249, v1 2048, v2 1024
free(): corrupted unsorted chunks
Aborted (core dumped)
```
### Expected Results:
Audio works in Carla and it doesn't crash
# Additional Info (as attachments):
[pw-dump.log](/uploads/dae17c85c9e2c0a10c378ce8b8b952dd/pw-dump.log)
[rnnoise.carxp](/uploads/0efefb5f675923ccb959423d491b0051/rnnoise.carxp)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3296packaging of client configs and modules2024-01-11T07:48:23ZThomas Weißschuhpackaging of client configs and modulesHow are the client configuration libraries (client.conf, client-rt.conf) and the modules used by clients (module-client-device, module-client-node) supposed to be packaged in relation to libpipewire and the pipewire daemon?
Is it valid ...How are the client configuration libraries (client.conf, client-rt.conf) and the modules used by clients (module-client-device, module-client-node) supposed to be packaged in relation to libpipewire and the pipewire daemon?
Is it valid to have libpipewire installed but not the client configurations and modules?
At the moment both ArchLinux and Debian are packaging libpipewire in a way that does not guarantee that the configurations and modules are also installed. Only the full pipewire daemon pulls them in.
This leads to errors on startup:
```
[W][00355.592783] pw.conf | [ conf.c: 939 try_load_conf()] can't load config client.conf: No such file or directory
[E][00355.593459] pw.conf | [ conf.c: 963 pw_conf_load_conf_for_context()] can't load default config client.conf: No such file or directory
```
(This is a followup to https://github.com/mpv-player/mpv/issues/11790)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3294PipeWire as Bluetooth sink has audio stuttering heavily2023-06-19T15:24:40ZBart RibbersPipeWire as Bluetooth sink has audio stuttering heavilyThis is happening on a RPi3. PipeWire is configured as a Bluetooth sink and everything played to it (e.g. by an Android phone) is played on attached USB speakers. However no matter what audio is played, it stutters and crackles heavily, ...This is happening on a RPi3. PipeWire is configured as a Bluetooth sink and everything played to it (e.g. by an Android phone) is played on attached USB speakers. However no matter what audio is played, it stutters and crackles heavily, making it unable to use properly.
`pw-top` output:
```
S 28 0 0 --- --- --- --- 0 Dummy-Driver
S 29 0 0 --- --- --- --- 0 Freewheel-Driver
R 39 2048 48000 9.6ms 1.6ms 0.23 0.04 0 S16P 6 48000 alsa_output.usb-0d8c_USB_Sound_Device-00.analo
R 52 1200 48000 136.4us 305.6us 0.00 0.01 0 S16LE 6 48000 + PipeWire
R 76 512 48000 145.5us 9.3ms 0.00 0.22 0 S16LE 2 44100 + bluez_input.22_22_02_5A_81_E8.2
```
`alsa_output.usb-0d8c_USB_Sound_Device-00.analo` has been cut off, but it's the name of the output device.
Interestingly enough audio played over the network using the pulseaudio-zeroconf thing plays flawlessly, it's just Bluetooth that has this issue.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3293Segfault in libpipewire-0.3.so.0`tee_process at impl-port.c:186:142023-06-16T19:07:27ZNiklāvs KoļesņikovsSegfault in libpipewire-0.3.so.0`tee_process at impl-port.c:186:14- PipeWire version (`pipewire --version`): present in current git master, first noticed in a build of commit a0a32af38
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Gentoo Linux using custom ebuilds for ...- PipeWire version (`pipewire --version`): present in current git master, first noticed in a build of commit a0a32af38
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Gentoo Linux using custom ebuilds for PipeWire and WirePlumber
- Desktop Environment: KDE (Plasma 5.27.5)
- Kernel version (`uname -r`): 6.4.0-rc6 with EEVDF scheduler
## Description of Problem:
Randomly PipeWire crashes with a segfault. All stack traces point to the same tee_process at impl-port.c:186:14.
## How Reproducible:
Happens about 3-4 times per day.
### Steps to Reproduce:
Currently not known what triggers the crash. It may be relevant that EasyEffects is being used. I have the core files and can provide other debug information such as the CPU register values, if needed.
# Additional Info (as attachments):
- LLDB stack trace of the first crash (all look the same from what I can tell): [PW_a0a32af38_crash.txt](/uploads/ac9c5a9b5aee2ef571728fd60f72fadd/PW_a0a32af38_crash.txt)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3292how to record specific applications?2023-07-31T15:41:15ZBETLOGhow to record specific applications?I am having trouble figuring out how to use loopback (as suggested by the wiki) to substitute for pulseaudio's module-virtual-sink.
Unlike pulse I can't just assign the desired application to the module in pavucontrol-qt. My best guess i...I am having trouble figuring out how to use loopback (as suggested by the wiki) to substitute for pulseaudio's module-virtual-sink.
Unlike pulse I can't just assign the desired application to the module in pavucontrol-qt. My best guess is that I need to do some stream.rules matching, or define a master/slave.
...But how do i define an application as an input?
Can I get some assistance?
The embedded source example that seems most pertinent
```
context.modules = [
{
name = libpipewire-module-loopback
args = {
node.description = "CM106 Stereo Pair 2"
#target.delay.sec = 1.5
capture.props = {
node.name = "CM106_stereo_pair_2"
media.class = "Audio/Sink"
audio.position = [ FL FR ]
}
playback.props = {
node.name = "playback.CM106_stereo_pair_2"
audio.position = [ RL RR ]
target.object = "alsa_output.usb-0d8c_USB_Sound_Device-00.analog-surround-71"
node.dont-reconnect = true
stream.dont-remix = true
node.passive = true
}
}
}
]
```https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3290Debian/sid & pipewire 0.3.71 no network sink2023-06-19T14:54:57ZPascal ObryDebian/sid & pipewire 0.3.71 no network sinkI'm on GNU/Debian/sid and do regular updates. Yesterday I had an issue migrating pipewire from 0.3.65 to 0.3.71.
After the migration I cannot connect from my client computer to a remote sink. Actually the sink which was displayed in GNO...I'm on GNU/Debian/sid and do regular updates. Yesterday I had an issue migrating pipewire from 0.3.65 to 0.3.71.
After the migration I cannot connect from my client computer to a remote sink. Actually the sink which was displayed in GNOME control is not listed anymore.
I have done a:
`$ pactl unload-module module-zeroconf-discover`
and
`$ pactl load-module module-zeroconf-discover`
Still no sink listed.
I have then reverted to 0.3.65 and all is working fine.
For the record on the server I have pipewire 0.3.71.
I haven't found a similar issue, so reporting.
If needed I can do some testing to help on this issue, just let me know.