Sprachausgabe

Für Telefonanwendungen sollte eine Sprachausgabe in den Mikrocontroller hineinpassen. Das erspart eventuell Displays und ähnliches. Um nicht extra Flash-Speicher anbauen zu müssen kommt nur synthetisierte Sprache in Frage, wie sie in den 80-er Jahren des letzten Jahrhunderts üblich war: Eine Roboterstimme mittels Formanten. Klingt altbacken, aber ist verständlich und erfüllt den Zweck. Leider ist dazu kaum Software aufzutreiben. Schon gar nichts was in einen 8-Bit-Mikrocontroller passt. Auch klingt alles (was es so gab und gibt) englisch. Eine Deutsch-Anpassung wäre hilfreich. Dazu ist eine Anpassung des Vokaldreiecks erforderlich. Das „Übersetzen“ von Text in Phoneme kann zur Compilezeit erfolgen, sodass der Mikrocontroller nur noch konstante Phoneme ausspucken muss.

Eine Alternative ist eine auf Sprachausgabe optimierte Audiokompression: LPC = Linear Predictive Coding nennt sich das, und dafür gibt es (zu spät, 2021 gefunden) eine Arduido-Implementierung: Talkie nennt die sich.

Ausgangspunkt für die phonembasierte Sprachausgabe ist eine auf der Softwaremüllhalde gefundene Abandonware, dessen Quelltext offenbar von einem Disassembler / Decompiler stammt, mühevoll zur Funktion gebracht aber bei weitem noch nicht ausgemistet.

Erste Überarbeitung

Hier ist der erste Entwicklungsstand abgelegt. Ausgangspunkt ist die Sprachausgabe für einen 32-Bit-Mikrocontroller namens ESP8266 mit WLAN auf dem Chip, wie's scheint. Ich brauche es allerdings für 8 Bit Verarbeitungsbreite.

Es ist soweit umgestrickt, dass:

• Etwas (oder erheblich) mehr Struktur drin ist
• H-Dateien weder Kode noch Daten enthalten
• Dass man es sowohl für AVR als auch für Windows compilieren kann
• Dass es unter Windows spricht: Einfach mittels sndPlaySound
• Dass man es in 3 Schichten aufteilen kann: "Can you hear me now?"
  • Englisch-zu-Phonemschrift-Konverter "KAEN YUW /HIY5R MIY NAW4?"
  • Phonemschrift-zu-Binärphonem-Konverter L"\x0648\x0149\x044A\x0B08\x071C\x041A\x0935\x0814\x6224\x5B05\x0A12\x071B\x0805\x581C\x4F33\x4D14\x0202"
  • Binärphonem-zu-Waveform-Konverter 22 kSa/s mono 8 bit
• Dass die kleinste Windows-Echse 8 KByte groß ist
• Dass Nullterminierung die seltsame 155-Terminierung ablöst

Die (überflüssige) Phonemschrift stammt noch aus der Quelltextvorlage.

Der Binärphonem-String ist aus 3 64-Byte-Puffern entstanden (array-of-struct statt struct-of-array) und kann zweckmäßigerweise als Unicode-ähnliche wchar_t-Zeichenkette abgelegt werden.

Zweite Überarbeitung

Immer noch darauf aus, den Wust auseinanderzunehmen, habe ich das Programm in 4 Teilprogramme aufgeteilt, die dazu bestimmt sind, in eine Pipe verkettet zu werden. Das Kunswerk ist diesmal nur für (das gute alte) Visual Studio 6 gemacht. Um es selbst zu kompilieren benötigt man mein msvcrt-light-Paket. Denn nur so ist sichergestellt, dass das Kompilat auch wirklich nur aus selbstgeschriebenem Kode besteht. Andernfalls wirft der Kompiler mehr oder weniger viel Microsoft-Kode hinein, 30 Kilobyte Minimum.

Nur das dritte Teilstück muss in einen AVR implementiert werden. Da sogar das Windows-Programm (die „Echse“) < 8 KByte groß ist, passt es sicherlich mühelos in einen ATmega32-8 oder -U4, also Arduino Uno oder Leonardo. Natürlich nicht diese „Echse“, sondern das Ergebnis der Kompilierung des Quelltextes mit avr-gcc. Entsprechende PROGMEM-Attribute für die Tabellenablage im Flash-Speicher und pgm_read_byte()s zum Lesezugriff darauf sind bereits eingebaut.

Immer noch sind eine Unmenge gotos mit Sprungmarken aus Hexadezimalzahlen sowie globale Variablen drin. Das auszumisten wird noch zwei weitere Überarbeitungen erfordern, ganz zu schweigen von der Aufgabe, das ganze etwas mehr deutsch klingen zu lassen.

Die Teile im einzelnen:

