Don't work with pipewire-pulseaudio #419
Comments
|
After checking in https://github.com/masmu/pulseaudio-dlna/blob/master/pulseaudio_dlna/pulseaudio.py and finding https://gist.github.com/saivert/25bff8f1d63167c7880fff654a0f3e0e it was easy to retrieve the Pulseaudio socket from PipeWire with $ systemctl --user status pipewire-pulse.socket
● pipewire-pulse.socket - PipeWire PulseAudio
Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.socket; enabled; vendor preset: enabled)
Active: active (running) since Sat 2021-04-24 19:21:34 CEST; 5h 2min ago
Triggers: ● pipewire-pulse.service
Listen: /run/user/1000/pulse/native (Stream)
CGroup: /user.slice/user-1000.slice/user@1000.service/pipewire-pulse.socket
Apr 24 19:21:34 pons systemd[2375]: Listening on PipeWire PulseAudio.
and then injecting it into $ diff /usr/lib/python3.9/site-packages/pulseaudio_dlna/pulseaudio.py.before /usr/lib/python3.9/site-packages/pulseaudio_dlna/pulseaudio.py
101a102
> '/run/user/1000/pulse/native',
et voilà, we're up and running: Unfortunately the device will not show up in Fedora 33 |
|
It's something that should be resolved at pipewire level - They do promise 100% pulse compatibility, but it isn't there yet. There is |
|
Now that this has been merged upstream, I'll just need to wait for a PipeWire version with Then we have a quick and dirty test for compatibility: $ pactl load-module module-loopback
Fehlgeschlagen: Entität nicht vorhanden
The same command could also help to identify the PipeWire Pulseaudio socket in another way: $ pactl info | head -n 1
Server-Zeichenkette: /run/user/1000/pulse/nativeIs this deterministic, do they retrieve this information from DBUS? How could |
|
There's another regression on early testing this a pre-1.0.0 Seems this is also asking for an issue upstream, since behaviour can be reproduced with: $ systemctl restart --user pipewire-pulse
$ id=$(systemctl show -p InvocationID --user --value pipewire-pulse); journalctl INVOCATION_ID=${id} + _SYSTEMD_INVOCATION_ID=${id} -fand in another terminal $ pulseaudio-dlna (--debug)Here's their homework: |
|
An update from Fedora 33, where As of https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/e7b04bca2c7f22b2db9f8c3c6da48bd724c38c31 the patch is available in that version. Click the three little dots next to parent ... I can also verify that the loopback module is working with which has the loopback appear in the Playback tab of then helps to get silence again. So off we go to test the interface with This cycle repeats four times. After the first time, it also outputs: This does not lead to the device appearing in After these four cycles, What is interesting here, is that the three endpoints that drop their connection, are equally accessible with curl: and that The DLNA media renderer is a Raspberry Pi 4 on Ubuntu 20.04 with a self-compiled |
|
We have a response from upstream about:
that reads as follows:
Seems we're getting there, eventually. |
|
As a temporary alternative (for chromecast), mkchromecast works with pipewire. I only got it to work with python3.8 tho. |
|
In the meantime, to switch back to regular pulseaudio in fedora 34:
|
I know, thank you |
|
what's the current status? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Versions
Distro: Fedora 34 Beta
Pulseaudio-dlna: 0.6.1 (from
cygn/pulseaudio-dlnaCOPR)Pipewire: 0.3.25
Steps to reproduce
pulseaudio-dlnaWhat I expect
pulseaudio-dlnawill work properly withpipewire-pulseaudioinstead ofpulseaudio.What really happens
pulseaudio-dlnastucks with message:Could not connect to pulseaudio! Application terminates!Logs
The text was updated successfully, but these errors were encountered: