FAQ
Answers to the most common questions about WFAS.
WFAS is a personal project by an engineering student. Its security features (key authentication, ChaCha20-Poly1305 encryption, anti-replay checks) are an experimental implementation that I wrote myself while learning. They have not undergone any formal security audit or independent review.
- Please do not rely on WFAS to protect sensitive, confidential or safety-critical audio or data.
- Please do not use it on public, corporate, school or otherwise untrusted networks.
- The encryption is a best-effort measure for a home network you trust. It is not a substitute for a vetted, audited solution.
- There may be vulnerabilities or design mistakes that I am not aware of.
The software is provided "as is", without warranty of any kind, under the terms of its licenses. If you find a problem, I would be grateful if you reported it on GitHub.
General
Yes. There is no premium tier, no time limit and no ads, and the full source code is on GitHub. The Ko-fi link on the download page is optional.
No. WFAS has no user accounts, cloud registration or sign-in. You install the app, open it and connect.
Yes. Streaming uses only your local area network (LAN): the audio goes directly between your devices and not through the internet or an external server. The desktop app does make one request to the GitHub API to check for new releases (see the privacy page), and you need internet access to download the app.
In native WFAS protocol mode, typical latency is around 15 to 50 ms, depending on network conditions and hardware. Your results may differ, and I have not been able to test every combination of devices and networks. That is usually fine for watching videos, but it may not suit every game or music application. DLNA and Snapcast modes use larger buffers (medium latency) for multiroom synchronization or TV playback. HTTP/AAC and HTTP/Opus modes have higher latency (roughly 100–400 ms) because of browser audio buffering, but they work with almost any browser.
Compatibility
Yes, in principle. Any combination of WFAS clients and servers should be able to communicate, regardless of platform: Windows → Android, Android → Windows, Windows → Linux, Android → Android, and so on. The protocol is the same on all platforms, but I have not been able to test every combination, so please report any problems on GitHub.
On macOS 14.2 and later, the system audio capture API (Core Audio tap) falls under the Screen Recording permission, even though no video is captured. This is a macOS design choice. WFAS only uses the audio part of that API, and you can check this in the source code.
The AudioPlaybackCapture API that allows capturing internal audio (e.g. from Spotify or YouTube) was introduced in Android 10. On older versions, only microphone input is available for capture. WFAS still works as a receiver (client) on older Android versions.
Yes. You can stream to your Smart TV or soundbar via DLNA/UPnP without installing anything on the TV, although behavior varies between TV brands and models. Alternatively, switch to HTTP/AAC or HTTP/Opus streaming mode on the Desktop server and open the generated URL in the Smart TV's built-in browser.
Security
No. Audio is sent only between the devices you choose on your local network. There is no cloud component, no relay server and no telemetry; the only external request is the desktop app's check for new releases on GitHub. You can verify this in the source code on GitHub.
To enable encryption, open the app on the sender device (Send / Server mode), scroll down to the security section, select the Key security mode, and set your shared key. Just below it, turn on the encryption switch toggle. Make sure the client device connects using the exact same key. The stream will then be encrypted with ChaCha20-Poly1305. Please note that this is an experimental implementation that has not been security-audited. Read the security page and disclaimer →
I would recommend against it. WFAS is an experimental project and its security features have not been audited, so please do not rely on them on public or untrusted Wi-Fi. If you have to stream in such a place, connecting your devices with a USB cable (USB tethering) avoids sending the stream over the shared Wi-Fi network, which reduces exposure, but it is not a guarantee of security either.
Common issues
Check these in order:
- Both devices are connected to the same Wi-Fi network (not one on 2.4 GHz and one on 5 GHz if the router has client isolation between bands).
- The firewall on the server machine allows UDP traffic on the WFAS port (default: 9090).
- The WFAS server is running and not minimized to tray without being started.
- Try entering the server's IP address manually in the client instead of relying on auto-discovery.
A VPN creates a virtual network interface and often changes the default routing, which can prevent WFAS from discovering devices on your LAN or binding to the correct network interface. Try: temporarily disable the VPN while streaming, or manually specify the server's LAN IP in the client app, bypassing auto-discovery. If your VPN allows split tunneling, exclude the WFAS port from the tunnel.
WFAS is licensed under the EUPL, which requires that the source code remains public. Google Play doesn't require this, but publishing there involves additional fees and policy constraints. WFAS isn't on the official F-Droid repository, but it's available through IzzyOnDroid, a third-party F-Droid-compatible repository for apps that don't fit F-Droid's own inclusion criteria, as well as a direct APK from GitHub Releases (also mirrored on GitLab), so you never need a Google account to install it.