WiFiAudioStreaming-Desktop: your PC as an AirPlay-style transmitter

The problem is the missing virtual audio cable

The application turns your computer into a wireless audio transmitter or receiver, sending your PC's audio to any device on the same local network or playing audio from another device. It is designed to work with a separate Android version, and it is written in Kotlin with Jetpack Compose.

The design decision that makes it different from the obvious approach is in the native audio engine entry. On Windows and macOS, audio is captured directly via a native C library loaded through JNI, and the README is emphatic that no VB-Cable, no BlackHole and no third-party virtual drivers are required. FFmpeg handles encoding only for the HTTP streaming protocols. That matters because the usual way to capture a system's audio output on Windows is to install a virtual cable, which is a driver, a reboot and a permanent change to the audio routing of the machine, and on macOS a separate audio device. The trade is a native library that only exists on two platforms, so a Linux user has a different path or no path.

The project is licensed EUPL-1.2, the default branch is master, and the recent releases are v1.2 from 2026-08-21, v1.1 from 2026-07-22 and v1.0 from 2026-05-24, with the last push on 2026-09-24.

Six protocols, and they are not interchangeable

The protocol list is where the project's real scope shows. WFAS v2 is the native protocol and the one with the lowest latency. RTP works with any RTP-capable receiver. HTTP/AAC targets Safari and iOS, and HTTP/Opus WebM targets Chrome, Firefox and any browser. DLNA/UPnP is aimed at AV receivers, soundbars and smart TVs with no app needed on the other side, and the README marks it as work in progress for the next release, while noting it is already visible in the Settings screenshot. Snapcast gives synchronised multiroom, and any snapclient joins, so a Raspberry Pi, an ESP32, Home Assistant or the Snapcast mobile apps.

That list explains the design rather than contradicting it. A native protocol cannot talk to a smart TV, and a browser cannot speak a native protocol, so a tool that wants to cover the devices people actually own has to speak several. The cost is that the app is a multi-protocol server rather than a simple one, and each protocol has different latency, encryption and quality characteristics.

One behaviour is worth calling out because it saves a lot of confusion. Peers running an incompatible protocol version are rejected immediately during the handshake with a clear error, instead of hanging silently.

Microphone routing, including into your own stream

The microphone feature is more than a talkback channel. The server can receive microphone audio from a connected client and route it in three ways: ignore it, expose it as a virtual microphone to other applications such as Discord, Zoom or games, or mix it directly into the outgoing stream. There is also a real-time mute button.

The third option, mixing the client microphone into the outgoing stream, is the one that changes the shape of the use case. It turns the machine into a talkback or intercom station, where a client can speak into whatever the PC is playing, which is the sort of thing that turns a media streamer into a one-way intercom. The virtual microphone option is the other useful one, and it is the one that removes the need for a second application to feed a voice call.

The application also lives in the system tray, and the README says you can configure it to start minimized and close to tray so it runs silently in the background like AirPlay or Chromecast. For a tool that captures system audio continuously, that is the difference between a program you use and a program you forget about.

Discovery by multicast beacon, with a manual fallback

Clients find available servers on the network via a multicast beacon, and the device list badges each server as Multicast or Unicast and whether it is encrypted or requires a key. If your router blocks multicast, you can manually enter the IP address.

The fallback is not a workaround bolted on, it is a required path, because consumer routers frequently filter multicast between wireless clients. The badges also carry more information than a name does. Knowing that a server is unicast, and that another one needs a key, changes what you can do with it before you try, and that is information a plain device list cannot carry.

On the sending side there is a matching split. Unicast is direct streaming to a single device, and multicast is simultaneous transmission to multiple clients. The Snapcast protocol is listed as synchronised multiroom, which is a third thing again, since the point of Snapcast is that the clients are synchronised to a common clock rather than merely fed at once.

Access control and encryption, and where the key model stops

