Question.

[willwade]

TTS is a bit of a pain. What if we ditched it for GTK???

So rust-tts-wrapper is in https://github.com/AACTools/VoiceGarden-SPD and https://github.com/AACTools/VoiceGarden-SAPI (so speech engines for Linux and Windows). SPD isnt fully tested.. if you wanted to look at that @owenpkent pls do!

Its a problem as Dasher-Apple (particularly iOS) couldn't use this - we could do a apple AVSynth engine for Apple in the same way .. which then leads to Android.. Again we could do that there.. Basically every platform EXCEPT iOS could just use the standard OS interface for speaking. And we'd get the same parity of voices etc - but with less dev overhead in Dasher-*

Not sure. Thoughts welcome

W

[owenpkent]

I think this is the right direction, but I would frame it differently, because the framing changes what we are actually deciding.

We would not be ditching rust-tts-wrapper, we would be unlinking it

Both of the projects you point at are built on it. VoiceGarden-SPD's Cargo.toml:

rust-tts-wrapper = { git = "https://github.com/AACTools/rust-tts-wrapper", tag = "v0.3.18", default-features = false, features = ["sherpaonnx", "cloud"] }

and VoiceGarden-SAPI is a SAPI5 COM provider over the same crate. So the 1300 sherpa voices and the 20 cloud engines do not go away, and neither does the maintenance of them. What changes is where the boundary sits: today Dasher-GTK statically links a Rust library through a C FFI, and under this proposal it would talk SSIP to a process that links it instead.

That is a much easier thing to argue for than "ditch TTS", and I think it is clearly correct.

What Dasher-GTK actually sheds

Everything below is a real cost we are paying in this repo right now, not hypothetical:

• Cargo becomes a hard build dependency for anyone building the frontend. CMake shells out to cargo build --release and every contributor compiles ~8k lines of Rust plus rustls, ICU4X and symphonia before they see a window. Nothing about editing a GTK dialog needs a Rust toolchain.
• A per-platform feature matrix: system,cloud on Linux, sapi,cloud on Windows, avsynth,cloud on macOS, plus a cloud-only fallback when the speech-dispatcher headers are missing, and that choice is baked into the CMake cache at configure time. This came up in review on feat: add run.py, a cross-platform build-and-launch helper #46 last night as a footgun, and it only exists because we compile the engines in.
• Conditional linking: speechd is linked only when the system feature is on, because cloud-only builds have no speechd symbols and the Flatpak SDK has no libspeechd at all.
• The Flatpak is cloud-only today as an explicit compromise, with a comment in the manifest saying so: "Flatpak uses cloud-only TTS (no speech-dispatcher) to avoid building dotconf/libspeechd in the sandbox." An SSIP socket needs nothing built in the sandbox, so this is the case that improves most.
• An FFI memory-safety surface we have already been bitten by. b3b4b4b chore: bump rust-tts-wrapper to pick up tts_free_voices UAF fix was a use-after-free reaching us across the C boundary. A process boundary deletes that whole class.
• C API churn we track by hand, e.g. feaae93 Update TtsService.cpp for rust-tts-wrapper C API changes.

The swap itself is small, which surprised me

I listed every wrapper symbol TtsService.cpp actually calls: tts_speak, speak_sync, stop, pause, resume, set_rate, set_pitch, set_volume, set_voice, get_voices, get_engines, get_last_error. That is it. We use no boundary or viseme callbacks, even though the C API offers them.

Every one of those maps onto plain SSIP (SPEAK, STOP, PAUSE, RESUME, SET SELF RATE|PITCH|VOLUME, SET SELF SYNTHESIS_VOICE, LIST SYNTHESIS_VOICES, LIST OUTPUT_MODULES). TtsService is 186 lines and its public interface would not need to change at all - only its body, and it would lose the FFI. So the cost of this is genuinely low on our side.

The three things I would want answered before committing

