mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #824] librespot crashes if the local system is using systemd-resolved instead of avahi #415
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#415
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @WhyNotHugo on GitHub (Jul 23, 2021).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/824
I'm currently using systemd-resolved for mDNS rather than avahi, and
librespotflat out crashes when starting.This happens with the latest stable release. I tried building from source, but it seems pulseaudio won't work in that case for some reason:
I've noticed that now
rodioseems to be used as a backend, and not pulseaudio, however, that default backend assumes alsa. As hinted above, I'm using pulseaudio, not alsa:Any hints on how to work around any of these issues?
@kingosticks commented on GitHub (Jul 23, 2021):
What features does this build have enabled?
How to compile with the pulseaudio feature enabled is explained at https://github.com/librespot-org/librespot/wiki/Compiling#features. That page also contains info about the
with-dns-sdfeature (EDIT: which it sounds like is enabled on your build and is why it's crashing).@WhyNotHugo commented on GitHub (Jul 23, 2021):
I'm using this package, which is basically built using the default.
Given that pulseaudio is the de-facto standard sound system on Linux desktop, wouldn't it make sense for that to be enabled by default? Otherwise most users should have to rebuild themselves tweaking some compile-time flags.
I'm a bit confused about this flag. It seems to be disabled by default, right? Using
devwith this change:And running
cargo run -- --name hugo@victory --backend pulseaudio, it seems to work, and spotify on other devices can discover this device. I'm under the impression thatwith-dns-sdis required for mDNS discovery to work? Is there another discovery mechanism in place?@kingosticks commented on GitHub (Jul 23, 2021):
The wiki page states the default feature is the Rodio backend. Every other feature in that table is disabled by default and that includes
pulseaudio-backendandwith-dns-sd.No, it appears to be built with
--all-features. This enables all the features in that table. This is not the default.You've then changed the default feature from Rodio to Pulseaudio, so that will enable Pulseaudio. Every other feature is disabled in your build.
Yes. There are two different ways mDNS is implemented in librespot. The default way is an integrated mDNS server, this one may not play nicely when you have other mDNS applications running (such as an Avahi service). This is the one you are using in your build because you have not specified
with-dns-sd(or--all-features). The other way is activated using thewith-dns-sdfeature flag and it talks to the Avahi service running on your machine; if that Avahi service is not running then librespot crashes.@WhyNotHugo commented on GitHub (Jul 23, 2021):
Ah, thanks for the explanation, that makes sense. I guess that when using
systemd-resolvedinstead ofavahi, thewith-dns-sdfeature should be disabled.I'm surprised that
systemd-resolveddoesn't serve as a drop-in replacement foravahi, considering it comes from the same developer.Might it be related to:
This is a bit of another topic, but why use Rodio by default instead of Pulseaudio? Pulseadio is pretty much the de-facto standard on Linux desktop and what most distributions ship out of the box.
@ashthespy commented on GitHub (Jul 23, 2021):
Rodio is cross platform (Windows, Linux, MacOS) :-)
@WhyNotHugo commented on GitHub (Jul 23, 2021):
Any hints on how to make it work on Linux? There's no references to it in the arch wiki, packages or forums.
@WhyNotHugo commented on GitHub (Jul 23, 2021):
Hmm.. this is a bit of a red herring. On Linux, Rodio seems to just wrap around ALSA. So while, technically, it is multi-platform, it won't run on most Linuxes since most distributions ship Pulseaudio and not ALSA as a sound subsystem.
It's really as "cross-platform" as pulseaudio. Pulseaudio runs on windows, but I don't expect most windows users to have pulseaudio set up.
@ashthespy commented on GitHub (Jul 23, 2021):
Not sure, Rodio uses
cpalbehind the scenes, so you would have to look there. Since PA runs on ALSA anyway, you would probably have to hook into that subsystem directly.@WhyNotHugo commented on GitHub (Jul 23, 2021):
So there's two parts to ALSA (which is a source of infinite confusion):
When using pulseaudio, it relies on (1), but supercedes (2). Pulseaudio can be built to also expose the same APIs as (2), but that's mostly there for legacy compatibility for older software (e.g.: stuff that precedes pulseaudio), and not enabled by default. It's not really something that actively maintained software should be relying on either.
Obviously (1) isn't going anywhere, since it's what userspace components use to talk to the kernel's sound... stuff.
Rodio es cross-platform in the sense that it can be made to work on different platforms, and, in a way, is as cross-platform as pulseaudio, which can also be made to work on other platforms.
But it's not cross-platform from the "works without setting up another sound subsystem" point of view.
@kingosticks commented on GitHub (Jul 23, 2021):
Start a new discussion about making PulseAudio the default.
@WhyNotHugo commented on GitHub (Jul 23, 2021):
Yeah, that's getting off-topic here. Thanks for the pointers.