-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CRITICAL Could not connect to pulseaudio! Application terminates! #41
Comments
It seems this is my issue:
How can I fix this? |
You cannot. Does not work with pipewire. In Fedora the workaround is to fall back to pulse. |
Thanks. I was about to report that I did exactly that 😄 |
Is there any work going on to get this to work with pipewire already? If not, I'll take a look at it... |
Well you need to check if pipewire guys finished implementing full compatibility - unfortunately I don't think that's the case because nothing else seems to require what we need. Also, I think that there is probably a better way to implement this in pure pipewire - even with audio and video. If you are looking for a challenge, I'd pick this. |
Yeah, I was first thinking of start from scratch but then again this project have lots of experience on potential pitfalls etc. What functions do you need in pipewire that you mentioned? |
@Cygn I've not had the time to dig in deep yet, but I've started to glance at the implementation. Correct me if I'm wrong, but the dbus interface is basically only used to communicate with pulseaudio to setup new sinks and get callbacks of when something happens with the audio routing. Then streamserver is used to handle connections from the casting devices to forward the actual audio packets to the chromecast device. Is this first analysis correct? If so, I'm thinking the dbus interface is not really needed for pipewire, it should be possible to write the same functionality that is in pulseaudio.py but specific for pipewire instead and communicate over the pipewire-protocol-native or pipewire-protocol-simple maybe. Then one could specify which implementation to use, pulseaudio or pipewire. How does this sound? Or have I completely missed some critical part here? |
This overlaps my understanding of the code. Note that I've taken over just for packaging; @masmu is the original architect. I've touched the code very little and mostly handle PRs. |
Ok, I just wanted to check so I don't spend time implementing something that someone else know is the wrong path to go. Thanks for your input. I'll dig into this, but it will take some time. I'll implement it more pipewire specific and add an option to select if using pipewire or PulseAudio when starting the Daemon. |
Cool :-) point me to your repo when you start this. |
I'll fork this project to my laptop and then push it here: https://github.com/EvTheFuture |
I've created a pipewire wrapper in C that works with ctypes in Python. However when thinking of it and looking at the code, wouldn't it be sufficient (and easier, i e no need to compile C code) to simply wrap the commands Ideas and suggestions are welcome. |
I run Arch Linux and i have pipewire installed. How can I make this work?
INFO Found the following pulseaudio server addresses:
CRITICAL Could not connect to pulseaudio! Application terminates!
INFO SSDPDiscover.search()
Thanks in advance
The text was updated successfully, but these errors were encountered: