mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #974] No audio output over gstreamer pipe after some time #471
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#471
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 @sqozz on GitHub (Mar 4, 2022).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/974
Hello!
I have 3 instances of librespot running (each for one account) and configured it to output into a gstreamer pipeline.
After some time (I cannot really make out a pattern and be more precise) this pipeline seems to break and I receive no audio output despite everything else looking to work fine (librespot shows up as spotify connect device, I can start playback, no error from spotify). This is what is getting logged:
At 2022-03-02T17:18:04Z everything worked. At 2022-03-04T13:39:59Z I started a new session where audio output was missing until I restarted librespot at 2022-03-04T13:43:55Z. After that the audio was working perfectly fine again.
I use the gstreamer backend instead of the native pulseaudio one because this way I can distinguish between the different instances of librespot (by adding a
client-name).The command I use to run librespot is:
/opt/librespot/target/release/librespot spotifyd --disable-discovery --enable-volume-normalisation --name Catcave (sqozz) --device-type avr --bitrate 320 --backend gstreamer --device ! pulsesink client-name=spotify_sqozz --username my@user.name --password passwordI know that the log doesn't really provide much more information but maybe somebody can help me to further dig down what maybe could cause my problems here.
Some system information:
OS: gentoo
gstreamer version: 1.18.4
gstreamer plugins: base, good, bad, ugly (all 1.18.4)
pulseaudio version: 15.0
librespot version: 0.3.1
a605444(Built on 2022-01-09, Build ID: ljDVAehf, Profile: release)Thanks in advance!
@sqozz commented on GitHub (Mar 4, 2022):
I also just checked my PA logs and can see a lot of these errors being logged from "Mar 4 14:40:06" till "Mar 4 14:43:51":
This looks rather suspicious to me
@sqozz commented on GitHub (Mar 5, 2022):
I just hit the same issue again today so it definitely seems to be related. However restarting librespot seems to solve it despite pulseaudio complaining in the "pipe-sink" component (which hints to an issue in the output and not the input). I'm still puzzled how this can be linked to librespot
@JasonLG1979 commented on GitHub (Mar 6, 2022):
The Gsreamer backend in v0.3.1 is a mess. It was rewritten by a legit gstreamer expert in the soon to be merged
new-apibranch. You could give that branch a try and see if it helps?@sqozz commented on GitHub (Mar 7, 2022):
Thanks! I switched my setup over to
new-apiand give it a try. Please expect me to test this for one or two days as the issue isn't that easy to reproduce :)@JasonLG1979 commented on GitHub (Mar 7, 2022):
You might also look into just setting environment variables to tell pulseaudio what you want instead.
@sqozz commented on GitHub (Mar 7, 2022):
Yeah I thought about something like this too but didn't find any reference in the librespot docs. Would you mind pointing me into the right direction here? Or are you talking about pulseaudio env variables?
Until now the gstreamer backend seems more stable on the
new-api-branch but it might need some more time testing.@kingosticks commented on GitHub (Mar 7, 2022):
We should probably back-port it in the meantime.
@roderickvd commented on GitHub (Mar 7, 2022):
We can't easily without bumping MSRV from 1.48 to 1.56.
@kingosticks commented on GitHub (Mar 7, 2022):
Ahhh, yeh. Shame. I personally can't be bothered to decouple that and the other improvements (start & stop implementations, thread simplifications) but someone keen could..!
@roderickvd commented on GitHub (Mar 7, 2022):
Certainly true, that doesn't need the new bindings (and so the MSRV bump) perse. But for those who can wait or live with the bleeding
new-apiedge, I don't think we're too ar off from a 0.5 release somewhere later this year.Edit: venturing contributors, don't let this hold you from back-porting this!
@JasonLG1979 commented on GitHub (Mar 8, 2022):
@sqozz Would something like this work?:
https://github.com/JasonLG1979/librespot/tree/pulseaudio-name
It makes the name arg show up as the app name in the PulseAudio Volume controls like so:
For bonus points it also sets
PULSE_PROP_application.icon_nametoaudio-x-generic.@sqozz commented on GitHub (Mar 8, 2022):
I just quickly tried it locally and it seems to work. The stream shows up with the name of the
--nameparameter. I was expecting I could set the stream-name with theLIBRESPOT_NAMEenvironment variable but it shouldn't make a big difference for my use-case.edit: with your changes the
application.nameproperty in PA is changed. This is exactly the one I'm changing with my gstreamer pipeline - so it works fine!@JasonLG1979 commented on GitHub (Mar 8, 2022):
It should also work with the LIBRESPOT_NAME env var.
@JasonLG1979 commented on GitHub (Mar 8, 2022):
@roderickvd and @kingosticks I see the value of being able to set the name displayed by PulseAudio to differentiate instances but I'd like your thoughts.
Normally I'd say that just reading the
PULSE_PROP_application.nameenv var and using it if present would suffice but being as though it has a.in it it's not actually a valid env var and shells like bash will throw an error saying as much if you try to set it. So that makes that a non-starter. I honestly don't think it's really meant to be able to be set in a shell I think it's more meant to be used programmatically? Otherwise why would you purposely make a env var you can't set from a shell?I really do not want to add another command line arg to set it but I'm also not sure if always using
--nameis correct? Do you think that having the--nameshow up in the PulseAudio sound setting instead ofLibrespotwould be "expected" (or at least welcomed) behavior? Maybe justLibrespotif no name is given butLibrespot - Instance Nameif a name is given?@kingosticks commented on GitHub (Mar 8, 2022):
I think this sounds sensible.
@JasonLG1979 commented on GitHub (Mar 8, 2022):
@kingosticks It's still a bit of a bodge. To avoid changing the backend API I slightly abuse the
LIBRESPOT_NAMEenv var.@JasonLG1979 commented on GitHub (Mar 8, 2022):
@kingosticks I put in a PR https://github.com/librespot-org/librespot/pull/976 we can continue there if you'd like.
@sqozz what are your thoughts?
@sqozz commented on GitHub (Mar 9, 2022):
I'm a little bit torn between both solutions. I can understand that you might not want to introduce yet another option and for my use-case it should be a working solution. On the other hand you now couple the possibilities of naming the spotify-connect client to the capabilities of pulseaudio and might need more logic to avoid invalid chars (I don't know if PA supports every possible name which spotify would accept).
Then again if somebody really has special needs one could always fall back to the gstreamer pipeline to set these special attributes manually and you wouldn't need to duplicate the whole logic in librespot again.
@JasonLG1979 commented on GitHub (Mar 9, 2022):
Invalid chars is not really a concern. The input is already checked to make sure it's valid. The pulse prop is only used for display purposes. How the UI in the DE's sound settings decides to represent it is an implementation detail in that UI.
@sqozz commented on GitHub (Mar 9, 2022):
sure. I wasn't really concerned about UIs showing it but PA not supporting some chars. It might be a edge case and not worth considering too much - just my two cents :)
@JasonLG1979 commented on GitHub (Mar 9, 2022):
Rust and C both use the same string spec AFAIK? A valid Rust string would be a valid C string I would think?
@roderickvd commented on GitHub (Mar 9, 2022):
I don't think the distinction matters in this case, but if you want to get really technical in terms of FFI then you could read about
CStringon a rainy afternoon.@JasonLG1979 commented on GitHub (Mar 9, 2022):
I can't imagine it mattering at all. Worst case a user tries to set a name with unicode emojis in it and it's not displayed properly.
@JasonLG1979 commented on GitHub (Mar 9, 2022):
Plus pulseaudio parses the string from an env so one would hope that it's reasonably robust in checking it.
@allquixotic commented on GitHub (Mar 15, 2022):
I submitted a PR to backport the gstreamer cleanup to dev: https://github.com/librespot-org/librespot/pull/979
@roderickvd commented on GitHub (Apr 7, 2022):
@sqozz has your initial issue been fixed? Can we close this issue?
@sqozz commented on GitHub (Apr 29, 2022):
Yes. I'm running
librespot 0.3.1 dd8155bsince the 7th of March now and didn't observe the problem once. Thanks all for your great help and fast responses - appreciated!