White Noise After 15 Seconds: Rebuilding a Streaming TTS Sanitizer on VicroCode

There's a bug in the market evidence that's almost too clean. Someone running long-form text-to-speech on DeepInfra noticed that around the one-minute mark, their audio snapped into harsh white noise. Not a clip, not a glitch, just the whole back half of the file turning to static. They did the right thing and captured the stream, and the cause was almost comically small: into what should have been a raw PCM16 byte stream, the host was injecting a 45-byte SSE heartbeat line (`: ping - \r\n\r\n`) roughly every 15 seconds.

Here's why 45 is the villain. PCM16 spends exactly 2 bytes per sample. The heartbeat is an odd number of bytes. The moment it lands in the stream, every sample after it is shifted by one byte, so the low byte of one sample pairs with the high byte of the next, forever. The decoder keeps playing, but it's reading garbage. Fifteen seconds of clean audio, then one odd-length line, then noise. The fix the reporter landed on is the only one that works: find that line inside the stream and strip it before it knocks your alignment off.

The signal underneath the bug

I want to zoom out before writing code, because this bug isn't really about DeepInfra. Look across the rest of the evidence and the same shape keeps showing up. The developer who forked an open-source TTS site said writing code was only about three tenths of the work, and a big chunk of the rest was fixing upstream quirks nobody had hit before, including preset voice IDs the provider had quietly removed so synthesis just 500'd. The person poking at Kling 4.0 argued that the thing deciding whether a pipeline survives long-term isn't output quality, it's task state, retries, parameter logging, version changes. Different tools, same lesson.

The durable value in an AI pipeline is rarely the model call. It's the thin, unglamorous layer you build around a stream you don't control: the part that notices when the upstream does something weird, cleans it up deterministically, and leaves a record so you can prove what happened. Models get swapped. Providers change their framing. That sanitizing-and-observability layer is the asset you keep.

So that's what's worth rebuilding here. Not the TTS engine, the durable half: a sanitizer that strips the heartbeat mid-stream, a ledger that logs every strip so you can inspect it later, and a small board so you can actually hear the before and after.

The sanitizer, as a hosted Python endpoint

The core is a byte-level filter. The one real trap is chunk boundaries: a 45-byte signature can arrive split across two network chunks, so a naive `replace` on each chunk in isolation will miss the ones that straddle the seam. The fix is to hold back a short tail between chunks and prepend it to the next one.

# heartbeat_sanitizer.py
#
# IMPORTANT: capture YOUR own stream first and confirm the exact 45 bytes.
# The literal below is a placeholder shaped like the reported SSE heartbeat.
# Treat the exact signature as something you verify, not something you assume.
HEARTBEAT = b": ping - \r\n\r\n"  # replace with the exact bytes you captured

def sanitize_stream(chunks, signature=HEARTBEAT):
    """Yield PCM bytes with the heartbeat line removed, keeping byte alignment.
    `chunks` is any iterable of byte chunks from the raw stream."""
    carry = b""
    keep = len(signature) - 1  # max length of a signature split across a boundary
    for chunk in chunks:
        buf = carry + chunk
        buf = buf.replace(signature, b"")
        if len(buf) > keep:
            emit, carry = buf[:-keep], buf[-keep:]
        else:
            emit, carry = b"", buf
        if emit:
            yield emit
    tail = carry.replace(signature, b"")
    if tail:
        yield tail

Because full signatures are already removed inside `buf`, the only thing the tail can ever hold is a partial match waiting for the next chunk to complete it, which is exactly what `keep` preserves. One more guard worth adding: after stripping, the total output should be even. If it's ever odd, something you didn't expect is in the stream, and you want to know rather than ship static.

You can stand this up as a hosted service and run Python online so the sanitizer lives behind a stable endpoint instead of in a notebook you forget about. Wrap the generator in a handler that counts and records each strip:

import sqlite3, time

def open_ledger(path="corruption.db"):
    db = sqlite3.connect(path)
    db.execute("""
        CREATE TABLE IF NOT EXISTS strip_events (
            id            INTEGER PRIMARY KEY AUTOINCREMENT,
            ts            REAL NOT NULL,
            request_id    TEXT,
            byte_offset   INTEGER,  -- clean-output offset where the strip happened
            signature_len INTEGER,
            note          TEXT
        )
    """)
    db.commit()
    return db