• s1.exe konvertiert einen (englischen) Text von der Standardeingabe in eine Art Lautschrift und gibt diese auf die Standardausgabe aus. Das sieht genauso aus wie oben beschrieben: Aus "Can you hear me now?" wird "KAEN YUW /HIY5R MIY NAW4?".
• s2.exe konvertiert diese Lautschrift von der Standardeingabe in eine Liste von Phonemen, die in 16-Bit-Quantitäten ähnlich UTF-16 auf die Standardausgabe geschrieben wird. Das ist binär und nicht menschenlesbar, aber schön kurz, kaum länger als der zugrunde liegende englische Satz, und kann mehr oder weniger direkt in Waveform umgerechnet werden. Anhand der Debugausgabe kann man den künftigen Sound der Phoneme erahnen.
  s2.exe sollte nicht ohne Ausgabeumlenkung benutzt werden!
  Kann man diesen zu Text wandeln (etwa mit hexdump), macht dieses Filter aus "KAEN YUW /HIY5R MIY NAW4?" den String L"\x0648\x0149\x044A\x0B08\x071C\x041A\x0935\x0814\x6224\x5B05\x0A12\x071B\x0805\x581C\x4F33\x4D14\x0202". Die Bedeutung der 16-Bit-Werte ist in phonem_t deklariert. Der Index (Lo-Byte) ist dabei relativ willkürlich gewissen Phonemen zugeordnet. Es gibt in s2 und s3 genau 80 Phoneme mit den Indizes 1..80. Die Null dient programmintern zum Abschluss der Zeichenkette. Das High-Byte enthält Länge und Betonung, nicht als Lautstärke sondern als Tonhöhe. Dass der entstehende Zeichenstrom Steuerzeichen enthalten kann ist, gelinde gesagt, unglücklich. Es wäre ein leichtes, den Indexbereich um 32 zu verschieben. Noch besser wäre es, wenn der Zeichenstrom mnemonisch ist, also teilweise passende ASCII-Zeichen zur Aussprache enthält.
• s3.exe liest die Phoneme von der Standardeingabe und berechnet daraus die Waveform, die wiederum auf die Standardausgabe geschrieben wird. Ohne Header, sondern fix 22 kSa/s, 8 bit, mono. Beim ATmega kommen diese Ausgangsdaten auf einen geeignet konfigurierten PWM-Generator. Die Synthese ist für eine Männerstimme compiliert. Die tiefere Stimmlage ist IMHO für schwachbrüstige Prozessoren günstiger bei den Berechnungen.
  s3.exe sollte nicht ohne Ein- und Ausgabeumlenkung benutzt werden! Dieses Programm generiert aus sehr wenig (Byte) sehr viel (Kilobyte)! Noch habe ich nicht die Stelle gefunden, wo man die Abtastrate variieren kann. Denn für einen ATmega mit 16 MHz und 8-Bit-PWM bietet sich eher 32 kSa/s an. Mit unverändertem Design würde es wohl wie eine hektische Mickymausfrauenstimme klingen.
• s4.exe nimmt schließlich einen Binärdatenstrom von der Standardeingabe und gibt diesen fix mit 22,05 kSa/s, 8 bit, mono, auf das Windows-Standardtonausgabegerät aus (meistens der Lautsprecher). Es ist als einziges der vier Programme komplett neu geschrieben — und vergleichsweise simpel.
  s4.exe gibt (derzeit) nichts auf die Standardausgabe aus. Das kann man, wer will, auch mit SoX machen, aber nur für diese Aufgabe gleich so 'nen dicken Brocken installieren … (Und ich weiß nicht wie man SoX dazu bringt genau dasselbe zu tun; gehen wird's sicherlich irgendwie!)

Nun, wozu das ganze?
Der Testfall ist echo Can you hear me now? | s1 | s2 | s3 | s4! Die Zeichenkette Can you hear me now? wird zum Eingabetext für s1.exe, dessen Ausgabe die Eingabe für s2.exe usw. bis es aus dem Lautsprecher schallt.

Um das ganze auf einen Arduino zu bringen erscheint es wenig sinnvoll, die Programme s1.exe und s2.exe zu implementieren, es sei denn, man steht auf Englisch und hat noch viel Flash-Speicher frei. Denn niemand wird sich von einem 8-Bit-Controller variablen Text vorlesen lassen. Schon gar nicht Namen aus einem Telefonbuch. Feste Texte, wie bspw. Zahlen, genügen vollauf.

Die Datei phonems.bin kann als Eingabedatei von s3.exe dienen, als eine Art Abkürzung: s3 < phonems.bin | s4 Und phonems enthält zwei menschenlesbare UTF-16-Beispiel-Phonemstrings.

Im Wettrennen: LPC

Durch den Verweis auf LPC = Linear Predictive Coding angestachelt, anscheinend eine TI-Erfindung? (Nein, allenfalls die geänderte Bitkodierung zur weiteren Speicher-Einsparung, die Grundlage ist LPC10 bzw. FIPS137), soll Sprachausgabe auch mit einem ATtiny85 möglich sein. Nein, die Unmachbarkeit von schnellen Multiplikationen ohne MUL-Befehl, daran glaube ich nicht. Wenn die Framerate für den Multiplikationsblock 8 kHz beträgt, hat man bei 16 MHz 2000 Takte Zeit. Macht bei 20 Multiplikationen 100 Takte. Das reicht geradeso.

