I want my computer to read an agent's update while I keep working. This week I tested two speech paths in CKE: Kokoro and Qwen three TTS.

That is the practical reason I care about text-to-speech. My desktop has several agents, several terminals, and often several things happening at once. A written summary is useful, but when I cannot comfortably read another pane, I need to hear it. And I need to trust what I hear: a file path, a minus sign, or the difference between “passed” and “not passed” cannot quietly disappear just because it is awkward to pronounce. I wrote more about the agent workflow I want to make accessible.

Listen before reading the benchmarks

The article's audio player contains three short sections. You can seek to each timestamp. These are progress samples, not a controlled voice-quality contest: the prompts and generation paths differ.

The first section is deliberately labeled reference. It shows what the Qwen model can say with its upstream implementation, not what our C runtime can accept today. The other two sections show the narrow native paths we have exercised. Listening is still the test for whether the pronunciation is pleasant and understandable; a valid WAV and a passing numerical comparison do not answer that for a person.

Two routes to a waveform

Both systems end with samples that a browser can play. They get there differently. Kokoro first turns text into phonemes and predicts their duration. Qwen3-TTS turns text into a sequence of acoustic codes and decodes those codes into a waveform. In CKE, the important engineering question is not just “does the model make noise?” It is whether each generated C call has the right shapes, state, weights, and numerical result.

Where Qwen is today

We chose the pinned Qwen3-TTS 12 Hz 0.6B CustomVoice model, not an unnamed “latest” model. The reference implementation is pinned to this source revision. For one small prompt, CKE's generated path now goes all the way from the selected text IDs through the 28-layer talker, five-layer code predictor, 16-group codec, and a 24 kHz waveform. If you want the architecture first, my earlier Qwen/Kokoro comparison walks through why the two routes differ.

For “Hello, this is CKE.”, the generated run reached the same 736 acoustic code IDs as the reference: 46 frames times 16 groups. It returned 88,320 samples, or 3.68 seconds of audio. The largest absolute difference from the pinned reference waveform was 1.33 × 10⁻⁶. That is a real end-to-end numerical result for this trajectory. It does not prove the generated route can read this whole article, or even a different-length sentence.

The runtime gained a small native speech session around that circuit: it checks the model files, prepares the supported text, keeps weights loaded, clears mutable state between requests, writes a WAV only after valid samples are published, and can stop at checked boundaries. A second seven-token sentence, “Yes, this is CKE.”, also has a reference comparison. The current native host accepts nonempty English text only when it maps to exactly seven context tokens. A newer prefix/cache test handles two- and seven-token requests across all 28 talker layers, but continuation still assumes the fixed position. That is why I am not calling it arbitrary-text speech yet.

The initial full generated run took 338.64 seconds for 3.68 seconds of audio on an Intel Core i7-14700T. Selecting a checked AVX2/FMA Conv1D provider for the codec brought two measured runs to 197.43 and 196.20 seconds, while preserving the code IDs and waveform hash. That is a substantial kernel improvement, and still far too slow for an interactive desktop assistant. It is one host, one utterance, and an optional provider; it is not a general speed promise.

Where Kokoro is today

Kokoro 82M is the smaller route we have been pushing toward practical accessibility. Its frontend uses pinned Misaki phoneme preparation. CKE has generated native speech for small known phrases. In an optional Kokoro-to-Whisper round trip, “Hello.” and “Hello there.” produced 24 kHz mono WAVs and CKE's generated Whisper path transcribed those same phrases. That checks an audible route more directly than inspecting a waveform array, but it is still a two-phrase test. The dilated-convolution walkthrough goes deeper into one of the kernels behind that sound.

Kokoro also has a bounded whole-text planner and session experiments. They handle a wider class of text by checking and chunking source spans before synthesis, and reject material they would silently misread. One important example: a dollar amount whose dollar sign would be lost is rejected instead of read as a different amount. This matters when the “text” is an agent's technical status, not a bedtime story. The connected native waveform still has an unresolved comparison against the pinned PyTorch numerical ceiling, so I would not hide that behind a passing WAV or Whisper transcript.

The comparison that matters to me

Here are the two native CKE clips without making you scroll back to the article player. They are short, different prompts, so listen for what each route is currently producing rather than treating this as a blind voice-quality contest.

The Qwen reference itself gave us a useful warning. A literal path plus “−3.5, not +3.5” ran into a 320-token generation cap under greedy decoding instead of naturally stopping. Under a sampled policy, that case stopped after 142 audio frames and produced 11.36 seconds of audio in 32.35 seconds on P3. We need a stop decision, source-text trace, and listening check before treating a long technical response as read successfully. A cap is a safety rail, not evidence that the sentence finished.

What I want next

I want to select an agent, hear its latest update, interrupt it, repeat the exact line, and know which system spoke it. The original answer should remain visible and recoverable. An unknown path, a negative number, or an error code should be announced accurately or explicitly declined. If CKE cannot handle a request, LinuxUtilities can offer a clearly announced system-voice fallback instead of silently pretending the native route worked.

So the next tests are not more “it made a WAV” demos. They are: variable-length Qwen continuation; full text-to-phoneme and waveform checks for Kokoro; a representative corpus of paths, numbers, commands, and mixed prose; time to first audio; stop latency; and human listening on my headset. The little player in this post is the point of the work. It lets you hear exactly which boundary has been crossed, and which one has not.

Keep reading

If you are curious about how speech becomes kernels, start with How Kokoro TTS Works and Where CKE Stands, then follow the dilated-convolution visual walkthrough. For the other model family, Qwen3-TTS and Kokoro: Two Routes from Text to Speech explains the different model shapes before this week's native progress.

For the reason behind all this work, read I Want to Use My Linux Workstation Without Looking at It and Talking to the Agents Without Losing the Thread. And if you want to see how cautiously I treated an earlier milestone, CKE's First Kokoro WAV Is Not Ready Yet is the historical baseline, not today's status.

Evidence snapshot: CKE TTS bring-up and retained P3 artifacts inspected October 30, 2026. Audio samples are labeled by execution path; no production speech service or general accessibility quality is claimed.