1. The speech-dispatcher version floor, which is the one I can help with. VoiceGarden-SPD's README says 0.12+ and lists Debian 13+, Ubuntu 25.04+, Fedora 41+. It does not list Ubuntu 24.04 LTS - but 24.04 ships speech-dispatcher 0.12.0~rc2 (I am on 24.04.4 and that is what is installed here). Whether an RC counts as 0.12 for the module API VoiceGarden-SPD needs is exactly the untested bit you mentioned, and it matters a lot: 24.04 is the LTS most of our users will be on for years. Happy to take this - I have the machine for it.
2. Flatpak sandbox reachability. We would need the spd socket exposed (--filesystem=xdg-run/speech-dispatcher or equivalent), and spd already running on the host, since autospawn from inside a sandbox is not something I would rely on. If that works it is a straight win over today's cloud-only Flatpak; if it does not, Flatpak users lose TTS entirely, which is worse than the status quo. Worth proving before anything else.
3. Where credentials live, which is a product decision rather than a technical one. Our Speech page currently enumerates the engines and collects per-engine API keys (azure wants subscriptionKey+region, polly wants three, and so on) and hands them to the wrapper. Under SPD that configuration moves into VoiceGarden-SPD, and Dasher's page shrinks to picking a voice from whatever SSIP offers. I actually think that is better for AAC - one place to configure voices, shared with Orca and everything else, instead of each app hoarding its own API keys - but it does mean Dasher on a stock machine with no VoiceGarden installed gets whatever espeak-ng voices spd has, and nothing more. If that is the intended outcome, fine; we should just say it out loud, and decide what the app does when spd is absent entirely.

On iOS

Small correction to the framing there: iOS does have AVSpeechSynthesizer, so Dasher-Apple can speak with OS voices on iOS the same as macOS. What iOS lacks is the ability to inject extra voices system-wide the way SAPI5 and spd modules let you, so the gap is the 1300 sherpa voices and the cloud engines, not speech as such. Worth someone on the Apple side checking whether iOS 17's speech synthesis provider extensions (AVSpeechSynthesisProviderAudioUnit) are the equivalent trick - if they are, the "every platform except iOS" caveat may be narrower than it looks. I have not tested that and it is not my area.

Overall: yes, and I would like to start with (1) since you asked. If VoiceGarden-SPD works on a 24.04 LTS box I will report back with what it took.

[owenpkent]

Took (1) as offered, and then built the Dasher side to go with it. Summary first: the version floor is fine, but VoiceGarden-SPD cannot currently speak, and it fails silently.

1. Ubuntu 24.04 LTS / speech-dispatcher 0.12.0-rc2: the floor is not the problem

Installed v0.3.0 via the user-local tarball path (voicegarden-spd install, no root). Its own doctor is happy with the RC:

  [ok]   speech-dispatcher version: 0.12.0-rc2
  [ok]   daemon socket: /run/user/1000/speech-dispatcher/speechd.sock
  [ok]   module binary: ~/.local/libexec/speech-dispatcher-modules/sd_voicegarden
  [ok]   registration: AddModule in ~/.config/speech-dispatcher/speechd.conf

voicegarden-spd refresh pulled 322 edge voices with no credentials, and the daemon enumerates every one of them through the module (spd-say -o voicegarden-spd -L → 322). So the README's "Ubuntu 25.04+" line is more conservative than it needs to be: 24.04 LTS works, which is the answer that matters for us.

2. It cannot speak, and the cause is the SSML envelope

Every utterance through the daemon fails, 100% reproducible:

voicegarden-spd: engine 'edge' voice 'en-GB-SoniaNeural' ← "<speak>Repeat test number 3</speak>"
voicegarden-spd: synthesis failed: synthesis worker vanished

The ← line is the clue. speech-dispatcher wraps message text in a <speak> envelope for index marking, and the module hands that to the engine unmodified. Reproducible with no daemon involved at all, straight from their CLI:

