swyh-rs: streaming the loopback output to UPnP renderers in Rust

What the program actually does

swyh-rs is described as a Stream-What-You-Hear implementation written in Rust and MIT licensed. It allows you to stream the music you are currently playing on your PC, on Windows or Linux, to a UPNP, DLNA or OpenHome compatible music player, which the README calls a renderer.

The use case is specific but common enough. You have a network player, a Sonos soundbar, an amplifier with a streaming client, and a desktop that plays music from a local file, a streaming service or a video. The renderer can play from your own server but cannot see what your desktop is doing. swyh-rs bridges that gap: it captures the audio your machine is playing and republishes it as a UPnP renderer would, so the network player sees a second source.

That also explains why the project lives on a LAN. The renderer discovers the stream over SSDP, which is link local multicast, and the audio itself goes to the renderer over the network. There is no cloud component and no account, and the README has a section on VPN and SSDP failure for people who try to put the two ends on different networks.

Why it was written from scratch

The README lists the reasons the author gave for writing the Rust implementation instead of using the original SWYH.

* I wanted to learn Rust * SWYH does not work on Linux * SWYH did not work well with Volumio, because push streaming did not work * SWYH has a substantial memory leak due to the use of an old and unmaintained Intel .Net UPNP/DLNA library it uses

That list is a fair description of the scope of the project. swyh-rs is not trying to be a general media server. It is a focused reimplementation of one program, with the platform gap and the library problem as the driving reasons.

The README also names alternatives and is candid about their limits. The original SWYH has picked up development again after six years and has a revamped version 2.0 beta, still Windows with MP3 and LPCM/L16 only. StreamToSpeaker by Mihonarium may be better suited if you are on Windows and want to watch video or play games while streaming to your speakers, because it should have much lower latency, and as of October 2026 it supports only LPCM/WAV 16 bit and AirPlay.

Lossless only, and the reason is practical

The README states plainly that swyh-rs does not support lossy mp3 or aac re-encoding, only lossless LPCM, WAV, RF64 and FLAC, and gives the reason as obvious.

It is obvious once you know what re-encoding means here. Transcoding to MP3 or AAC costs CPU, adds latency, and produces a file that is worse than the source. A lossless stream is a straight copy of the samples the machine is already playing, which means the renderer sounds exactly as good as the original and the PC has almost nothing to do.

That choice has consequences in the field, and the README documents them per device. MoOde audio is listed as tested when configured as a UPnP renderer in Openhome mode, using FLAC, which the README calls preferable, or LPCM, which has been possible since 1.8.7, or WAV, with a known problem of a five second delay in the WAV, RF64 and LPCM formats that has its own section in the known problems list. Denon HEOS devices work best with WAV format and NoneChunked streamsize, and if you change the format or the streamsize you may have to restart swyh-rs before the Denon recognises the stream.

The general rule that emerges is that FLAC is the safest format when a renderer supports it, and the second safest is LPCM.

Sonos needs FLAC, and only one speaker of a pair

The Sonos notes are the longest in the compatibility section, and they contain the traps.

The recommendation is to use WAV format or FLAC on current firmware. A Sonos may stutter when using WAV depending on the network, and if that happens you should use FLAC if the device supports it. Software version 15.9 (Build 75146030) on the Play:1 is known to support FLAC without stuttering. There is a wiki entry on Sonos stuttering and the associated issues for more detail.

The rule that will break a stereo pair is stated as important: if you are streaming to a stereo pair, you should only stream to the master of the pair and never to both, because doing so can and will break the stereo pair.

There is also a size limit with a workaround. If you use the WAV format, streaming will stop after 2 GB worth of samples, and if that bothers you you enable autoresume in the App tab.

The stuttering advice is not only about the format. Stuttering can occur with Sonos gear, especially over WiFi, and an initial buffering value can prevent it. Installing ccproxy is also reported to help, with a separate issue for the details.

Inject Silence keeps the renderer connected

