(Also, I know it's besides the point but this might be the most painful way to connect to Wifi physically possible. "Make normal everyday tasks slow, tedious and painful" is a bit of an odd choice for a product demo.)
Say, speaking of Sam, what were the memory requirements for SAM (Software Automatic Mouth) on C64. I guess they were not more than 64K? Although, the bulk here is probably for the speech recognition, not the TTS. (And this one does sound a little nicer :)
Browser demo of a reversed SAM:
According to [1], the weight of a modern runnable version is around 39k.
The ratio of how good it sounds compared to how much computing power it uses is ridiculous. The C64 has ballpark 3 orders of magnitude less CPU throughput as an RP2350, and the codebase uses an impressive array of tricks to do actual formant synthesis (barely) and a pretty refined form of Elovitz text to phoneme conversion. One of my favorite tricks is its up and down bouncy pitch, which is not random, but based on the opposite contour as the first formant. It's simplistic but enough to make it not sound like a robotic monotone.
I've been playing around with this some myself and SAM is an inspiration, along with other landmark systems like MITalk (predecessor to DECtalk), SP0256, and other. I believe it's possible to use modern techniques to get pretty good sounding speech in, say, 64k and 10% of the throughput of a RP2350. It's really cool to see projects like OP, especially under permissive license.
Played by the great Richard Kind, who my wife swears she saw on the Highline in NYC.
Flite for comparison: https://github.com/festvox/flite
I’ve worked in this space. TTS in a small footprint isn’t the hard part —- it’s doing it accurately that’s hard.
Although for the use cases OP is targeting, lower accuracy may be good enough!
This actually holds for everything in AI.
https://github.com/moonshine-ai/moonshine#when-should-you-ch...
uv init
uv add moonshine-voice
uv run moonshine-voice mic --language en
good job on a clear readme.md tbh
air a
bat b
cap c
drum d
each e
fine f
gust g
harp h
sit i
jury j
crunch k
look l
made m
near n
odd o
pit p
quench q
red r
sun s
trap t
urge u
vest v
whale w
plex x
yank y
zip zTTS (neural diphone synth @ 16 kHz) ~1.8 MiB voice pack
This is in the realm of Microsoft Sam.
The project credits does mention espeak (which is formant based) as well as various other TTS projects, although it sounds like they are only using the pronunciation part of espeak, not the voice synthesis.
Having it run on a pico would be pretty impressive =3
Yes, although relative to the DECTalk DTC01, a Pi Pico is a beast !
Pico : dual core ARM @ 133 MHz, 2MB flash, 264K RAM
DECTalk: 68000 @ 10 MHz + TMS 32010 @ 20 MHz (5 MIPS), 256K ROM, 64K RAM
Couldn’t find a link, is that hard to do?
One gotcha if anyone wants this in a Chrome extension: MV3 requires 'wasm-unsafe-eval' in the CSP for any wasm at all, which surprised me the first time a build that worked fine as a web page died silently as an extension.
[1] https://blog.trulm.com/posts/speech-as-independent-parts/
I think my small Talon models are next, around 3% lsc clean at ~28M (greedy CTC decoding, no external encoder, no LM, not trained in a domain specific way). I reached around 6.5% at 10M.
I've been working on some new baselines I want to release soon as public artifacts. This article is inspiring me to try pushing the param size down a bit. I suspect we can do large vocabulary end to end in the <5M range.
Fishing for anecdotes here, does anyone have any good tts/stt experiences?
I started ottex half a year ago after I tested gemini 2.5 flash native audio support. I was blown away by the quality of transcripts and decided to built an app to use it myself.
Currently the default model in the app is Gemini 3 flash, but you can connect to 9 providers and God knows how many models to play with.
I would suggest you to try this models for ai prompting:
- Gemini 3 / 3.5 flash - Soniox rtt v5 - Mistral transcribe v2 - assembly 3.5 pro
I intend to use it to work on low stakes vibe coding projects while I'm doing other stuff. Todays LLMs are a lot better at interpreting rambling dictation with mid-message corrections.
There are a few paid programs out there that do the same, but they made my vibe slop sense tingle and are not aimed at development.
I would die In minutes
https://etsc.eu/tiny-proportion-of-drivers-understand-danger...
Seems like an overreaction.
All the studies show it's not an over-reaction, you're 400% more likely to have an accident. It is extremely dangerous and it's not an over-reaction, the more people do this, the more people die. It's simple maths. If you're doing extended programming sessions, you're not paying attention to the road like you should be.
And no, talking to a passenger is not as dangerous as it's a different cognitive load.
It'll take you 20 seconds to google this, please do and stop putting everyone else in jeopardy.
After googling the 8th or 10th result had a link to the study I assume you are referencing.
I just don't agree with you. I believe that there is risk when driving inherently although relatively low and a 400% increase from 0.0001 to 0.0004 does not really concern me.
I have been in one accident in 15 years and I was not at fault and it was unavoidable.
Many people engage in all sorts of distracted driving, texting, eating, driving while tired etc. which I would wager are more detrimental than speaking on the phone.
Having your one bone to pick being speaking on the phone just seems absurd and an odd message to preach when nearly everyone does it.
The difference between talking to a passenger versus using a hands-free phone is an interesting one. While they intuitively feel similar, it has been shown that speaking on the phone results in significantly worse performance. This is because a passenger shares awareness of the driving situation and surroundings. Their conversation naturally adapts to traffic conditions, often pausing or shifting topics to focus on the road, which can help with awareness.
Texting and eating are far more dangerous as they divert eyes from the road and introduce motor interference. Fatigue also severely degrades both attention and cognitive function.
Coding while driving does seem unnecessarily risky though. Unlike other non-motor distractions, it demands more cognitive engagement without necessarily moving your hands or eyes. It is far more demanding than a standard phone conversation, which has already been shown to impair driving.
You will make errors that you won’t remember because your brain is occupied with the code rather than monitoring the environment.
Your ability to recognize objects and react slows down. If a child runs into the road, that split-second delay could mean the difference between stopping or killing them. The same applies to sudden obstacles like kangaroos in my case. The delay in reaction could turn a near-miss into a fatal crash.
Most of the risk lies in the complex and unexpected situations. It's really not worth it, just listen to some music or an audiobook and enjoy your ride. Do coding later.
If you have any other psychology or cognitive-related questions to it I can try and answer. I'm not an expert in this specific area but we did some work on it at university.
But there are countless projects I work on this way. Eg, I got an email from person X, it says it encountered a bug when doing x and y. Codex reads the email (using nvidia/gliner-PII to hide PII data) and investigates the reason for the bug and proposes a solution. I ask it to implement the fix on my dev server and increase test coverage. I enjoy my walk and after say 7 minutes get a an overview of the fix and can decide to deploy to production.
Edit: never mind, I see you already suggested the Shokz OpenComm2 in another comment. Thanks!
However, being able to interact with these natural language systems in uncontrolled settings is still a fools errand. For STT, there is also regional dialect, slang, and individual differences.
Witnessing blind users hit unrecognizable reading-speeds on old Gordon 8 TTS systems was surprising. I learned people adapt to imperfect systems pretty quickly. =3
Running speech recognition and TTS locally is quite feasible, as projects like this one show.
ouch - this is ironic in an extreme, given Apple's OS layers and anti-GPL efforts
next, personal computers that come with a secret OS that can read all RAM by remote command?
(this inspired some more demo-y stuff I have where claude can manipulate the mouse and audit things it's built visually in conjunction with that). I'm sure this has already been wrapped up into some MCP framework, but it was fun to build it super early on and it just sort of works for me.
I don't use this in my day job, but it does feel very futuristic when I pull up my home lab.
[1] hex https://github.com/kitlangton/Hex
I used to use Handy but as of a few months ago it had stuttering and other issues so I switched to Hex. Even for relatively long minute long dictation, transcription is near instant and accuracy is more than sufficient, especially when talking to AI since it that can “read between the lines “.
Using voice with code agents is a huge unlock and I’m surprised to see some people I recommend it to, still resist it.
As for TTS I found it fun to make a voice plugin for Claude Code that uses PocketTTS, so it can give brief updates whenever it finishes a turn:
https://pchalasani.github.io/claude-code-tools/plugins-detai...
I built this myself with whisper -> “secretary” prompt -> Claude Code, but having the first two steps be interactive is really what I would want.
I acknowledge this may just mean I haven't tried enough modern voice recognition systems. But I've used Whisper and I don't think it works nearly as well for real-time speech.
(I still don't tend to use voice mode in Claude Code because I find typing more comfortable.)
If I get time, I would like to try compiling it to WASM. This would allow me to swap my robot poet’s native browser voice synthesis for it. Not sure if it is worth it, but it will be fun to play around with.
Edit: typo