input	result
Plain text	OK, 156672 bytes of PCM, ~213 ms
<speak>Wrapped</speak>	synthesis produced no audio
<speak>With <mark name="i1"/> a mark</speak>	synthesis produced no audio
Angle < bracket	OK

So it is specifically the SSML envelope, not angle brackets in general, and synthesis itself is healthy and fast (bench: 213 ms median warm). Something in the cloud engine's SSML path returns an empty buffer for edge. I only have edge to test with (the only engine needing no credentials), so I cannot say whether sherpa-onnx or the credentialled cloud engines behave the same.

The part I would fix first is not the bug, it is the reporting. The module still emits 701 BEGIN and 702 END to the daemon after synthesis has failed, so the daemon reports success, spd-say exits 0, and the client believes it spoke. For an AAC user that is the worst available failure mode: no audio, no error, nothing on screen. Whatever the SSML fix turns out to be, a failed synthesis needs to reach the client as a failure.

3. One installer bug worth a one-line fix

The user-local install writes a ~/.config/speech-dispatcher/speechd.conf containing only its own AddModule line. speech-dispatcher auto-detects modules in the module directory only while no AddModule is configured, so the moment that file appears, auto-detection stops and every other module vanishes from the session. On this box that silently took espeak-ng with it, along with the system config's SymbolsPreproc* settings. Anyone running Orca on espeak-ng would lose their screen reader's voice by installing VoiceGarden. The installer should append to a copy of the effective config, or register the other modules alongside itself.

Happy to file 2 and 3 upstream on AACTools/VoiceGarden-SPD with the reproductions if that is useful.

4. The Dasher side, which is the encouraging half

Branch: spike/tts-over-ssip (43561cb). SsipTtsService presents the identical interface to TtsService, so MainWindow and PreferencesWindow change only in which type they name. Every wrapper call maps to one SSIP command, and the callbacks that do not map (word boundaries, visemes) turned out to be unused:

speak/speak_sync  SPEAK + data block    set_voice    SET self SYNTHESIS_VOICE
stop              STOP self             get_voices   LIST SYNTHESIS_VOICES
pause/resume      PAUSE/RESUME self     get_engines  LIST OUTPUT_MODULES
set_rate/pitch/volume   SET self RATE|PITCH|VOLUME   (scaled to -100..100)

Selected with -DDASHER_TTS_BACKEND=ssip, which also skips the cargo step entirely. Configure + build from an empty directory on this machine:

	wall	cpu	binary	tts_* FFI symbols
wrapper backend	1m16s	9m24s	17.7 MB	27
ssip backend	29s	4m49s	3.6 MB	0

(Caveat on the wrapper row: my cargo registry cache was already warm, so a genuine first clone pays download time on top.)

Verified against the live daemon: enumerates both output modules and all 13362 espeak-ng voices, speaks, pauses, resumes, stops, and escapes a leading . so user text cannot terminate the message early. prefs_rebuild_selftest passes 8 rounds against the ssip build, which drives the Speech page's get_engines()/get_voices() through the real PreferencesWindow, and the app registers as SSIP client owen:dasher:main on startup.

One thing the spike settles: espeak-ng through my SSIP client works perfectly. The only thing that does not work is VoiceGarden itself. So the architecture you are proposing is sound and the Dasher-side cost is genuinely low; the risk is entirely in the module's maturity, which is what you suspected.

Where that leaves it

I would not move Dasher onto SSIP until (2) is fixed, because today it would mean shipping an app whose speech silently does nothing on any machine using VoiceGarden. But nothing I hit argues against the direction, and the cost on our side is a ~250-line class and the deletion of the entire cargo/feature-matrix/FFI apparatus. Still unresolved and unchanged from my earlier comment: where credentials live, and the Flatpak socket question.

[willwade]

Pause on this a bit.. Im doing more work on it alll.