Sound Keeper stops Windows audio outputs from going to sleep

A single exe that keeps a digital output alive

Sound Keeper is described as preventing SPDIF, HDMI and Bluetooth digital audio playback devices from sleeping, and it uses WASAPI, requiring Windows 7 or newer. The current version is v1.3.7, and the project page is at veg.by/projects/soundkeeper. The distribution model is unusual and worth understanding before anything else. You need just one exe file, with the others removable, and there are three of them: SoundKeeper32.exe for x86-32 Windows, SoundKeeper64.exe for x86-64 Windows, and SoundKeeperARM64.exe for ARM64 Windows. There is no installer, no registry entry, no service and no configuration file. The program does not have a GUI, and it starts to do its job right after the process is started, which means the only user interface is the file name and the command line. To close the program you just kill the SoundKeeper.exe process, and to autorun you copy SoundKeeper.exe into the startup directory, which you open by pressing Win+R and entering shell:startup. For a utility whose entire job is to sit in the background holding an audio stream open, that is about as small an installation surface as exists.

Getting the exe and running it without a GUI

There is nothing to install. The project ships as standalone executables on its own page at veg.by/projects/soundkeeper, and the documentation says you need just one exe file, with the others removable. Three builds are published, one for each Windows architecture, and you pick the one matching your machine. Once the file is on disk there is no setup step, no configuration file and no installer, because the program does not have a GUI and starts to do its job right after the process is started. To run it you start the exe, and to close it you kill the SoundKeeper.exe process. The autorun route is equally manual, copying SoundKeeper.exe into the startup directory, which you open by pressing Win+R and entering shell:startup. Because the settings are encoded in the executable name, the usual workflow is to rename the file to the variant you want, which is why the published examples read as a list of names rather than a list of flags.

How it keeps a device awake: a stream that never ends

The mechanism is to hold an audio output open by streaming into it. The stream type settings decide what is actually played. OpenOnly opens the audio output but does not play anything, and the documentation says it sometimes helps. Zero plays a stream of zeroes, and the note is that it may not be enough for some hardware. Fluctuate plays a stream of zeroes with the smallest non-zero samples once in a second, and that is the default. Sine plays a 1Hz sine wave at 1% volume, with frequency and amplitude changeable, and the documentation says it is useful for analog outputs. White, Brown and Pink play the named noise, with the same parameters as the sine except frequency. A stream of silence is enough for many receivers to consider the connection live, but a device with a strict digital lock will not accept a zero stream, which is exactly what the Fluctuate default is working around. The later changelog entries show the author chasing that hardware: v1.3.2 raised the default fluctuation rate from one per second to fifty per second, on the grounds that it helps in many more cases, and v1.3.1 made Fluctuate treat non-PCM output formats such as Dolby Atmos as 24-bit instead of 16-bit.

Settings encoded in the executable name

Default behaviour is changed either by adding settings to the executable file name or by passing them as command line arguments, and setting names are case insensitive. The device type settings come first. Primary keeps on the primary audio output only, and is used by default. All keeps on all enabled audio outputs. Digital keeps on all enabled SPDIF and HDMI audio outputs, which is described as the behaviour of Sound Keeper v1.0. Analog keeps on all enabled audio outputs except SPDIF and HDMI. Marked keeps on outputs that carry an exclamation mark in their name, so you add the mark to the desired outputs in the Windows device list, and that option arrived in v1.3.7. The examples show how the naming works in practice. SoundKeeperZeroAll.exe generates a zero amplitude stream on all enabled audio outputs, and SoundKeeperAll.exe generates the default inaudible stream on all enabled audio outputs. SoundKeeperSineF10A5.exe generates a 10Hz sine wave with 5% amplitude on the primary audio output, which the documentation notes is inaudible, while SoundKeeperSineF1000A15.exe generates a 1000Hz sine wave with 15% amplitude, which is audible and therefore offered for testing.

The command line form is the same thing spelled out, for example "SoundKeeper.exe sine -f 1000 -a 15" as a command line version of the 1000Hz, 15% example, and "SoundKeeper.exe brown -a 0.1" for brown noise at 0.1% amplitude, with the settings passed as command line arguments. The encoding is the design, and it is a defensible one for a single-purpose tool with no settings UI, though it does mean that changing a setting means renaming a file.

The stream parameters F, A, L, W and T

