Repository navigation
[Feature Request] Implement audio device release on idle (as an option) #96
Description
Describe the Feature Request
Currently, the sendspin-cpp client keeps the ALSA audio device permanently open in a RUNNING state, even when no audio is actively being streamed or played. I would like to request an option to automatically release/close the audio device after a period of inactivity.
Observed Behavior
The audio device remains locked indefinitely by the process. This prevents other system applications from accessing the audio hardware unless complex software mixing (such as ALSA's dmix plugin) is configured, which is often not ideal or feasible on lightweight embedded systems.
$ cat /proc/asound/card1/pcm0p/sub0/status
state: RUNNING
owner_pid : 25525
Proposed Enhancement
We propose adding an optional configuration flag (for example, --release-on-idle or --idle-timeout <seconds>) that closes the audio output device when the stream is paused or inactive for a set duration.
Because some DACs experience audio sync delays or audible popping noises when opening/closing the audio interface, this behavior should be disabled by default to preserve backward compatibility.
Context & Use Cases
- Resource Sharing: Allowing other local applications (such as text-to-speech engines or system notifications) to access the sound card when Sendspin is idle.
- Hardware Control: While the library's existing
PlayerRoleListenercallbacks (on_stream_start/on_stream_end) already allow downstream clients to trigger external hardware (like GPIO relays for amplifiers), releasing the ALSA device itself is still necessary to free up the hardware.
Tested with sendspin-client and sendspin-armv6, both of which are based on the sendspin-cpp library.
This request was briefly discussed on Discord with @marcelveldt, @balloob, and @kevina.
Activity
[-][Feature Request] Implement playback state hooks and audio device release on idle (as an option)[/-][+][Feature Request] Implement audio device release on idle (as an option)[/+]balloob commentedon Jul 17, 2026
sendspin-cppis a library and the TUI client is an example. If we are serious about building it out into a client that anyone can use, we should spin that into an own repo (like we have aiosendspin + sendspin-cli)jojo141185 commentedon Jul 18, 2026
Thanks for the explanation, @balloob. You are completely right. Looking into the client implementations,
sendspin-cpponly handles the stream lifecycle viaon_stream_end(), while the actual hardware block remains active inside the client's audio sink (AlsaPipeSink/PortAudioSink).Since this is purely a client-side resource management task, I will close this issue here.
It would be great to keep the
--release-on-idlelogic in mind for the TUI example, or as a built-in feature once the client application is spun off into its own dedicated repository. Thanks for pointing me in the right direction!jojo141185 commentedon Jul 24, 2026
Just a quick update on this topic: I have implemented this feature and opened corresponding Pull Requests to bring the auto-release idle timeout into the different Sendspin clients:
This allows the audio device to automatically release after a configurable period of inactivity (
idle_timeout).Feedback or testing on other hardware setups is very welcome!