Scream Stream

A Practical Guide to Scream Stream

What Scream Stream Actually Is

Scream Stream is a low-latency audio streaming utility built on the Scream protocol. It sends raw uncompressed PCM over UDP so you can route audio between machines in real time. The protocol is connectionless, which means there is no handshake, no retransmission, and no guarantee that any given packet arrives. You trade reliability for speed, and the whole thing works because the round-trip is fast enough that dropping a few packets won't ruin the stream in most cases. I ran into this tool when I needed to get audio from a headless Linux box running Ableton into a Windows machine where my interface and monitoring setup lived. Trying to use PulseAudio or ALSA over the network with standard tools adds too much latency for anything performance-sensitive. Scream handles the routing at roughly 1–2 milliseconds on a decent LAN, which is close to acceptable for live monitoring. It is not perfect. It will crackle under the right conditions. But for its niche, it is one of the few things that actually works out of the box.

How to Install and Run It

The binary is available for Windows, Linux, and macOS. On Linux, if your distribution provides it in the package manager, use that. Otherwise the source is on GitHub and compiles with a standard Makefile. The Windows version is a single executable. No installer, no service, just a console window. The basic command looks like this: scream -m <destination_ip> -d <device_index>

The -m flag specifies the receiver IP. The -d flag selects which audio output device to send from. If you have multiple sound cards, you will need to figure out which index is correct, because using the wrong one sends silence. On Linux, run it with JACK attached. On Windows, it uses WASAPI directly when available, which is preferable for latency. The default packet size is small, which keeps latency down but makes the stream more sensitive to network jitter. I spent about forty-five minutes the first time I set it up because the default device index was wrong and I thought the program was broken. It wasn't. It was working fine. It was just sending from my secondary microphone input instead of my main output. Count the indices carefully and verify with a test tone before you assume anything is wrong.

Receiver Setup

The receiving side is even simpler. On the machine that needs to play the incoming stream, you run Scream in listen mode: scream -l This creates a virtual loopback device. On Windows it appears as an audio playback endpoint. On Linux it shows up in JACK as a pair of connected ports. You then point your DAW or audio application to that virtual device and you are routing network audio. The audio arrives as PCM and gets played back on whichever physical output your system defaults to.

There is a common confusion here that nobody warns you about. The receiver does not need to know the sender's IP address. The sender pushes to the destination and the receiver just sits there listening. That is one of the design decisions that makes it simple but also one of the things that causes trouble when you try to chain multiple receivers together. Only one machine can legitimately receive at a time on a given port unless you set up multicast, which is another can of worms.

Latency and Buffer Configuration

Latency on Scream Stream depends on two things: the OS-level buffer size of your source device and the network path between the machines. On a Gigabit LAN with both machines wired and no congestion, you can usually achieve sub-5 millisecond round trip. Over Wi-Fi, expect 10 to 30 milliseconds depending on signal strength and interference. This is not a workaround suggestion. It is just what happens. If you are running this over a managed switch and both machines are on the same VLAN with QoS enabled for audio traffic, the consistency improves dramatically. Unmanaged switches and consumer routers do not handle bursty UDP well, and you will hear dropouts during peaks. I learned this the hard way on a project where a cheap Netgear router was causing periodic stutters every forty seconds. Moving to a managed switch eliminated the problem entirely. On Linux, if you are routing through JACK, you need to make sure the JACK buffer size is large enough to absorb the network jitter. A buffer of 64 samples at 48 kHz gives you about 1.3 milliseconds of jitter tolerance. If your network is adding another couple of milliseconds of variation, your audio will break up. I usually set JACK to 256 samples minimum when Scream is involved, which trades a tiny bit of latency for stability. The extra 4 milliseconds is usually fine unless you are doing live vocal monitoring, in which case you will feel it.

Common Problems and Workarounds

The biggest issue people hit is the sender crashing or freezing after running for a while. This is typically a resource leak or an issue with the audio driver on the source machine. On Windows, closing and restarting the process usually fixes it. On Linux, if JACK starts dropping XRUNs that coincide with the stream cutting out, the problem is likely the source device's driver fighting with JACK over exclusive access. Switching the source to ALSA raw mode instead of keeping it locked to JACK sometimes resolves it, though it may add a small amount of latency. Another issue is clock drift between the sender and receiver. Since UDP does not resynchronize, the two machines will gradually drift apart over time. After several minutes of playback, the receiver will either buffer underrun or introduce gaps. The workaround is to ensure both machines are on the same clock domain. On Windows, set the sample rate in both the sender and receiver to the same value and disable any sample rate conversion in your DAW. On Linux, lock JACK to the receiver's physical device as the clock master and let the sender align to it. I had a situation where one machine was at 44100 Hz and the other at 48000 Hz, and the audio degraded noticeably after about three minutes. Matching the rates fixed it completely. A third problem that is easy to miss is firewall interference. Windows Defender and some Linux firewalls treat Scream's UDP traffic as suspicious and will silently drop packets after the initial connection. You need an explicit inbound rule for UDP on the port Scream uses, which defaults to 54731. Without this, the stream will appear to connect and then simply produce silence. I verified this by running tcpdump on the Linux side and seeing packets arrive but not being processed by the audio subsystem, which pointed me directly at the firewall.

When Scream Stream Fails Completely

There are scenarios where this tool is not the right answer. If you need guaranteed audio integrity, such as for broadcast or professional recording where no packet loss is acceptable, Scream Stream will not work. It is designed for monitoring and live performance where a few dropped samples are preferable to the latency that other solutions introduce. If you are mixing multitrack sessions over the network, use something like Roli's Audio Bridge or explore Dante integration instead. The other limitation is that Scream Stream only handles stereo PCM. There is no built-in support for multichannel routing, compression, or metadata. If you need to send ten channels of audio across a network, you will need to either bundle multiple instances or look at a different protocol. It is a narrow tool by design, and that narrowness is both its strength and its weakness. I still use it occasionally for quick monitoring setups where latency matters more than features. It is not something I recommend for production environments, but for a home studio setup or a live rig where you just need to get audio from one computer to another without buying expensive hardware, it does exactly what it promises. Nothing more, nothing less.