Speech Infrastructure Shaped by Daily Use
SwiftMac is a native speech server for Emacspeak on modern Macs. It turns Emacspeak's text protocol into responsive speech, tones, and audio icons through Apple's speech and audio APIs.
SwiftMac is working accessibility infrastructure used in a real development workflow. Beyond speaking text, it handles voice changes, speech queues, audio icons, tones, volume control, and multi-device routing without pushing the complexity into a cloud service or a separate desktop application.
The Problem
Blind developers need low-latency, semantic audio feedback from the tools they live in all day.
Emacspeak turns Emacs into an audio desktop. A speech server is the bridge between Emacspeak's protocol and the operating system's speech stack. If that bridge is slow, brittle, or missing semantic audio detail, the whole development environment feels slow.
Technical work also needs more than plain speech. Code, comments, links, prompts, errors, and emphasis need different voices or audio cues. A useful server has to switch voices inside a line, stop immediately, queue and dispatch speech correctly, and keep tones and sound effects from fighting with spoken output.
| Workflow need | SwiftMac behavior |
|---|---|
| Fast command feedback | Async command handling over stdin |
| Semantic text output | Voice, pitch, rate, and punctuation controls |
| Non-speech cues | Audio icons, tones, and sound-effect volume controls |
| Complex audio setups | Separate routing for speech, notifications, tones, and effects |
| Daily reliability | Simple install path, compile-time dependencies, and direct Emacspeak integration |
What We Built
A small native system focused on the speech primitives Emacspeak needs.
SwiftMac keeps the server deliberately narrow. Emacspeak and Emacs Lisp keep the higher-level decisions. SwiftMac provides the primitives: queue speech, dispatch, stop, speak a letter, play audio icons, generate tones, change voice, change rate, change punctuation behavior, and route output.
That split matters. It keeps the system debuggable and lets the user configure meaning close to the editor, while the native Swift process focuses on fast audio behavior.
Native Speech
Uses macOS speech synthesis directly for responsive local output on Apple Silicon Macs.
Audio Routing
Routes speech, notifications, tones, and sound effects to different devices or channels.
Voice Semantics
Exposes voice, pitch, rate, and volume controls so code and rich text can sound different.
What Daily Use Shows
Robert uses SwiftMac for daily development; its public releases show how latency, routing, and voice behavior changed over time.
SwiftMac’s requirements come from sustained daily use: fast interruption, reliable queues, distinct audio cues, and routing across devices. The released code and version history show how those needs shaped the implementation.
This is company Labs and open-source work, not a customer engagement. The artifact, release history, license, and behavior are public.
The evidence supports a narrower claim: local speech infrastructure can become reliable through daily use, public releases, and public code. It does not establish federal deployment or company client past performance. Solutions describes the work required for customer delivery; Capabilities separates company and key-personnel experience.
The design also shows a pattern that applies outside accessibility. When a workflow depends on a fragile interface, build a focused adapter. Keep the protocol simple. Keep configuration close to the user. Avoid hidden runtime dependencies. Make the thing usable by default.