

Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Could hang an i2c flash chip off that thing for more storage and still have enough IO pins for serial coms and a spare IO pin.by MisterTea
- Interesting, though before clicking I thought the headline might be referring to a very poorly paid presentation about Marvel movies.by docdeek
- Even easier is the 1-bit DPCM codec used on the NES. Go up or down one step each sample depending on the next bit. You can't get a square wave out of it, only a triangle, but it has a nostalgic quality.by sehugg
- You should be able to do it all on-device, check out SAM, the Software Automatic Mouth. The actual data in the *_tabs files:by ctoth
- Nice work. Especially referencing the TI prior art of the Speak and Spell. This kind of synthesis was quite prevalent in the early 80s - school BBC Micros had a ROM which let you "*SAY" a phrase. Classic Macs had MacinTalk.
Another codec which might be interesting to try but is considerably more complicated is AMR, from GSM: https://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_code...
by pjc50 - This is great. Missed opportunity for a low-pass RC filter on the speaker circuit - if you know you're driving an 8kHz sample rate, you can design your filter with that cutoff, and it'll sound way better (it'll get rid of the buzzy quality).
- It's probably worth mentioning the 2400bps (300 bytes per second) LPC10 codec built into SoX. If you have SoX installed, try
and then speaking into your microphone for ten or fifteen seconds before you ^C it. Then play it back withrec -t lpc10 speech.lpc
It will sound very robotic but pretty comprehensible, at least with an adult male voice in English, and it preserves a lot of the prosody and enunciation that is so hard to get out of speech-synthesis packages.play speech.lpc12KiB of data at 300 bytes per second would be 41 seconds of recorded speech.
Decoding the LPC10 data on the CH32V003 might be tricky. On amd64, running `make CFLAGS=-Os` followed by `ld -r -o tmp.o *.o` inside sox-14.4.2+git20190427/lpc10 yields a tmp.o with 25243 bytes of text (including .rodata, etc.) and 356 bytes of data. I'm not optimistic that RISC-V would compress that to fit inside the CH32's flash. And I find the code in that directory inscrutable; it's Fortran that's been compiled to C.
Still, it seems plausible that you could massage the LPC10 data into a format that something like Talkie would understand.
by kragen - These CH32 mikrocontrollers are great and dirt cheap. I've build a small DC motor controller with them to control a toy robot: https://github.com/h0lad/MiniSpeedController
The bigger ones have PHYs for USB HS, USB-C (5Gbps) and 10/100M Ethernet integrated (!). And their development environment (Mounriver Studio) isn't too bad - I didn't had the immediate urge to port everything to CMake/VSCode.
But they need some kind of pin planning tool. It's awful to use the datasheet and find the correct pin functionalities and their mutual exclusions... STM32 mastered this with their STM32CubeIDE tool: select a feature (like USART1) and the right pins light up - alternate pins are easy to locate.
They also should clean up their license mess on OpenWCH (their GitHub page). Lots (all?) of their HALs are Opensource - but the right version with right SPDX tags are often a bit hidden.
by NoiseBert69