Synchronansatz von Talkie, funktioniert mit ATmega32U4, zur Reduktion der Interruptlast und des Speicherhungers. Arduino-Bezug entfernt und die vielen #ifdefs entfernt. Aus einem faktischen Singleton ein „statisches Objekt“ gemacht. (Es ist bekanntlich relativ egal, ob man in C++ ein Objekt mit lauter statischen Memberfunktionen bastelt oder Funktionen und Variablen in einen Namespace tut. Abgesehen vom dann fehlenden Defaultkonstruktor. Aber darauf kann/sollte man bei Mikrocontrollerprojekten verzichten können. Daher ist's hier mittels Namespace gelöst.) Das Beispiel würde auf einem ATmega32U4 2,5 KB Kode und für die Zahlen und einige Worte 1,8 KB Flash-Tabellenplatz benötigen.

Die Software implementiert ein Latticefilter mit unendlicher Impulsantwort (IIR) 10. Ordnung in der folgenden Form:

      ↓Subtraktion  ┌Spannung u[8]
    ╔═══╗    ╔═══╗  ↓   ╔═══╗      ╔═══╗      ╔═══╗      ╔═══╗      ╔═══╗      ╔═══╗      ╔═══╗      ╔═══╗
→u10╢ - ╟→u9─╢ - ╟─→u8─┬╢ - ╟─→u7─┬╢ - ╟─→u6─┬╢ - ╟─→u5─┬╢ - ╟─→u4─┬╢ - ╟─→u3─┬╢ - ╟─→u2─┬╢ - ╟─→u1─┬╢ - ╟─→u0─┬───┬→
    ╚═╤═╝    ╚═╤═╝┌×K8←┘╚═╤═╝┌×K7←┘╚═╤═╝┌×K6←┘╚═╤═╝┌×K5←┘╚═╤═╝┌×K4←┘╚═╤═╝┌×K3←┘╚═╤═╝┌×K2←┘╚═╤═╝┌×K1←┘╚═╤═╝┌×K0←┘   │
      └×K9←┐   └←─┼×K8┐   └←─┼×K7┐   └←─┼×K6┐   └←─┼×K5┐   └←─┼×K4┐   └←─┼×K3┐   └←─┼×K2┐   └←─┼×K1┐   └←─┼×K0┐    │
        ↑  │╔══╗╔═╧═╗ │╔══╗╔═╧═╗ │╔══╗╔═╧═╗ │╔══╗╔═╧═╗ │╔══╗╔═╧═╗ │╔══╗╔═╧═╗ │╔══╗╔═╧═╗ │╔══╗╔═╧═╗ │╔══╗╔═╧═╗ │╔══╗│
        │  └╢x9╟╢ + ╟─┴╢x8╟╢ + ╟─┴╢x7╟╢ + ╟─┴╢x6╟╢ + ╟─┴╢x5╟╢ + ╟─┴╢x4╟╢ + ╟─┴╢x3╟╢ + ╟─┴╢x2╟╢ + ╟─┴╢x1╟╢ + ╟─┴╢x0╟┘
        │   ╚══╝╚═══╝  ╚══╝╚═══╝  ╚══╝╚═══╝  ╚══╝╚═══╝  ╚══╝╚═══╝  ╚══╝╚═══╝  ╚══╝╚═══╝  ╚══╝╚═══╝  ╚══╝╚═══╝  ╚══╝
        └Multiplikation            ↑Speicherstelle=Verzögerung           ↑Addition

Das AVR-Programm als JavaScript: Sprich!

Es fiel (im Debugger) auf, dass die Amplitude der originalen Talkie-Firmware viel zu gering ist, Spitzenwerte liegen bei 25 %. Das ist beim Arduino verschenkte Ausgangsleistung. Die ursprünglichen Daten führen zur Instabilität im Filter bei der Ziffer Acht, ich habe die Daten leicht frisiert: Den Faktor K0 reduziert. Die Ausgangsspannung tendiert zu stark zu positiven Werten.

Nunmehr wurde das Kettenfilter auf 8 Bit reduziert und jede Additionsstufe mit Sättigung ausgestattet (das kostet dem AVR nicht so viel). Damit konnte die Ausgabelautstärke ohne hörbare Übersteuerungseffekte auf das Vierfache(!) gesteigert werden. Mit der Bitbreitenreduktion geht eine Verdopplung der Multiplikationsgeschwindigkeit einher, sodass sich dieses Kettenfilter auch auf einem ATtiny (der bekanntlich keinen MUL-Befehl hat) mit 16 oder gar 8 MHz Taktfrequenz betreiben lässt. Was zu beweisen wäre. Diese Javascript-Ausgabe simuliert genau ein derart konstruiertes Latticefilter.

Viel schwieriger als die Dekompression ist die Kompression. Die von mir gefundene Implementierung von 2011 Peter Knight in freemat habe ich auf Javascript umgestellt. Damit kann jedermann gesprochene Texte im Browser komprimieren. Zum Talkie-Kompressor