The security section is the one to read before putting this on a network. You can optionally gate who can connect, with three settings: Off, Ask to approve each device, or Key for a pre-shared password checked via a mutual HMAC-SHA256 challenge-response. The audio itself can be encrypted end-to-end with ChaCha20-Poly1305, described as per-packet AEAD with anti-replay and keys derived via HKDF, and the README says this works for both unicast and multicast with no PKI required. The protocol document, WFAS_PROTOCOL.md, sections 7 and 8, is where the detail lives.

The design is deliberately a shared secret rather than a public key infrastructure, and that is a reasonable trade for a device on a home network, but it sets a boundary. There is no certificate, no revocation list and no per-user identity, so the shared key is the whole of the access control, and a key that leaks leaks for every device using it. The Ask mode, where each connection is approved, is a middle ground that costs you an interaction per device.

Worth noting that the default is Off. On an untrusted network, that means any device that can reach the port can listen, which is the same assumption AirPlay makes and the same assumption that a guest wifi breaks.

A headless CLI for the parts that should not need a window

There is a command line interface, wfas, described as a full headless daemon and control tool, installable to your PATH during first-run setup. It starts a server or a client, runs commands such as wfas control volume 75 or wfas control mute against a running instance, manages configuration profiles with wfas config, and fixes the Windows firewall with wfas firewall allow. Nearly any command accepts --json for scripting.

There are two diagnostic modes that are unusual enough to mention. wfas --viz draws a real-time ASCII audio visualizer in the terminal, with theming such as --viz rainbow and a --groove mode that highlights the melody over the raw bass, and wfas --debug prints a live-updating table of UDP packets and internal state.

The --debug table is the more useful of the two for anyone diagnosing a problem, because the hardest failures in local network streaming are always the same: a packet that never arrives, a client that connects and gets nothing, a firewall rule that is missing. Seeing the packets settle that question faster than reading logs.

A related convenience is the firewall assistant. On Windows the app can create the required inbound firewall rule with one click, and on Linux it detects ufw or firewalld and shows the exact command to open the required ports.

Where this approach stops working

Three cases point elsewhere. The first is a Linux workstation, since the native audio engine is described as Windows and macOS only, and the README does not describe an equivalent path for Linux.

The second is a network where you cannot open ports or cannot accept the default. A local network streaming tool needs inbound traffic, which on a corporate or guest network is often blocked, and multicast discovery is blocked more often than direct connections are. The manual IP entry helps when multicast is filtered and unicast is not, but it does not help when the whole path is closed, and a VPN or a different tool is the answer there.

The third is anyone who needs the DLNA or UPnP path today. The README marks it as work in progress for the next release, and while it says the option is visible in the Settings screenshot, a screenshot is not a working implementation, and the feature list explicitly says no app is needed on the other side for it, which is the appeal of the protocol and the reason to wait for it.

The alternative worth weighing is Snapcast on its own for the multiroom case, since it has its own client ecosystem and its own synchronisation model, and a dedicated hardware streamer such as a Chromecast or an AirPlay receiver for the send-to-a-speaker case. This application is the interesting option when you want the PC to be the source and you want the choice of protocol and of who may listen, and the trade is the native capture dependency on two platforms.

Editorial conclusion

WiFi Audio Streaming fits someone who wants their PC's sound in another room without a proprietary receiver, who is on Windows or macOS where the native capture path exists, and who wants the choice of a native protocol, RTP, HTTP or Snapcast rather than one locked-in stack. It does not fit a Linux-only workstation, since the native capture library is described as Windows and macOS only, and it does not fit anyone who needs a DLNA receiver today, because that target is marked as work in progress. Before you adopt it, read WFAS_PROTOCOL.md sections 7 and 8, since the encryption and access control model lives there, and decide whether you need encryption at all, because the default is that anyone on the network can connect.

Frequently asked questions

Official sources

1. License: EUPL-1.2
2. marcomorosi06/WiFiAudioStreaming-Desktop on GitHub
3. Project website
4. README
5. Releases