spotifyd
spotifyd copied to clipboard
Spotifyd sink is never corked
Description Spotifyd sink in never corked, even if no audio is playing. This prevents audio based idle monitoring from working.
To Reproduce
- run spotifyd
- run 'pactl list sink-inputs'
- Look for 'Corked' and make sure it's value is true when nothing is reproducing.
Expected behavior When no audio is reproducing, corked shows true.
Logs
Sink Input #52
Driver: PipeWire
Owner Module: n/a
Client: 51
Sink: 63
Sample Specification: float32le 2ch 44100Hz
Channel Map: front-left,front-right
Format: pcm, format.sample_format = "\"float32le\"" format.rate = "44100" format.channels = "2" format.channel_map = "\"front-left,front-right\""
Corked: no
Mute: no
Volume: front-left: 65536 / 100% / 0,00 dB, front-right: 65536 / 100% / 0,00 dB
balance 0,00
Buffer Latency: 0 usec
Sink Latency: 0 usec
Resample method: PipeWire
Properties:
client.api = "alsa"
application.name = "spotifyd"
node.latency = "220/44100"
node.rate = "1/44100"
node.target = "-1"
media.type = "Audio"
media.category = "Playback"
media.name = "ALSA Playback"
stream.is-live = "true"
node.name = "PipeWire ALSA [spotifyd]"
node.autoconnect = "true"
media.class = "Stream/Output/Audio"
adapt.follower.node = ""
object.register = "false"
factory.id = "8"
audio.adapt.follower = ""
factory.mode = "split"
library.name = "audioconvert/libspa-audioconvert"
client.id = "51"
object.id = "52"
module-stream-restore.id = "sink-input-by-application-name:spotifyd"
Installed from: manjaro official repositories
Versions (please complete the following information):
- OS: Manjaro-sway
- Spotifyd: 0.3.2
Temporal workaround I wrote a service that kills spotifyd when spotify-tui (or the app your choose) is not running.
~/.local/share/systemd/spotifyd-autokill.service
[Unit]
Description=spotifyd auto-killer (when spotify-tui is not running)
[Service]
# Full path here is required
ExecStart="/home/zeioth/.local/share/systemd/user/daemons/spotifyd-autokill.sh"
[Install]
WantedBy=multi-user.target
~/.local/share/systemd/user/daemons/spotifyd-autokill.sh
#!/bin/bash
while true; do
if `ps -ef | grep "alacritty --title spotify-tui" | awk {'print $2" "$8'} | grep -v grep > /dev/null`; then
echo "Spotify-tui is running: No actions taken."
else
echo "Spotify-tui is not running: Closing spotifyd."
killall -9 "spotifyd" 2> /dev/null
fi
sleep 120
done
~/.local/bin/spotify-tui
spotifyd
alacritty --title 'spotify-tui' --config-file ~/.config/alacritty/monokai.yml -e zsh -c 'source ~/.zshrc && cd ~/workspaces/git-forks/spotify-tui && cargo run' &
This of course implies that the bug is still present, and the computer won't go into sleep mode while spotify-tui is open, even if the audio is stopped.
Tested with 0.3.3 and still happens.
On my Macbook (MacOs 12.4) when spotifyd is running and I close my lid, after sleep my hostname changed!
FeekApp.local becomes FeekApp-1.local .
@Zeioth From what I can see, this is (more or less) working on my system, at least when I use either the alsa or the pulseaudio backend.[^1] When I pause playback, spotifyd disappears from the pactl list sink-inputs output. After resuming it again, it reappears there. Although it does not set any corked attribute that you described above, I assume that this would also work for you?
What spotifyd audio backend are you using, and what audio server?
[^1]: I'm using PipeWire (0.3.51) as my audio server.
@feekApp Is your issue related to the one described here, or would it be better suited for a new issue? Apart from that, how does a changed hostname influence spotifyds ability to play music?
@eladyn I'am using portaudio as is recommended in the wiki config file for macOS. Can I better try pulseaudio?
On Changing host-name, spotifyd seems still playing, but no sound on my Mac. Need to restart brew services for spotifyd.
@feekApp Unfortunately, I have no MacBook to test this myself, but it seems like you're rather describing something like this? (Correct me, if I'm wrong.)
As for portaudio vs. pulseaudio: There is probably a reason, why the brew formula only packages portaudio by default. Thus, I doubt that my findings above would also help you on macOS.
@eladyn indeed seems similar.