The sine and noise streams take five parameters, and the parameter letters are terse enough that they need spelling out. F is the frequency, defaulting to 1Hz for Sine and 50Hz for Fluctuate, and applicable to Fluctuate and Sine. A is the amplitude, defaulting to 1%, with a note that 0.1% is the setting for inaudible noise, and it applies to Sine and Noise. L is the length of the sound in seconds, defaulting to infinite. W is the waiting time between sounds if L is set, which is what turns a one-off sound into a periodic one. T is the transition or fading time, defaulting to 0.1 second, and it applies to Sine and Noise. A related constraint appears in the v1.3.1 changelog, where the frequency parameter is limited to half of the current sample rate to avoid the generation of unexpected noise. That limit is a real behaviour rather than a documentation nicety, since a 1kHz tone on a device running at a low sample rate would alias into something you did not ask for.

The Windows 11 sleep problem and the three counterswitches

There is one known issue and it is significant for laptop users. Streaming audio prevents automatic sleep mode on Windows 11, and three switches exist to counter it. SleepL makes Sound Keeper sleep when the current user session is locked. SleepD makes it sleep when the monitor is turned off. SleepLD, or Sleepy, covers both cases. This is the part of the design that shows the tool's history. The changelog records the progression: v1.2.1 noted that Sound Keeper works on Windows 11 and that the workaround which allowed the PC to sleep had to be disabled there, then v1.2.2 made the tool work as a dummy when no suitable devices are found and made it not prevent the PC from going into automatic sleep mode on Windows 10, and v1.3.0 disabled PC sleep detection on Windows 7 through 10 and made the program no longer confused when PC auto sleep is disabled on Windows 10. v1.3.6 added handling of Windows 8 and later suspend and resume events, which the changelog says should help avoid battery drain during modern standby. So the utility is aware that the platform fights back, and the switches are the compromise.

WasAPI exclusive mode and the audio service memory leak

Two workarounds in the history reveal what this program actually contends with. The first is exclusive mode. v1.0.3 recorded that exclusive mode does not prevent Sound Keeper from working, and v1.0.4 fixed a potential memory leak when another program uses audio output in exclusive mode. v1.3.5 handled ASIO exclusive mode by waiting until it ends, similar to the existing WASAPI exclusive mode handling. The second is the Audio Service leak itself. v1.1.0 added a workaround for a Windows 10 bug which causes a memory leak in the Audio Service when audio output is busy, and v1.2.0 enabled that workaround only on the affected Windows versions, 8, 8.1 and 10, and v1.3.4 tuned the Windows 8 to 10 workaround to make it effective for a longer time. The v1.3.1 entry also records a potential deadlock when audio devices are added or removed being fixed, which is the kind of bug that only appears when someone unplugs a USB DAC.

Where Sound Keeper is the wrong tool

The scope is narrow in a way that is easy to misread. The stated purpose is digital audio playback devices, and the device type settings cover SPDIF and HDMI with Bluetooth named in the description. A Bluetooth speaker with its own power saving will not be held awake by a stream on a different endpoint, and an analog-only chain is explicitly the case the Analog setting exists to exclude. The second limit is that this is a Windows program and only a Windows program, with no Linux or macOS build in the repository, and the tree confirms the shape of it, with a Visual Studio solution, a vcxproj, resource scripts, statically linked msvcrt32.lib and msvcrt64.lib, and an EmptyStub.bin. The third is that the tool is not a mixer. It keeps one output alive; it does not route audio, it does not normalise levels, and it does not replace the volume control in the Windows sound settings. And the fourth is the licensing and the release shape. The licence is MIT and recorded in a License.md file in the repository root, and there are no GitHub releases, so the version history is the changelog section of the documentation rather than a set of tags, and the last push to the repository was on 2026-06-14.

Editorial conclusion

Adopt Sound Keeper if your Windows machine feeds a digital receiver or DAC over SPDIF or HDMI and the device drops the stream when it goes idle, since the utility addresses that specific failure with a small footprint and no configuration file. Do not adopt it if the problem is a headset or a Bluetooth speaker that has its own power management, or if you need the tool to be quiet on a laptop, because streaming audio keeps the system awake on Windows 11 unless you use the SleepL and SleepD switches. Verify two things before you install it: which output your chain actually uses, since the default is the primary output only and the Digital switch exists precisely because the default is often the wrong one, and whether your machine's own sleep behaviour is acceptable, because the documented known issue is that streaming audio prevents automatic sleep mode on Windows 11. The practical first step is to download the exe matching your architecture, rename it to encode the settings you want, and confirm that your receiver stays connected before you leave it running.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. vrubleg/soundkeeper on GitHub