Close this. Works now :)
Seems to happen when the sound is over bluetooth devices. Pipewire then looks frozen. Not able to play any sound. It then does not reply anymore to pulsemixer or pavucontroll "Connection to pulseaudio failed"
I also got this in my logs :
[W][00093.741378] mod.protocol-pulse | [ reply.c: 73 reply_error()] client 0xffff84a32030 [Music Player Daemon]: ERROR command:-1 (invalid) tag:3 erro
r:25 (I/O error)
Logs continiously output :
2022/01/16 18:11:44 command 'setvol' failed: problems setting volume
2022/01/16 18:11:44 Volume changed to 0
2022/01/16 18:11:44 command 'setvol' failed: problems setting volume
2022/01/16 18:11:44 Volume changed to 0
2022/01/16 18:11:44 command 'setvol' failed: problems setting volume
2022/01/16 18:11:44 Volume changed to 0
2022/01/16 18:11:44 command 'setvol' failed: problems setting volume
2022/01/16 18:11:44 Volume changed to 0
2022/01/16 18:11:44 command 'setvol' failed: problems setting volume
2022/01/16 18:11:44 Volume changed to 0
2022/01/16 18:11:44 command 'setvol' failed: problems setting volume
2022/01/16 18:11:44 Volume changed to 0
2022/01/16 18:11:44 command 'setvol' failed: problems setting volume
2022/01/16 18:11:44 Volume changed to 0
2022/01/16 18:11:45 command 'setvol' failed: problems setting volume
2022/01/16 18:11:45 Volume changed to 0
2022/01/16 18:11:45 command 'setvol' failed: problems setting volume
2022/01/16 18:11:45 Volume changed to 0
2022/01/16 18:11:45 command 'setvol' failed: problems setting volume
2022/01/16 18:11:45 Volume changed to 0
2022/01/16 18:11:45 command 'setvol' failed: problems setting volume
2022/01/16 18:11:45 Volume changed to 0
2022/01/16 18:11:45 command 'setvol' failed: problems setting volume
2022/01/16 18:11:45 Volume changed to 0
2022/01/16 18:11:45 command 'setvol' failed: problems setting volume
2022/01/16 18:11:45 Volume changed to 0
2022/01/16 18:11:45 command 'setvol' failed: problems setting volume
2022/01/16 18:11:45 Volume changed to 0
2022/01/16 18:11:45 command 'setvol' failed: problems setting volume
2022/01/16 18:11:45 Volume changed to 0
2022/01/16 18:11:45 command 'setvol' failed: problems setting volume
2022/01/16 18:11:45 Volume changed to 0
2022/01/16 18:11:45 command 'setvol' failed: problems setting volume
2022/01/16 18:11:45 Volume changed to 0
2022/01/16 18:11:45 command 'setvol' failed: problems setting volume
2022/01/16 18:11:46 Volume changed to 0
2022/01/16 18:11:46 command 'setvol' failed: problems setting volume
2022/01/16 18:11:46 Volume changed to 0
2022/01/16 18:11:46 command 'setvol' failed: problems setting volume
Hey there o/
Every sms I send using this argument have an extra line return at the end.
I understand the problem is caused by vi/vim/kak that end the file with this. But in the same time, most text editor would do so.
It is possible to handle this on the ModemManager side?
Thanks for help!
Hey there,
When a loopback node doesn't target anything specifically, I'd expect for it to grab the last filter, for the default source. Atm it just grab the default source.
Thanks!
ah, yes you right!
for the record, here my full configuration to playback the audio from my default device, with the full chain (after echo-cancel and capture-merger)
context.modules = [
{ name = libpipewire-module-loopback
args = {
audio.position = [ FL FR ]
node.description = "Ears Loopback"
capture.props = {
node.name = ears-input
stream.dont-remix = true
node.passive = true
}
playback.props = {
media.class = "Audio/Source"
node.name = ears-source
filter.smart = true
filter.smart.name = ears-source
filter.smart.disabled = false
filter.smart.before = [ echo-cancel-source ]
}
}
},
{ name = libpipewire-module-loopback
args = {
audio.position = [ FL FR ]
node.description = "Ears Loopback Playback"
capture.props = {
node.name = ears-source-playback
target.object = "ears-source"
}
playback.props = {
node.name = ears-sink-playback
stream.dont-remix = true
node.passive = true
}
}
}
]
The problem was occuring with both OBS, or qutebrowser. Both asking through xdg-desktop-portal-wlr. And it was not always causing a crash of Wireplumber. But screen-sharing was broken.
But today, I can't reproduce the issue anymore. It seems it works.. I modified my config yersterday a bit. Maybe some smart.filter rules was causing this?
it does! thanks
And here the wireplumber logs wireplumber.log
(sorry for double notification. I forgot this one on my last comment)
Yes of course! Here the dump just after Qutebrowser display "Success" After "Screen capture", on the page: https://mozilla.github.io/webrtc-landing/gum_test.html
I think you (or me?) reverted the loopback order. Without any --target I got this:
└─ Streams:
37. output.loopback-1-sink
71. output_FL > Loopback 2 Sink:playback_FL [active]
72. output_FR > Loopback 2 Sink:playback_FR [active]
39. output.loopback-2-sink
101. output_FL > ALC887-VD Analog:playback_FL [active]
102. output_FR > ALC887-VD Analog:playback_FR [active]
170. pw-play
168. output_FL > Loopback 1 Sink:playback_FL [active]
169. output_FR > Loopback 1 Sink:playback_FR [active]
This is what I expect. The problem is that I can't manually by-pass the loopback-1 with --target.
Take this config:
$ cat pipewire.conf.d/*
context.modules = [
{ name = libpipewire-module-echo-cancel
args = {
sink.props = {
filter.smart = true
filter.smart.name = echo-cancel-sink
filter.smart.disabled = false
}
source.props = {
filter.smart = true
filter.smart.name = echo-cancel-source
filter.smart.disabled = false
}
}
}
]
context.modules = [
{ name = libpipewire-module-loopback
args = {
audio.position = [ FL FR ]
node.description = "Ears Loopback"
capture.props = {
node.name = ears-source
filter.smart = true
filter.smart.name = ears-source
filter.smart.disabled = false
}
playback.props = {
node.name = ears-sink
stream.dont-remix = true
node.passive = true
}
}
}
]
edit: adding .before or .after doesn't help.
Here, what pavucontrol gives:
I'd expect "Ears loopback input from" to target "Echo-Cancel Source", but instead it targets "BIRD UM1 Mono" which is the default source.
Nah, it does not work for me. With, or without --target loopback-2-sink
, it targets loopback-1-sink
Here the pw-dump:
Right! The config that cause the issue is this one:
context.modules = [
{ name = libpipewire-module-echo-cancel
args = {
sink.props = {
filter.smart = true
filter.smart.name = echo-cancel-sink
filter.smart.disabled = false
}
source.props = {
filter.smart = true
filter.smart.name = echo-cancel-source
filter.smart.disabled = false
}
}
}
]
It works if I comment the source.props
parameter.
Why does this audio source smart filter might cause an issue with screen sharing?
Hey there,
When a loopback node doesn't target anything specifically, I'd expect for it to grab the last filter, for the default source. Atm it just grab the default source.
Thanks!
Hey there,
Taking this example from the docs/
: https://paste.sr.ht/~stacyharper/d909ebb4ff9c44998b59a0d0b408135e6ae1ab9c
We should be able to pw-play --target loopback-2-sink ...
.
If I understand correct, get-filter-from-target.lua
currently override this and re-target input.loopback-1-sink
.
This is an easy to reproduce example, but in my personal situation, I'd like to use one loopback node to merge different streams using a similar pw-play --target
command.
Thanks!
Hey there,
I'm trying this 0.4.81 and noticed OBS now can't have access to my screenshare. If I re-configure, and pickup my output, wireplumber crash.
Here the full wireplumber log with debug mode:
https://paste.sr.ht/~stacyharper/ff6cb258833829f3c39afac04a133d4c764ee427
Also, now I can't screenshare with qutebrowser too. Tried: https://mozilla.github.io/webrtc-landing/gum_test.html
Both was working with 0.4.17.
Context is Alpine Linux edge on Sway.
Willow (cdd47271) at 05 Jan 11:54
Willow (cdd47271) at 05 Jan 09:11
docs-policy: add filter.smart = true
fixes: #552
Willow at 05 Jan 09:10