Repository navigation
Sendspin playback source not shown in pulseaudio or pipewire GUI tools? #239
Description
So I am going to preface this with a boxed warning label that I am experienced enough to be dangerous, but to not truly understand what is going on with the backend when it comes to alsa, pulseaudio, and especially pipewire. I generally know how to get things from whatever source to whatever sink(s) I want them to go, but........
No matter which --audio-device option I start sendspin with, sendspin never shows up in pavucontrol, nor helvum. I am accustomed to being able to route playback from my laptop's speakers, wired aux output jack, bluetooth headset, etc using the pavucontrol tool. I will go to helvum if I really need something crazy weird like multiple sink outputs of the same source input. Yes, I can get into command line to move sendspin --audio-device to something else with typing, but sometimes that is far less practical than a couple of clicks...
Is there a different device I should be targeting the sendspin client to in order to expose it to pavucontrol and/or helvum? Is this just never going to be possible with sendspin-cli (if so that is quite disappointing)? Is there something sendspin-cli could do in order to surface itself better to other audio routing tools like pavucontrol and helvum?
Activity
balloob commentedon Apr 29, 2026
Thanks for the detailed write-up — this is a real gap, and there are actually two things going on:
1. The device you pick determines whether you go through the sound server. Sendspin uses PortAudio under the hood, and on Linux PortAudio talks to ALSA. If you pass
--audio-devicean index or name that maps to a hardware device (hw:0,0, an indexed sound card, USB DAC, etc.), the audio goes ALSA → kernel and bypasses PulseAudio/PipeWire entirely — so pavucontrol and helvum can't see it because it never connects to the sound server.To make sendspin show up as a routable client, point it at the sound server's ALSA plug device:
These are the same device names you'd use with any ALSA app — they show up in
aplay -L. Once routed through PA/PW, you can move sendspin between sinks in pavucontrol/helvum just like any other app.2. Even when it does go through the sound server, sendspin used to register with a generic name like
ALSA plug-in [python3], which is easy to miss in pavucontrol's playback list.#240 fixes the second part: sendspin now identifies itself as "Sendspin" (with a music role and a generic audio icon) so the stream is recognizable in pavucontrol/helvum/qpwgraph. It also adds a "Recommended for desktop usage" section to
sendspin audio-devices listand mentionspulse/pipewire/defaultin--audio-device --helpso the discovery story is better.So: once #240 lands, the recipe is
--audio-device pulse(orpipewire/default) and sendspin will show up labeled correctly and be freely routable. The hardware-only devices stay untouched — they're still the right choice if you want low-latency direct output and don't need PA/PW routing.Generated by Claude Code
fhteagle commentedon Apr 29, 2026
Hmm. Still not getting expected results after pulling and pipx installing a fresh git clone (with #240 in the git log display).
This seems to be a different output than when I was testing before I opened #239 ...
Same output for "pipewire". "default" does proceed to launch the tui, but again does not show up in pavucontrol even with active playback occurring.
After a bit more poking around, I think the behavior documented in the OP was being caused by the pipewire daemon running as my user (uid 1000), but sendspin is running as its own user (uid 942). If I instead run sendspin as uid 1000, sure enough its playback entry shows up in pavucontrol (also running as uid 1000). However, it is still being reported as "ALSA Plug-in [python 3.14]", and not the "Sendspin" label #240 was shift to.
So I guess the next question is the relative merits, security implications, etc of running sendspin as uid 1000 instead? Or would it be better to shift to pipewire running as a different uid instead?
balloob commentedon Apr 30, 2026
The daemon is meant to run as a background service with own user as a result of the install script. If you want to have it be part of your desktop experience, you need to run it Indeed as your user.
fhteagle commentedon Apr 30, 2026
@balloob - That makes far more sense to me. I am curious why the recommended install.sh script actually encourages the opposite, creating a separate sendspin user?
balloob commentedon Apr 30, 2026
It's meant for headless Linux boxes, to turn an old raspberry pi into a player.