webui: split TTS text on sentences in Latin-script text

[christopherthompson81]

Problem

splitTtsChunks treats 。！？!?；;… as sentence terminators. ASCII . is not among them, so a paragraph of Latin-script prose is one unsplittable sentence and falls through to the fixed-width cut in splitLongLine, which lands mid-word.

Each chunk becomes a separate synthesis request, so a word split across two of them is pronounced as two fragments.

splitTtsChunks("The first sentence is here. The second follows it closely. A third
                arrives now. And a fourth, rather longer than the others, continues
                past the point where a small budget would have to cut. Finally a fifth.", 60)

[60] The first sentence is here. The second follows it closely. A
[60]  third arrives now. And a fourth, rather longer than the oth
[60] ers, continues past the point where a small budget would hav
[26] e to cut. Finally a fifth.

The budget is 1000 by default so this needs a long paragraph to bite, but voxcpm2 defaults to 60 and vibevoice to 600, where it bites immediately.

Fix

. now terminates a sentence, with the guards that make it ambiguous in the first place:

• not between digits, so 3.14159 stays whole;
• not after a known abbreviation or a single-letter initial, so Dr. Smith and J. R. R. Tolkien stay whole;
• only before whitespace or end of text, so file.txt and example.com stay whole.

Where no sentence boundary fits the budget, the fallback breaks on words rather than characters, so only a token longer than the entire budget is ever cut mid-word.

[58] The first sentence is here. The second follows it closely.
[20] A third arrives now.
[59] And a fourth, rather longer than the others, continues past
[49] the point where a small budget would have to cut.
[16] Finally a fifth.

Two smaller fixes alongside:

• a Speaker 1: prefix is counted against the budget. It is repeated onto every chunk a line produces, so chunks carrying one previously exceeded the caller's limit — at budget 40 the first chunk came out 49 characters.
• chunks are trimmed, so a prefixed chunk no longer carries a double space.

Behaviour that does not change

CJK is unaffected: the existing terminators still apply and . is additive. 今天天气很好。我们去公园吧！你觉得呢？ splits at the same places.

The abbreviation list is not exhaustive and cannot be. A miss costs a split in a slightly wrong place, not a failure.

Checks

Exercised against the cases above plus filenames, initials, speaker prefixes, CJK and multi-line input. npm run check is clean and dist/index.html is rebuilt, as webui commits here do.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EkxqpYvUbjCpRDnFiNiVfx

[christopherthompson81]

The failing job here is Nix (vulkan), with an undefined reference to a generated shader symbol:

ld.bfd: ggml-vulkan.cpp:3964: undefined reference to
  `matmul_id_subgroup_nvfp4_f32_aligned_f16acc_cm1_len'

This PR changes two web UI files, TypeScript and the built bundle — no C++ — and the C++ tree is identical to main. Linux vulkan passes on the same commit, and #536, which does change C++, passes Nix (vulkan).

I looked into the cause rather than assuming it was unrelated. Building shaderc 2026.1, the version this job uses per its log, and compiling that exact shader with its exact 17 defines gives exit 0, no stderr, and 27,700 bytes of valid SPIR-V. 120 repeat compiles under parallel load produced no anomalies, and a full Vulkan build with that compiler and all four shader extensions enabled links cleanly — 2320 symbols declared, 2320 defined.

So the shader and the compiler are both fine. Something in the build environment produced an empty SPIR-V file while reporting success, and vulkan-shaders-gen turns that into a declaration with no definition, which only surfaces at link. #540 makes that path retry and, failing that, report the shader by name at generation time.

Could you re-run the Nix (vulkan) job here? I expect it to pass on identical content. I do not have permission to re-run it myself.

[0xShug0]

@christopherthompson81 That's a false postive. It has happened quite frequently. I've asked for help on Reddit.

[christopherthompson81]

#540 is a possible CI fix. It makes it fail shallow and fast, plus adds a retry for the specific thing that seems to fail transiently.

[0xShug0]

@christopherthompson81 This may not be a merge blocker, but I’d appreciate your thoughts. Shouldn’t we preserve the original spacing between sentences instead of always adding a space?

Say 40 budget and Chinese input: 今天天气很好，我们大家一起去公园散步吧。今天天气很好，我们大家一起去公园散步吧。今天天气很好，我们大家一起去公园散步吧。(full-width punctuation mark, looks like a space but isn’t one)

Before:
[40] 今天天气很好，我们大家一起去公园散步吧。今天天气很好，我们大家一起去公园散步吧。
[20] 今天天气很好，我们大家一起去公园散步吧。

After:
[20] 今天天气很好，我们大家一起去公园散步吧。
[20] 今天天气很好，我们大家一起去公园散步吧。
[20] 今天天气很好，我们大家一起去公园散步吧。

That's an extra request and higher latency.

[christopherthompson81]

Good catch — thank you.

Fixed by carrying the separator that actually followed each sentence. Your example now gives what you expected:

before:  [20] 今天…吧。   [20] 今天…吧。   [20] 今天…吧。
after:   [40] 今天…吧。今天…吧。          [20] 今天…吧。

There is no test harness under webui/native, so I verified by compiling text.ts with the bundled esbuild and running splitTtsChunks directly over a 17-case corpus — abbreviations, initials, speaker prefixes, a token longer than the budget, multiple spacing, newlines, CJK, Japanese, and mixed scripts — diffing the output before and against the fix. Those two cases are the only ones whose output changes.

Also rebased onto current main, which clears the conflict. That conflict was only in webui/native/dist/index.html, and it is worth mentioning separately: building unmodified main does not reproduce the committed bundle, because SvelteKit embeds a per-build random identifier (__sveltekit_191iq4z vs __sveltekit_1w7a9yp).

[0xShug0]

Happy to open a separate issue if that is useful.

Yes please. I thought that was just how the UI worked, so I never looked into it.

[0xShug0]

Merged!