The option that solves the most common complaint is called Inject Silence, and the README explains it in a way that shows how the pieces fit.

The purpose is to pause music without losing the connection. The InjectSilence flag is automatically added to the config file when you first start version 1.4.5, and it defaults to false. Since 1.12.0 it works with FLAC as well. If you do not enable Inject Silence for FLAC, swyh-rs will automatically and periodically inject some faint white noise in the absence of sound, so that you hopefully do not lose the connection.

The cost is stated too: injecting silence eats a negligible amount of CPU cycles. So the trade is a small, constant amount of audio on the wire in exchange for a renderer that does not drop off the network when you pause. For a device like a Sonos, which tears down a stream when nothing arrives, that is the difference between a pause and a reconnect.

Note the default. The behaviour of injecting faint noise is automatic for FLAC, while the explicit option exists for the other formats and defaults to off, which means the default experience on WAV is the one that keeps stuttering or dropping.

Two binaries, separated by Cargo features

The manifest is where the shape of the project is clearest. The package is named swyh-rs, at version 1.21.1, edition 2024, with rust-version 1.99.1 and a resolver of 3.

name = "swyh-rs"
version = "1.21.1"
description = "Stream What You Hear written in Rust"
license = "MIT"
repository = "https://github.com/dheijl/swyh-rs/"
default-run = "swyh-rs"

There are two features and two binaries, and the features decide which binary builds.

[features]
gui = ["dep:fltk", "dep:fltk-theme"]
cli = ["dep:local-ip-address", "dep:ctrlc"]
default = ["gui"]

[[bin]]
name = "swyh-rs"
required-features = ["gui"]

[[bin]]
name = "swyh-rs-cli"
required-features = ["cli"]

The GUI is FLTK based and is the default. The CLI variant needs local-ip-address and ctrlc, and the README has a section on the CLI binary for people who want to run this without a desktop session.

The dependency list explains the audio path: cpal for capture, dasp_sample for sample format handling, flac-bound for the FLAC encoder, and figura for the user interface widgets. The release profile strips symbols, uses codegen-units = 1 and thin LTO. The repository also carries a flake.nix and default.nix for Nix, an Inno Setup script for the Windows installer, a Python tray icon contributed separately, locales/ for translations, benches/ and a CLAUDE.md.

Releases, the ARM caveat and the licence

The current release named in the README is 1.21.0, whose title is the addition of SqueezeLite, or SlimProto, support, and the changelog is pointed to for the details. Windows x86/64 setup and binaries and Linux Ubuntu and Debian appimages are published in the Releases section.

The release history shows 1.20.4 on 2026-06-27, titled the Heatwave Release, 1.20.5 on 2026-07-14 with a focus on GUI responsiveness and other optimisations, and 1.21.0 on 2026-08-23, with the last push on 2026-10-20. The working tree is ahead of the last tag, which is the normal state for a project that ships binaries from tags.

One dependency is outside the project and should be treated carefully. ARM binaries are hosted in a separate repository maintained by Jamie Duk, who also publishes a build recipe. The README is explicit that the author has not tested them.

The licence is MIT, and the package metadata records the same. On the question of AI use, the README has a section on it, which is worth reading if you plan to contribute, and the repository also carries CONTRIBUTING.md and a CODE_OF_CONDUCT.md.

Editorial conclusion

swyh-rs fits a Windows or Linux machine on the same network as a UPnP, DLNA or OpenHome renderer, where you want to send whatever the desktop is playing to a network speaker in lossless quality and the original SWYH does not cover your platform. It does not fit anyone who needs MP3 or AAC re-encoding, and it does not fit a setup where the PC and the renderer sit on different networks, because discovery goes over SSDP on the local link. Verify first which format your renderer handles without stuttering, since FLAC is the safest choice where it is supported, and check the compatibility notes for your specific device before you rely on it.

Frequently asked questions

Official sources

1. dheijl/swyh-rs on GitHub
2. Issues
3. License: MIT
4. README
5. Releases