def sanitize_and_log(chunks, db, request_id, signature=HEARTBEAT):
    offset = 0
    carry = b""
    keep = len(signature) - 1
    for chunk in chunks:
        buf = carry + chunk
        found = buf.count(signature)
        buf = buf.replace(signature, b"")
        for _ in range(found):
            db.execute(
                "INSERT INTO strip_events(ts, request_id, byte_offset, signature_len, note) "
                "VALUES (?, ?, ?, ?, ?)",
                (time.time(), request_id, offset, len(signature), "heartbeat stripped"),
            )
        if found:
            db.commit()
        if len(buf) > keep:
            emit, carry = buf[:-keep], buf[-keep:]
        else:
            emit, carry = b"", buf
        offset += len(emit)
        if emit:
            yield emit
    tail = carry.replace(signature, b"")
    if tail:
        yield tail

That endpoint, hosted in-platform, becomes the piece you point your own capture or test clips at. It's deterministic, it's inspectable, and it doesn't care which model produced the bytes.

The ledger: proof, not vibes

A counter in memory tells you nothing an hour later. The strip events go into a SQLite table so each corruption event is a row with a timestamp, a request ID, and the byte offset where it hit. When you want to know whether your 300-plus-character synthesis jobs are the ones getting bitten, you don't guess, you query. Being able to open the SQLite editor and sort strip events by request, count them per run, or spot a job with far more heartbeats than its length should produce turns a flaky, intermittent bug into something you can see and reason about.

-- which requests took the most heartbeats, worst first
SELECT request_id, COUNT(*) AS strips, MIN(ts) AS first_seen
FROM strip_events
GROUP BY request_id
ORDER BY strips DESC;

This is the part that pays off months later. When a provider changes the exact heartbeat bytes, or starts injecting on a different interval, your ledger shows the shift as a change in the pattern instead of a mysterious wave of complaints.

The playback board: trust your ears

Numbers are good, but with audio you want to hear it. The reported failure is literally audible, so the acceptance test should be too. A small browser board with two players, one fed the raw bytes and one fed the sanitized output, lets you confirm the fix the only way that really counts. Since the stream is headerless PCM16, you wrap each version in a minimal WAV header before handing it to the player.

import struct

def pcm16_to_wav(pcm: bytes, sample_rate=24000, channels=1) -> bytes:
    byte_rate = sample_rate * channels * 2
    block_align = channels * 2
    data_len = len(pcm)
    header = b"RIFF" + struct.pack("<I", 36 + data_len) + b"WAVE"
    header += b"fmt " + struct.pack("<IHHIIHH", 16, 1, channels, sample_rate,
                                    byte_rate, block_align, 16)
    header += b"data" + struct.pack("<I", data_len)
    return header + pcm

Serve two of those from the endpoint and build a static page you can run HTML online with a before player, an after player, and a tiny table that reads recent rows from the ledger. The whole loop becomes: feed in a captured stream, hear the static on the left, hear clean speech on the right, and see the strip count that explains the difference.

<!-- board.html -->
<main>
  <h2>Before (raw)</h2>
  <audio controls src="/audio/raw.wav"></audio>
  <h2>After (sanitized)</h2>
  <audio controls src="/audio/clean.wav"></audio>
  <h2>Strips this run</h2>
  <pre id="log">loading...</pre>
  <script>
    fetch('/ledger/latest')
      .then(r => r.json())
      .then(rows => {
        document.getElementById('log').textContent =
          rows.map(r => `#${r.id}  offset ${r.byte_offset}  ${new Date(r.ts*1000).toISOString()}`).join('\n');
      });
  </script>
</main>

Where the boundary honestly is

A few things I won't pretend about, because the evidence doesn't support them and neither do the tools.

First, this rebuild doesn't connect to DeepInfra for you. VicroCode can host the Python sanitizer, the SQLite ledger, and the HTML board, and it can expose them as endpoints you call. It is not a verified live proxy sitting inline in your production TTS path at your traffic volume. Whether it holds up as an always-on inline filter under real load is unverified; treat it first as a reproducible sanitizer and acceptance harness you run against captured or test streams.

Second, the specifics of the bug come from a single report: a 45-byte SSE heartbeat, roughly every 15 seconds, white noise past the one-minute mark on long text. I'm not generalizing that to other providers or claiming it's a universal pattern. That's exactly why the code treats the signature as something you capture and confirm, not a constant you trust.

Third, the before/after improvement is yours to verify. I can show you the mechanism and the harness; I can't claim your audio comes out clean until you run your own clips through the board and listen. The ledger and the two players exist precisely so the result is something you confirm rather than take on faith.

And a scope note: the Model Center only covers models already available on the platform, so this isn't a way to route to a specific external TTS provider from inside VicroCode. The thing being built here is the durable layer around a stream, not the stream's source. That's the part worth owning anyway.