Entwicklung einer Automatenbedienung mit einer leistungsfähigen ...

Entwicklung einer Automatenbedienung mit
einer leistungsfähigen Spracherkennung und
einer graphischen Benutzerschnittstelle
unter C++
Masterarbeit
zur Erlangung des Grades "Master of Engineering"
vorgelegt dem Fachbereich 03 Elektrotechnik und Informatik der
Hochschule Niederrhein von
Zitzer, Juri
Bahnhofstr. 41
41747 Viersen
Matrikelnummer 605125
abgegeben am: 20.07.2011
Erstgutachter: Prof. Dr.-Ing. Hans-Günter Hirsch
Zweitgutachter:
Prof. Dr.-Ing. Roland Hoffmann

Vorwort
An erster Stelle möchte ich mich ganz herzlich bei Herrn Prof. Dr.-Ing Hans-Günter
Hirsch bedanken, der mich während meiner Masterarbeit wissenschaftlich betreut und
bei der Suche nach Lösungswegen unterstützt hat. Einen weiteren Dank möchte ich
Herrn Prof. Dr.-Ing. Roland Hoffmann für die Übernahme des Zweitgutachtens
aussprechen. Außerdem möchte ich mich bei Herrn Dipl.-Ing. Andreas Kitzig, M. Eng.
dafür bedanken, dass er mir bei der Durchführung meiner Masterarbeit mit seinen
Ratschlägen und informativen Beiträgen zur Seite stand.
Der praktische Teil dieser Masterarbeit wurde parallel zur Entwicklung vom „asrLib“-
Projekt für die Erstellung von Dialogsystemen durchgeführt. Die dabei erzeugten
Quelltexte wurden in das Projekt integriert und erweitern dieses. Diese Arbeit
beschäftigt sich mehr mit der Weiterentwicklung des „asrLib“- Projektes, als mit der
Entwicklung im Bereich Spracherkennung.
Die vorliegende Masterarbeit wurde sorgfältig mit den Gedanken erstellt, dass ein
Benutzer der „asrLib“- Bibliotheken ein Dialogsystem anhand dieser erstellen und
betreiben kann. Deshalb kann man einen großen Teil dieser Arbeit als eine so einer Art
Bedienungsanleitung ansehen. Dabei wurde diese so strukturiert, dass man selbständig
ein neues Spracherkennungssystem oder eine neue graphische Oberfläche aufbauen
kann oder schon vorhandene Elemente an entsprechenden Stellen ändern kann, um
diesen neue Eigenschaften hinzuzufügen. Die Darstellung des Quelltextes, die
(vielleicht auf den ersten Blick überflüssige) Beschreibung von vorhandenen
Bibliotheken und eingesetzten Tools und eine lange Auflistung von benutzten
Funktionen sollen dabei hilfreich sein.
Falls der Leser nicht die ganze Masterarbeit lesen möchte oder kann und nur den
Kapitel ansieht, dem er die gewünschte Information entnehmen möchte, kann es dazu
kommen, dass ihm unbekannte Begriffe auftauchen oder der Zusammenhang einiger
Stellen im Text unklar wird. Deshalb wurden die vielzähligen Verweise auf andere
Stellen, wo es erklärt wird, worum es geht, in der gesamten Arbeit eingesetzt.

Ich versichere an Eides Statt durch meine Unterschrift, dass ich die vorstehende Arbeit
selbständig und ohne fremde Hilfe angefertigt und alle Stellen, die ich wörtlich oder
annähernd wörtlich aus Veröffentlichungen entnommen habe, als solche kenntlich
gemacht habe, mich auch keiner anderen als der angegebenen Literatur oder sonstiger
Hilfsmittel bedient habe. Die Arbeit hat in dieser oder ähnlicher Form noch keiner
anderen Prüfungsbehörde vorgelegen.
Krefeld, den 20.07.2011 ________________

Inhaltsverzeichnis
1. Aufgabenstellung...........................................................................................................1
2. Einleitung.......................................................................................................................2
3. Grundlagen....................................................................................................................3
3.1. Dialogsystem..........................................................................................................3
3.1.1. Graphisch.......................................................................................................3
3.1.2. Sprachbasiert..................................................................................................4
3.1.3. Multimodal.....................................................................................................5
3.2. Spracherkennung....................................................................................................6
3.2.1. Spracherkennungssystem...............................................................................7
3.2.2. Analyse...........................................................................................................8
3.2.3. Erkennung......................................................................................................9
4. Betriebsmittel, Software..............................................................................................10
4.1. FLTK 2.0..............................................................................................................10
4.2. POCO...................................................................................................................14
4.3. Hilfsmittel............................................................................................................16
5. asrLib...........................................................................................................................17
5.1. asrLib und CMake................................................................................................18
5.2. asrLib und Code::Blocks......................................................................................19
5.3. Bibliotheken.........................................................................................................21
5.4. Plugins..................................................................................................................25
5.5. Wichtiges.............................................................................................................27
6. Parallele Erkennung.....................................................................................................30
7. GUI..............................................................................................................................51
Tabellenverzeichnis
Vorhandene Actionen eines Zustandsautomaten aus dem Plugin „Actions.so“.............28
Mögliche Zustände einer Sprachdetektion mit HirschLib- Funktionen..........................41

Abbildungsverzeichnis
Abbildung 1: Spracherkennungssystem............................................................................7
Abbildung 2: Aufteilung des Audiosignals ......................................................................8
Abbildung 3: Merkmalsextraktion ....................................................................................8
Abbildung 4: FLUID Hauptfenster 1...............................................................................11
Abbildung 5: FLUID Hauptfenster 2...............................................................................11
Abbildung 6: FLUID „Widget Bin“................................................................................11
Abbildung 7: "Hello, World!" mit FLTK........................................................................12
Abbildung 8: Schriftart mit FLUID ...............................................................................13
Abbildung 9: Callback mit FLUID .................................................................................13
Abbildung 10: "Hello, World!" Projekt unter FLUID.....................................................13
Abbildung 11: POCO- Übersicht....................................................................................14
Abbildung 12: CMake GUI.............................................................................................18
Abbildung 13: Code::Blocks Übersicht...........................................................................20
Abbildung 14: Code::Blocks Einstellungen....................................................................20
Abbildung 15: Beispiel Zustandsautomat........................................................................23
Abbildung 16: Ablaufplan einer Spracherkennung.........................................................36
Abbildung 17: Sequenzdiagramm Spracherkennungssystem..........................................40
Abbildung 18: Möglicher Verlauf einer parallelen Spracherkennung............................46
Abbildung 19: Fahrkartenautomat...................................................................................52
Abbildung 20: GUI-Kalender..........................................................................................54
Abbildung 21: Kommunikation zwischen GUI und StateMachine.................................56
Quellenverzeichnis
http://www.nuance.de/spracherkennung/speechtechnology.asp.......................................4
http://de.opensuse.org/.....................................................................................................10
http://www.fltk.org/.........................................................................................................10
http://pocoproject.org/.....................................................................................................14
http://www.cmake.org/....................................................................................................16
http://www.codeblocks.org/.............................................................................................16

1. Aufgabenstellung
Wie man dem Titel der vorliegenden Masterarbeit entnehmen kann, beschäftigt sich
diese mit der Spracherkennung. Das Ziel dieser Arbeit ist, nicht ein neues Verfahren der
Erkennung der gesprochenen Sprache zu entwerfen oder die aufwendige Algorithmen
zur Berechnung der nützlichen Daten aus einem Audiosignal zu erstellen, sondern eine
Möglichkeit zur Verfügung zu stellen, die Spracherkennung universeller einsetzen zu
können. Dabei sollen die schon fertige Funktionen zur Analyse von Signalen und
Erkennung der Sprache verwendet werden. Diese Funktionen wurden mit der
Programmiersprache C erstellt und zu „HirschLib“- Bibliotheken zusammengefügt. Der
Quellcode, der im Rahmen dieser Masterarbeit erstellt werden soll, wird in der
erweiterten Programmiersprache C++ geschrieben, dabei sollen die Strukturen in
„HirschLib“- Bibliotheken entsprechend angepasst werden.
Die Aufgabe dieser Masterarbeit setzt sich aus zwei Teilen zusammen:
Als Erstes, soll eine Methode entwickelt werden, mit der man eine schnellere und
bessere Erkennung der Sprache realisieren kann. Diese wird dann bei der Bedienung
von verschiedenen Automaten durch Sprache eingesetzt, z.B. bei einem automatisierten
Auskunftssystem über Telefonleitung. Bei dieser Methode sollen mehrere Prozesse, die
diese Erkennung durchführen, mit unterschiedlichen Konfigurationen gleichzeitig
ausgeführt werden. Dabei erhöht sich die Erwartung, dass die gewünschten Ergebnisse,
zumindest von einem dieser Prozessen, geliefert werden.
Als Weiteres, soll eine graphische Oberfläche zur Steuerung von Automaten erstellt
werden, die parallel zur Sprachbedienung eingesetzt werden kann, z.B. bei einem
Fahrkartenautomat.
Seite 1

2. Einleitung
Diese Einleitung zur vorliegenden Masterarbeit soll als ihre kurze Übersicht dienen.
Hier werden alle ihre Kapitel vorgestellt und deren Inhalte zusammengefasst.
Im Kapitel „Grundlagen“ wird erklärt, was man unter einem Dialogsystem verstehen
soll, welche Arten es davon gibt und welche bei dieser Masterarbeit verwendet wird.
Dann wird ein Spracherkennungssystem mit allen seinen Komponenten kurz dargestellt
und die meist eingesetzten Verfahren der Spracherkennung erwähnt.
Das Kapitel „Betriebsmittel, Software“ sollte nicht außer Acht gelassen werden, da die
externen Bibliotheken und Tools, die bei dieser Arbeit eingesetzt wurden und deshalb
auch wichtig sind, werden in diesem Kapitel beschrieben. In weiteren Kapiteln wird es
immer wieder auf diese Beschreibung zurückgegriffen.
Wie der Name des Kapitels „asrLib“ schon sagt, wird hier „asrLib“- Projekt dargestellt,
in dem (und parallel zu dem) die im Rahmen dieser Masterarbeit erstellten
Applikationen entwickelt wurden. In diesem Kapitel werden die wichtigsten Funktionen
und die Grundlagen beschrieben, die für die beiden weiteren Kapitel entscheidend sind.
Im Kapitel „Parallele Erkennung“ wird, als Erstes, gezeigt, wie eine Spracherkennung
mit dem „asrLib“- Projekt überhaupt funktioniert. Dann wird beschrieben, wie eine
Möglichkeit der parallelen Erkennung im Rahmen dieser Masterarbeit geschaffen wurde
und wird erläutert, was man für einen parallelen Einsatz von mehreren
Spracherkennungssystemen braucht und was man dabei beachten soll.
Am Anfang des praktischen Teils dieser Masterarbeit wurde die Beschreibung von zu
erstellenden graphischen Oberflächen im XML- Format erstellt. Mit dem von POCO *
zur Verfügung gestellten Parser wurde diese Beschreibung in das FLTK * - Format
während der Ausführungsphase der Applikation übersetzt. Dieses Verfahren hat sich
nicht bewehrt und es wurde entschieden, auf das FLTK- eigenes Tool FLUID * zur
Erstellung von graphischen Oberflächen umzusteigen. Im Rahmen dieser Arbeit wurden
zwei graphische Oberflächen erstellt. Damit der Benutzer von „asrLib“- Bibliotheken
nicht auf diese zwei Oberflächen angewiesen ist und selbst solche schnell erstellen
kann, wurden diese Bibliotheken entsprechend erweitert. Dazu im Kapitel „GUI“.
* wird im Kapitel 4 beschrieben
Seite 2

3. Grundlagen
In diesem Kapitel wird es kurz erläutert, was ein Dialogsystem ist, welche Arten von
Dialogsystemen es gibt und wie eine automatische Spracherkennung realisiert wird.
3.1. Dialogsystem
Als Dialog bezeichnet man eine schriftliche, mündliche oder visuelle Kommunikation
zwischen mindestens zwei Personen. Wenn man eine natürliche Person mit einem
Computer ersetzt, wird Dialog mit Hilfe von einem Dialogsystem geführt.
Dialogsysteme werden immer dort eingesetzt, wo die teure menschliche Arbeitskraft
nicht unbedingt notwendig ist. Solche Dialogsysteme werden immer beliebter und
begegnen uns überall, meistens ohne dass wir es wahrnehmen. Dabei können Dialoge
mittels Sprache, mit Hilfe der graphischen Oberfläche oder sogar anhand von
Gestenerkennung geführt werden.
3.1.1. Graphisch
Die graphischen Dialogsystemen sind die ältesten, beliebtesten und am meisten
verbreitetsten Dialogsystemen. Die bekannteste Dialogführung ist die Kommunikation
zwischen Mensch und Personal Computer. Dabei werden unbedingt ein Monitor oder
ein Projektor für die Ausgabe von Information verwendet und eine Tastatur oder eine
Computermaus oder am liebsten beides für die Informationseingabe benutzt. Die
berührungsempfindliche Monitore können nicht nur die Daten ausgeben, sondern
erlauben auch die Eingabe von Daten und Befehlen per Fingerdruck, was die
herkömmliche Eingabegeräte ersetzt. Solche Monitore werden z.B. bei Dialogsystemen
für die Fahrplanauskunft und Fahrkartenkauf auf vielen Bahnhöfen in Deutschland
angewendet. Man liest eine Frage auf dem Bildschirm und gibt die Antwort mittels
Tastatur ein. Oder man tippt direkt die Felder an, die zur Auswahl auf dem
Berührungsbildschirm angezeigt werden und wie Tasten funktionieren. Diese
Dialogsysteme bieten rein graphische Dialogführung an. Die Eingaben des Benutzers
werden fast immer zu 100 % richtig erkannt. Für sehbehinderte Menschen sind diese
aber nutzlos, hier kann man nicht ohne sprachbasierte Dialogsysteme auskommen.
Seite 3

3.1.2. Sprachbasiert
Nach den graphischen kommen die sprachbasierten Dialogsysteme zum Einsatz, für
deren Benutzung man nur die Lautsprecher und einen Mikrofon benötigt. Die Sprache
ist die natürliche Art der Kommunikation für Menschen, deshalb werden diese
Dialogsysteme immer beliebter. Die Bekanntesten sind die Anrufbeantworter der
telefonischen Auskunfts- und Beratungs- Diensten. Der Anrufer wird in einem
interaktiven Dialog aufgefordert, eine Menüauswahl per Sprache zu treffen. In
Abhängigkeit davon, welche Auswahl getroffen wurde, wird der Anrufer mit einem
entsprechenden Call-Center-Mitarbeiter verbunden oder der Dialog wird weiter geführt.
Solche Dialogsysteme sind meistens auf die Ziffern-Erkennung und auf die Erkennung
von bestimmten Sprachbefehlen begrenzt. Obwohl der Wortbestand klein ist, können
die ausgesprochene Wörter oft falsch erkannt werden, weil der Anrufer z.B. einen
Akzent oder Störgeräusche im Hintergrund hat. Es wird immer wieder versucht, die
Dialogsysteme auf diese Abweichungen und Störungen anzupassen und die
Erkennungsrate zu erhöhen.
Ein anderes Beispiel für sprachbasierte Dialogsysteme ist die Sprachsteuerung eines
personalen Computers, was z.B. bei Microsoft Windows Vista schon in Betriebssystem
integriert ist. Die weltweit meistverkaufte Spracherkennungssoftware Dragon
NaturallySpeaking von Nuance Communications erlaubt es, dem Anwender mit nur
wenigen, einfachen Worten E-Mails zu versenden, Termine festzulegen, im Internet
nach Informationen zu suchen oder Anwendungen des PC's zu starten, zu bedienen und
zu beenden. Die Sprache kann mit einer Geschwindigkeit von bis zu 160 Wörtern pro
Minute und Genauigkeitsraten von bis zu 99% ohne vorherigen Sprachtraining
bearbeitet werden [http://www.nuance.de/spracherkennung/speechtechnology.asp].
Die Sprachsteuerung kann sehr nützlich sein, wenn man sich dabei frei bewegen möchte
oder wenn die Hände und Augen des Benutzers schon woanders beschäftigt sind, wie es
beim Steuern des Autos der Fall ist.
Seite 4

3.1.3. Multimodal
Ein multimodales Dialogsystem ist eine Kombination aus beiden oben beschriebenen
Dialogsystemen, dabei können auch die Gesten- und Mimik- Erkennung hinzukommen.
Multimodal bedeutet, dass für die Kommunikation mehr als eine Modalität (Sehen,
Hören, Fühlen) eingesetzt werden kann oder muss. Man unterscheidet zwischen den
komplementären (ergänzenden) und den redundanten (alternativen) multimodalen
Dialogsystemen.
Bei komplementären Dialogsystemen kriegen oder liefern alle verwendeten Modalitäten
ihre eigene Information und ergänzen einander, die können nicht einzeln sinnvoll
eingesetzt werden. Man könnte zum Beispiel in einer Zeichnungssoftware den Befehl
„Zeichne einen Kreis hier“ in den Mikrofon diktieren, den Mauszeiger auf die
gewünschte Stelle ziehen und Maustaste betätigen. Dabei braucht man keine genauere
Position zu nennen. Die Software bekommt die Aufgabe über zwei verschiedene
Informationsquellen (Mikrofon und Maus), die jeweils nur einen Teil dieser Aufgabe
liefern.
Bei redundanten multimodalen Dialogsystemen haben alle Informationsquellen
denselben Informationsgehalt. Das kann man am Beispiel von einem Fahrkartenautomat
deutlich sehen. Die Frage „Wann möchten Sie fahren?“ wird auf dem Bildschirm
angezeigt und gleichzeitig über die Lautsprecher ausgegeben. Der Benutzer hat
seinerseits freie Wahl, die Frage per Sprache zu beantworten oder die Schaltfläche mit
dem gewünschten Datum auf dem Bildschirm mit der Maus zu wählen. Die
Informationen in beiden Fällen sind vollständig und unabhängig voneinander und
dienen demselben Zweck. Eine weitere Anwendungsmöglichkeit von redundanten
multimodalen Dialogsystemen ist bei im vorherigen Kapitel erwähnten Telefondiensten
sehr beliebt. Dem Anrufer wird es angeboten, die gewünschten Menüpunkte per
Sprache auszuwählen oder alternativ die Eingabe über die Telefontastatur per Tonwahl
zu machen. Allerdings wird die zweite Möglichkeit nur dann funktionieren, wenn das
Telefongerät die Tastenwahlfunktion unterstützt.
Im Rahmen dieser Arbeit sollte ein redundantes multimodales Dialogsystem entwickelt
werden, das neben der Spracherkennung eine graphische Oberfläche mit der Maus- und
Tastatur- Steuerung zur Bedienung von Automaten anbieten soll.
Seite 5

3.2. Spracherkennung
Die Spracherkennung ist heutzutage sehr beliebt und wird in vielen Bereichen mit
Erfolg eingesetzt. Die häufigste Anwendung findet in Programmen für die Sprache-
Text-Umwandlung (text-to-speech) und im Kapitel 3.1.2 beschriebenen sprachbasierten
Dialogsystemen statt. Es gibt zwei Arten der Spracherkennung: sprecherabhängige und
sprecherunabhängige. Mit der Ersten muss die Anwendung zuerst an den jeweiligen
Benutzer angepasst werden, dabei sollen einige Sprachaufnahmen erfolgen. Der
Wortbestand bei dieser Art der Spracherkennung kann sehr groß sein. Deshalb wird die
sprecherabhängige Erkennung meistens für die Sprache-Text-Umwandlung eingesetzt.
Bei der sprecherunabhängigen Spracherkennung kann die Erkennung vom beliebigen
Benutzer sofort und ohne vorheriges Trainieren gestartet werden, vorausgesetzt, der
Benutzer spricht dabei auf der für die Erkennung vorgesehenen Sprache. Bei für
mehrere Anwender gedachten, sprachbasierten Dialogsystemen wird ausschließlich
diese Art der Spracherkennung mit einem festgesetztem Wortschatz verwendet. Deshalb
kommt nur die sprecherunabhängige Spracherkennung bei dieser Arbeit in Betracht.
Man muss zwischen Spracherkennung (was gesprochen wird) und Sprechererkennung
(wer spricht) sowie Stimmerkennung (wie gesprochen wird) unterscheiden. Die
Aufgaben und Ziele von diesen drei Teilgebieten der Sprachverarbeitung sind
unterschiedlich, obwohl die Verfahren zu deren Realisierung sehr ähnlich sind. Man
analysiert empfangene Signale und vergleicht ermittelte Werte mit den vorhandenen,
vorher erstellten Mustern. Welche Daten dabei relevant sind und wie diese verglichen
werden sollen, hängt vom jeweiligen Verfahren ab. Die Erstellung von Mustern ist mit
einem sehr großen Aufwand verbunden. Als Erstes müssen mehrere Sprachäußerungen
von möglichst vielen männlichen und weiblichen Personen mit verschiedenen Akzenten
aufgenommen werden, um die universellere Muster zu erhalten, die zu einem breiten
Spektrum von Anwender passen werden. Die aufgenommene Äußerungen müssen
analysiert werden. Die durch Analyse gewonnene Daten werden dann zu Mustern
trainiert und im gewünschten Format abgespeichert. Die Art der Analyse bei dem
Training und diese bei der Erkennung müssen natürlich gleich sein.
Die ganze Applikation, bei der die Spracherkennung stattfindet, wird sehr oft als
Spracherkenner bezeichnet. Bei der Echtzeit-Erkennung, d.h. während der
Spracheingabe durch Benutzer, wird Analyse vor der Erkennung durchgeführt. Deshalb
wird diese Applikation bei der vorliegenden Arbeit Spracherkennungssystem genannt.
Seite 6

3.2.1. Spracherkennungssystem
Ein Spracherkennungssystem besteht hauptsächlich aus zwei Komponenten, die bei
dieser Arbeit als Analyzer und Erkenner bezeichnet werden. In Einem wird die
Merkmalsextraktion (oder Analyse) durchgeführt und in Anderem findet die
Mustererkennung statt. Es können noch zusätzliche Komponente dem System
hinzugefügt werden, um bessere Ergebnisse der Erkennung zu erzielen. So können die
Modelle, oder Muster, die für die Erkennung gebraucht werden, mit der Adaption an die
Störgeräusche der Umgebung angepasst werden. Die Erkennung selbst ist ein zeit- und
leistungs- aufwändiger Prozess. Um das System etwas zu entlasten, kann ein
Sprachdetektor eingesetzt werden. Die Sprachdetektion sorgt dafür, dass Erkenner erst
dann startet, wenn wirklich die Sprache kommt, oder, um genauer zu sein, wenn in den
analysierten Daten Anfang der Sprache vom Sprachdetektor erkannt wird. Die
optionalen Komponente sind in der Abbildung 1 punktiert dargestellt.
Abbildung 1: Spracherkennungssystem
Bei der Aufnahme von Audiosignalen kann es dazu kommen, dass die Grundspannung
zum Audiosignal addiert wird. Um diesen kleinen aber unangenehmen Nebeneffekt, das
DC-Offset genannt wird, zu beseitigen, kann DC-Filter verwendet werden. Manchmal
ist dieses Filter ein Bestandteil der Analyse. Sehr oft wird es aber komplett ausgelassen.
Deshalb ist DC-Filter als eine optionale Komponente des Spracherkennungssystems in
der Abbildung 1 dargestellt.
Seite 7

3.2.2. Analyse
Die Analyse (oder Kurzzeitanalyse, oder Merkmalsextraktion) wird, ausgenommen die
Energieberechnung, im spektralen Bereich durchgeführt. Dazu soll das Sprachsignal
in kleine, sich überlappende Abschnitte geteilt und mit Hamming-Fenster gewichtet
werden. Die Länge von 25 ms für diese Abschnitte und 15 ms für die Überlappung oder
entsprechend 10 ms für die Verschiebung hat sich in der Praxis durchgesetzt.
25 ms
Abbildung 2:
Aufteilung des
Audiosignals
10 ms
Mit der Fast Fourier Transformation (FFT) wird jeder Abschnitt in den
Frequenzbereich überführt. Die dabei entstandene Fouriertransformierte wird mit der
aus 24 bis 26 sich zur Hälfte überlappenden Dreiecksfiltern bestehende Mel-Filterbank
multipliziert, um das Mel-Spektrum zu berechnen. Aus Diesem kann nun das Mel-
Cepstrum ermittelt werden. Dazu wird das Mel-Spektrum zuerst logarithmiert und
anschließend mit der Kosinus-Funktion multipliziert. Die dabei gewonnene
Merkmalsvektoren bilden die sogenannte Merkmalssequenz, oder MFCC (Mel
Frequency Cepstral Coefficients), die zusammen mit der Energie die gewünschten
Ergebnisse der Kurzzeitanalyse repräsentiert.
Eine graphische Darstellung von diesem ganz grob beschriebenen Verfahren der
Merkmalsextraktion ist in der Abbildung 3 zu sehen. Eine nähere Betrachtung von
einzelnen Schritten wird hier nicht erfolgen, da es nicht die Aufgabe dieser Arbeit ist,
eine Analyse durchzuführen.
0. Sprachsignal 1. Aufteilung
3. Hamming 4. FFT
2. Energie
5. Mel-Filterbank
8. MFCC
7. Kosinus
6. LOG
Abbildung 3: Merkmalsextraktion
Seite 8

3.2.3. Erkennung
Während der Erkennungsphase werden die durch Analyse gewonnene Merkmale des
Eingangssignals mit den vorhandenen Mustern verglichen, um das Muster zu ermitteln,
das diesem Sprachsignal am ähnlichsten ist. Es gibt verschiedene Verfahren, um diesen
rechenintensiven Vergleich durchzuführen. Die drei Bekanntesten sind Dynamische
Programmierung (Dynamic Time Warping, DTM), Künstliche Neuronale Netze (KNN
oder Artificial Neural Network, ANN) und die Darstellung des Musters als Hidden-
Markov-Modell (HMM).
Bei Dynamischer Programmierung werden die analysierten Daten der zu erkennenden
Äußerung an jedes vorhandene Muster zeitlich angepasst, um einen korrekten Vergleich
zu ermöglichen. So können zwei unterschiedlich lange Äußerungen desselben Wortes
richtig miteinander verglichen werden. Dabei werden die Abstände zwischen den
einzelnen Werten der beiden Merkmalsfolgen berechnet. Das Muster mit dem kleinsten
Abstand zur vorliegenden Äußerung wird ausgewählt. Die Zeitanpassung wird für jeden
Wert der Merkmalsvektoren dynamisch durchgeführt.
Neuronale Netze, oder anders genannt Künstliche Intelligenz, bestehen aus mehreren
Schichten. An die Eingangsschicht werden die Merkmale des zu erkennenden Wortes
gelegt, an die Ausgangsschicht die der vorhandenen Muster. In den Zwischenschichten
werden die ersten Merkmale so lange verarbeitet, bis die den Merkmalen eines dieser
Muster ähnlich sind. Das betroffene Muster wird als Ergebnis anerkannt. Sehr oft
werden die Hidden-Markov-Modelle als Muster bei dieser Art der Mustererkennung
eingesetzt, dabei entsteht eine neue, gemischte Technik.
Bei dem dritten und wahrscheinlich am häufigsten benutzten Verfahren mit Hidden-
Markov-Modellen werden die Übergangswahrscheinlichkeiten zwischen den Zuständen
berechnet, aus denen diese HMM's bestehen. Man kann ein HMM als Zustandsautomat
darstellen, dabei können die analysierten Daten von einem Wort oder sogar von einem
Phonem in mehrere Zustände zerlegt werden. Die Verteilung von Merkmalsvektoren
auf die Zustände wird mit Hilfe von Viterbi- Algorithmus realisiert. Nachdem alle diese
Merkmale optimal verteilt wurden oder nachdem der beste Pfad durch den
Zustandsautomat gefunden wurde, werden die Wahrscheinlichkeiten berechnet. Das
Muster mit der höchsten Wahrscheinlichkeit wird der zu erkennenden Sprachäußerung
zugewiesen. Im Labor für Digitale Nachrichtentechnik an der Hochschule Niederrhein
wird sehr viel Wert auf dieses Verfahren gelegt.
Seite 9

4. Betriebsmittel, Software
openSUSE wird auf nahezu allen Rechnern im DNT-Labor als
Betriebssystem eingesetzt. Diese freie Distribution ist in
Deutschland sehr verbreitet und beliebt. Obwohl openSUSE
kostenlos ist, kann man eine kommerzielle Version mit dem
vollständigen Handbuch und mit einer 90-Tägigen telefonischen Installations-
Unterstützung erwerben. Um das Betriebssystem unbeschränkt nutzen zu können, muss
man auf die Produktlebenszeit achten. 18 Monate lang ab Erscheinungsdatum von
jeweiliger Version stehen die Aktualisierungen und zugehörige Repositories zur
Verfügung. Man soll also rechtzeitig auf die neue Version umsteigen. Die
Softwareentwicklung bei dieser Masterarbeit wurde ausschließlich unter openSUSE
durchgeführt. [http://de.opensuse.org/] Die verwendeten Entwicklungswerkzeuge und
Bibliotheken sind sowohl unter Linux als auch unter Microsoft Windows und Mac OS
einsetzbar, wie z.B. das Toolkit FLTK für die GUI-Entwicklung.
4.1. FLTK 2.0
Es gibt viele kostenfreie GUI-Frameworks, die
einen breiten Funktionsumfang zur Verfügung
stellen. Bei dieser Arbeit ist die Wahl auf Fast
Light Toolkit (FLTK) Version 2.0 gefallen. FLTK ist eine plattformunabhängige C++
Bibliothek, bei der auf die Anbindungen an andere Programmiersprachen verzichtet
wurde. Aus diesem Grund und weil es nur auf die GUI konzentriert wurde und alle
anderen extra Klassen ausgelassen wurden, ist FLTK, wie auch der Name schon sagt,
sehr schnell und leicht im Vergleich mit anderen Toolkits. Außerdem wird 3D-Grafik
mit OpenGL-Anbindung bei FLTK unterstützt. [http://www.fltk.org/]
Zusammen mit FLTK wird ein FLTK eigener graphischer Editor „Fast Light User-
Interface Designer“ (FLUID) installiert, mit dem man nicht nur eine graphische
Oberfläche sondern große Projekte mit Klassen und Namensräumen ganz leicht
erstellen kann. FLUID verwaltet seine Projekte als Textdateien mit eigenem Dateisuffix
'.fl', die man bei Bedarf mit beliebigem Texteditor editieren kann. Mit FLUID kann man
die neu erstellte oder aus der '.fl'-Datei geladene Projekte in C++ Code konvertieren,
Seite 10

(„Write code“ in der Abbildung 4) dabei werden jeweils eine '.cxx' und eine '.h' Datei
erstellt, die den gesamten Quellcode enthalten, der nur noch kompiliert werden soll.
Nach dem Start von FLUID öffnen sich zwei Fenster. In dem Hauptfenster, das auf den
Abbildungen 4 und 5 zu sehen ist, kann man alle Konfigurationen vornehmen, den
Quellcode erstellen und graphische Elemente hinzufügen.
Abbildung 4: FLUID Hauptfenster 1 Abbildung 5: FLUID Hauptfenster 2
Das zweite Fenster ermöglicht einen schnellen Zugriff auf alle vorhandene Elemente:
Abbildung 6: FLUID „Widget Bin“
Wenn man ein graphisches Objekt erstellt, öffnet sich ein drittes Fenster, das dieses
Objekt darstellt. So ist ein Fenster von der Applikation „Hello World!“ in der
Abbildung 7 auf der nächsten Seite als ein FLUID-Objekt dargestellt. Mann kann die
einzelne Elemente direkt im Fenster verschieben und deren Größe mit dem Mauszeiger
ändern. Das Fenster wird nach der Kompilierung des Quellcodes genau so aussehen,
wenn man die Applikation startet. So schnell und übersichtlich kann man beliebig
komplizierte graphische Oberflächen mit FLUID erstellen.
Seite 11

Abbildung 7:
"Hello, World!"
mit FLTK
Um die Vorteile von FLUID besser zu erkennen, soll man den von Hand erstellten
Quellcode für die Applikation „Hello, World!“ ohne Headerfile mit den Abbildungen 8
bis 10 auf der Seite 13 vergleichen:
#include
#include
#include
#include
#include
using namespace fltk;
// für exit()
void my_callback(fltk::Button*, void*) // Abbildung 10
{
exit(0);
}
int main(int argc, char **argv)
{
Window *window = new Window(300, 200, "hello");
window->begin();
}
Widget *box = new Widget(20, 20, 260, 80, "Hello, World!");
box->box(UP_BOX);
// Schriftart
box->labelfont(HELVETICA_BOLD_ITALIC); // in
box->labelsize(36); // der
box->labeltype(SHADOW_LABEL); // Abbildung 8
Button *button = new Button(70, 120, 160, 60, "Exit");
button->labelsize(24);
button->callback((Callback*)my_callback); // Abbildung 9
window->end();
window->show(argc, argv);
return run();
Für einen Anfänger in der GUI- Programmierung mit FLTK ist es sehr aufwändig z.B.
die Schriftart für einen Text zu ändern, ohne in der Dokumentation zu suchen. Mit
FLUID muss man nur die gewünschte aus allen vorhandenen Möglichkeiten auswählen.
In der Abbildung 8 sind die geänderten Parameter rot dargestellt. Alle benötigten FLTK
eigene Headerfiles werden automatisch bei der Quellcode-Generierung eingefügt.
FLUID erstellt alle Elemente als kleinen Buchstaben „o“. Ein Abschnitt des oben
Seite 12

angegebenen Quellcodes könnte vereinfacht bei FLUID wie folgt aussehen:
Window *o = new Window(300, 200, "hello");
{
Widget *o = new Widget(20, 20, 260, 80, "Hello, World!");
}
{
Button *o = new Button(70, 120, 160, 60, "Exit");
}
Deshalb ist Button-Callback in der Abbildung 9 als „my_callback(o, 0)“ angegeben.
Der Buchstabe „o“ ist der Button selbst und die Ziffer 0 steht für „Übergabeparameter:
keine“. Das ganze Projekt unter FLUID sieht dann wie in der Abbildung 10 aus.
Abbildung 8: Schriftart mit FLUID
Abbildung 9: Callback mit FLUID
Abbildung 10:
"Hello, World!"
Projekt unter
FLUID
Seite 13

4.2. POCO
POCO ist eine Sammlung von modernen, leistungsfähigen, freien C++
Klassenbibliotheken und Frameworks für die Netzwerk- und Internetbasierten
Anwendungen, die auf Desktop-, Server- und Embedded-
Systemen ausgeführt werden. [http://pocoproject.org/]
Die POCO- Bibliotheken werden weltweit mit dem Ziel entwickelt, eine möglichst
große plattformunabhängige Sammlung von fertigen Lösungen zu verschiedensten
Aufgaben, auf die man bei der Programmierung in unterschiedlichen Bereichen stoßen
kann, zusammen zu stellen. Diese sehr empfehlenswerte Bibliotheken ermöglichen den
Entwicklern, die Zeit für die Entwicklung von schon Entwickeltem zu sparen.
Eine grobe Übersicht der POCO- Bibliotheken, die aus der kurzen Zusammenfassung
unter http://pocoproject.org/documentation/PoCoOverview.pdf kopiert wurde:
Abbildung 11: POCO- Übersicht
Die Zip- Bibliothek enthält Klassen zum Erstellen, Bearbeiten und Entpacken von Ziparchivierten
Daten.
Die Klassen aus Util- Bibliothek sind für die Verarbeitung von Konfigurationsdateien
und für die Behandlung von Kommandozeilenparameter, sowie für die Erstellung von
Seite 14

Server- Anwendungen wie Unix-Dämonen oder Windows-Diensten zuständig.
Wie der Name von XML- Bibliothek schon sagt, ist diese Bibliothek für die Erstellung
und Analyse von XML- Dokumenten verantwortlich. Dabei werden die W3C (World
Wide Web Consortium) Standards SAX2 und DOM unterstützt.
Die Net- Bibliothek bietet Implementierungen verschiedener Netzwerkprotokolle und
Server wie HTTP, FTP, SMTP und anderen. Damit kann man z.B. IP-Adressen
verwalten, e-Mails versenden oder kompletten Webserver erstellen.
Eine Erweiterung von dieser Bibliothek wird als NetSSL bezeichnet und verwendet die
SSL- (Secure Sockets Layer) und TLS- (Transport Layer Security) Verschlüsselung für
eine sichere Kommunikation. Um diese Erweiterung einsetzen oder überhaupt
installieren zu können, müssen zusätzliche externe OpenSSL- Pakete auf dem Rechner
schon vorhanden sein. Deshalb wird es empfohlen, diese Erweiterung nur dann zu
installieren, wenn sie wirklich benötigt wird. Unter Linux kann man diese Bibliothek
vor der Installation von POCO folgendermaßen auslassen:
./configure --omit=NetSSL_OpenSSL
Mit „--omit=Crypto“ kann man eine weitere Bibliothek ausschließen, die OpenSSL
benötigt - Crypto. Diese Bibliothek bietet die Ver- und Entschlüsselung von Daten an.
Die Data- Bibliothek erlaubt einen einfachen Zugriff auf verschiedene Datenbanken
über ODBC (Open Database Connectivity) und auf die Datenbankverwaltungssysteme
wie MySQL oder SQLite. Dafür müssen Microsoft ODBC für Windows oder
unixODBC / iODBC für Linux und MySQL client installiert werden.
Um alle von externen Paketen abhängige POCO- Bibliotheken bei der Installation zu
ignorieren, kann man diesen Befehl anwenden:
./configure -–omit=NetSSL_OpenSSL,Crypto,Data/ODBC,Data/MySQL
Das „Herz“ von POCO ist Foundation, eine Bibliothek mit vielen abstrakten Klassen
und fertigen Strukturen für die Arbeit mit Ausnahmen und Ereignissen, mit parallelen
Prozessen und deren Kommunikation miteinander, mit Datum und Zeit, mit Dateien und
Ordner, mit dynamischen Bibliotheken und vielem mehr.
Seite 15

4.3. Hilfsmittel
Um die Makefiles zu generieren und um alle bei dieser Arbeit
erstellten Quelltexte zu einem Projekt zusammenzufügen, wurde das
plattformunabhängige Programmierwerkzeug CMake (cross-platform
make) verwendet. [http://www.cmake.org/]
Mit CMake kann man schnell und leicht Projekte aus beliebig komplexer Ordner-
Architektur erstellen. Dazu muss eine einfache Konfigurationsdatei „CMakeLists.txt“ in
jedem Ordner mit Quellcode vorhanden sein. Auf der offiziellen Webseite von CMake
findet man sehr gute Dokumentation und viele Konfigurations- und Anwendungs-
Beispiele von diesem Toolkit. Neben der kommandozeilenorientierten Anwendung
„cmake“ gibt es einen graphischen Editor „cmake-gui“, mit dem man ganz bequem die
wichtigsten Konfigurationen vornehmen und externe Bibliotheken anbinden kann.
Mit CMake erstellte Makefiles können direkt vom „make“- Programm gelesen werden,
um den Quelltext zu kompilieren. Alternativ kann das zusammen mit Makefiles erstellte
Projekt in eine Entwicklungsumgebung für die weitere Verarbeitung geladen werden.
Für welche Entwicklungsumgebung das Projekt erstellt werden soll, muss man vorher
bestimmen.
Bei dieser Arbeit wurde eine freie, plattformunabhängige C++
Programmierumgebung mit dem Namen Code::Blocks verwendet,
bei der beliebige Compiler und Debugger eingesetzt werden können.
Code::Blocks kann mit weiteren zusätzlichen Erweiterungsmodulen
(Plugins) versehen werden. Diese Programmierumgebung hat ein deutsches Handbuch
mit ausführlicher Beschreibung. [http://www.codeblocks.org/] Code::Blocks hat viele
Einstellungsmöglichkeiten und eine übersichtliche graphische Oberfläche, die die
Arbeit mit dem Quellcode leichter und angenehmer werden lassen, besonders wenn es
um größere Projekte geht. Wenn man die erstellten Anwendungen mit Code::Blocks
testen will, kann man unter „Project → Set program's arguments” die gewünschten
Übergabeparameter angeben. Unter „Project → Properties → Build targets” kann man
den Ordner festlegen, aus dem die Anwendung starten soll (s.a. Abbildung 14 auf der
Seite 20). Das Projekt selbst kann man mit dem folgenden Aufruf von CMake erstellen:
cmake -G "CodeBlocks - Unix Makefiles"
Seite 16

5. asrLib
asrLib (Automatic Speech Recogition Library) ist ein Projekt, das im Labor für Digitale
Nachrichtentechnik an der Hochschule Niederrhein entwickelt wurde und das eine
Sammlung von Bibliotheken zur Erstellung von Applikationen für automatische
Spracherkennung zur Verfügung stellt. Mit diesen Bibliotheken kann man nicht nur
lokale sprachbasierte Dialogsysteme, d.h. mit dem Einsatz von Mikrofon und
Lautsprecher, realisieren, sondern auch solche, die eine Kommunikation mit dem
System über beliebige Telefongeräte per Telefonleitung ermöglichen. Das Projekt
asrLib wurde parallel zu dieser Masterarbeit weiter entwickelt und um die Möglichkeit,
multimodale Dialogsysteme mit der graphischen Oberfläche zu entwerfen, erweitert.
Das Projekt befindet sich im gleichnamigen Ordner und ist in mehrere Verzeichnisse
unterteilt. Die hier dargestellte (vereinfachte) Verzeichnisstruktur gibt einen kurzen
Überblick über „asrLib“, die etwas nähere Beschreibung von einzelnen Ordner findet
man in den nächsten Kapiteln.
asrLib
| --- applications // beinhaltet Ordner mit Quellcode für verschiedene Applikationen
| --- DialogHGH // Quellcode einer Applikation für sprachbasierte Dialogsysteme
| --- GuiApp // Quellcode einer Applikation für multimodale Dialogsysteme
| --- build.Codeblocks // Ordner für alle Makefiles, wird von CMake erstellt
| --- bin // Ordner für ausführbare asrLib- Binärdateien
| --- lib // Ordner für asrLib- Basis- Bibliotheken
| --- CMakeModules // Ordner mit zusätzlichen Konfigurationsdateien für CMake
| --- data // enthält alle Daten und Konfigurationsdateien für Dialogsysteme
| --- plugins // fertige Erweiterungsmodule als dynamische Bibliotheken
| --- doc // Dokumentation von asrLib-Projekt, erstellt mit Doxygen
| --- include // Ordner mit Headerfiles für Grundbibliotheken von asrLib
| --- lib // Ordner mit externen Bibliotheken, die bei asrLib eingesetzt werden
| --- CapiLib // ISDN-IO Bibliothek
| --- HirschLib // Bibliotheken für automatische Spracherkennung
| --- plugins // Ordner mit Quellcode für alle Erweiterungsmodule
| --- src // Ordner mit Quellcode für Grundbibliotheken von asrLib
Seite 17

5.1. asrLib und CMake
Um die mühsame manuelle Erstellung von Makefiles und deren Korrektur bei jeder
Änderung im Projekt zu ersparen, wurde bei dieser Arbeit CMake eingesetzt (Kapitel
4.3). Um noch einfacher und angenehmer zu arbeiten, wurde der leicht zu bedienende
graphische Editor von CMake verwendet, der nur zu empfehlen ist. Dieser Editor kann
über Kommandozeile mit „cmake-gui“ aufgerufen werden. Nach dem Start öffnet sich
ein Auswahlfenster für Makefiles- Generator *. Es wird empfohlen, „CodeBlocks -
Unix Makefiles“ als Generator auszuwählen, um das Projekt für die weitere Bearbeitung
in Programmierumgebung Code::Blocks vorzubereiten, die ebenfalls im Kapitel 4.3
kurz beschrieben wurde. Als Weiteres gibt man den vollständigen Pfad zum asrLib-
Ordner im entsprechenden Eingabefeld (1. in der Abbildung 12) für Verzeichnis mit
dem Quellcode ein. Als Ausgabeordner (2.) wird z.B. „build.Codeblocks“ ausgewählt
(s. Ordnerstruktur auf vorheriger Seite) oder ein neuer Ordner erstellt, in dem alle
Makefiles geschrieben werden sollen. Wie der Name schon sagt, wird ein Projekt für
Code::Blocks zusammen mit Makefiles in diesem Ordner angelegt.
1. →
2. →
3. →
Abbildung 12: CMake GUI
* Falls Auswahlfenster nicht automatisch geöffnet wird, kann man das erzwingen, indem man den
Menüpunkt „File → Delete Cache” wählt (oder beide Eingabefelder leer lässt, die mit Ziffern 1 und 2 in
der Abbildung 12 gekennzeichnet sind) und den Button „Configure“ (3.) betätigt.
Seite 18

Mit der Schaltfläche „Configure“ (3.) wird die Konfigurationsdatei „CMakeLists.txt“
im asrLib- Ordner eingelesen und alle Einstellungen und Zuweisungen werden in
CMake übernommen. Falls nötig, können Diese im Editor angepasst werden. Wenn
keine Fehler bei diesem Konfigurationsschritt auftreten, bzw. nach deren Beseitigung,
kann man den gewählten Generator mit der Taste „Generate“ starten.
Die Konfigurationsdatei ist leicht zu verstehen und kann nach Bedarf angepasst werden.
So kann der Zielordner für ausführbare Binärdateien mit Variable „OUTPUT_BINDIR“
geändert werden. Standardmäßig ist das der Ordner „bin“, der sich im vom Benutzer
festgesetzten Ausgabeordner (2. in der Abbildung 12, z.B. build.Codeblocks) befindet.
Der Ordner für alle bei asrLib erzeugten Bibliotheken ist mit der Variable
„OUTPUT_LIBDIR“ zu setzten, standardmäßig „build.Codeblocks/lib“. Welche Ordner
mit Quellcode bei der Kompilation berücksichtigt werden sollen, kann man mit
„add_subdirectory()“ festlegen. Man kann den Namen des Projektes für die
Programmierumgebung mit „PROJECT(asrLib)“ bestimmen.
Um die Konfigurationsdatei übersichtlich zu halten, kann man zusätzliche Einstellungen
in separaten Modulen abspeichern. So sind einige Module im Ordner CMakeModules
abgelegt, die angeben, welche externe Bibliotheken geladen werden sollen und wo diese
zu finden sind. Jeder Ordner mit Quellcode enthält seine eigene Konfigurationsdatei mit
lokalen Zuweisungen. Zum Beispiel ist der Ausgabeordner für Bibliotheken in allen
„CMakeLists.txt“ Dateien in allen Verzeichnissen unter „plugins“ (s. Ordnerstruktur auf
der Seite 17) als „data/plugins“ definiert, im Gegensatz zur oben erwähnten Variable
„OUTPUT_LIBDIR“ („build.Codeblocks/lib“), um diese Bibliotheken von denen, die
aus dem Quellcode unter „src“ erstellt werden, zu trennen. Worin der Unterschied liegt
und wofür dieser gut ist, wird im Kapitel 5.4 erläutert.
5.2. asrLib und Code::Blocks
Code::Blocks braucht nicht besonders vorgestellt zu werden. Das Wichtigste wurde
schon im Kapitel 4.3 geschrieben. Einige Bemerkungen müssen in diesem Kapitel doch
noch gemacht werden. Nach dem Start von Code::Blocks wird es vorgeschlagen, ein
neues Projekt anzulegen oder schon vorhandenes zu öffnen. Hier öffnet man vom
CMake erstelltes Projekt, z.B. „asrLib/build.Codeblocks/asrLib.cbp“. Wie viele andere
Programmierumgebungen kann Code::Blocks nicht nur ein Projekt editieren und
kompilieren, sondern auch ausführen und debuggen. In der Abbildung 13 ist die
Seite 19

Symbolleiste mit den Werkzeugen zum Debuggen mit der Ziffer 1 gekennzeichnet. Auf
der rechten Seite von dieser Leiste ist ein weißes Fenster abgebildet, hier kann man z.B.
den Speicher ansehen oder Variablen beobachten. Die kurzen Popup Meldungen geben
eine verständliche Beschreibung zum jeden Symbol.
1. →
2. →
Abbildung 13: Code::Blocks Übersicht
Mit 2. sind die Werkzeuge zum Ausführen und Kompilieren vom ganzen Projekt oder
seinen einzelnen Teilen markiert. Mit „Build target:“ wählt man den zu kompilierenden
Teil aus („All“ für ganzes Projekt). Falls man irgendwelche Änderungen im Quellcode
außerhalb von Code::Blocks macht, muss das Projekt mit dem Symbol mit zwei blauen
Pfeilen neu geladen werden. Wichtig für das Ausführen von jedem Projekt ist die in der
Abbildung 14 markierte Einstellung (Ordner, aus dem die Anwendung starten soll).
Abbildung 14: Code::Blocks Einstellungen
Seite 20

5.3. Bibliotheken
Wie schon im Kapitel 5 geschrieben wurde, besteht das Projekt asrLib aus einer
Sammlung von Bibliotheken. Diese Sammlung setzt sich aus sechs sozusagen stetigen
Bibliotheken zusammen, die eine Basis für asrLib bilden, und aus von diesen
abgeleiteten Erweiterungsmodulen, die „Plugins“ genannt werden. Bei dem Aufruf von
Applikationen kann man festlegen, welche Plugins benötigt werden. Man kann Diese
bei Bedarf auch während der Laufzeit laden. Der Quellcode (die Ordner „src“ und
„include“ in asrLib- Ordnerstruktur auf der Seite 17) für die sechs Grundbibliotheken ist
in Gruppen aufgeteilt, die zu einem gemeinsamen Namensraum „asrlib“ gehören:
Base (libBase.so) ist die Grundlage für alle anderen Gruppen. *
StateMachine (libStateMachine.so) ist der Kern von allen Dialogsystemen. Stellt ein
Zustandsautomat dar, dessen Aufgabe ist, nicht nur die Zustände eines Systems unter
gegebenen Bedienungen zu wechseln, sondern auch die Konfigurationsdateien
einzulesen und Information dynamisch zu speichern.
Audio (libAudio.so) ist für das Einlesen und Bearbeiten von Audiodateien, für die
Konfiguration von Audiotreiber und für den Austausch von Audiodaten zwischen
Soundkarte und Komponenten eines Spracherkennungssystems zuständig. *
ISDN (libISDN.so) basiert auf ISDN-IO Bibliothek, oder CapiLib, einem Treiber für
ISDN-Komponente. Damit kann der Datenaustausch mittels ISDN realisiert werden. *
ASR (libASR.so) beinhaltet die (virtuellen) Basisklassen für alle Komponente eines
Spracherkennungssystems (Kapitel 3.2.1). Man kann mehrere von ASR abgeleitete und
voneinander unabhängige Spracherkennungssysteme mit verschiedenen Methoden der
Erkennung erstellen und als Plugins bei Dialogsystemen einsetzen.
GUI (libGUI.so) ermöglicht eine einfachere Erstellung von graphischen Oberflächen
und deren Einbindung in Dialogsysteme. GUI gründet auf FLTK 2.0 (Kapitel 4.1) und
hat ihre eigene von FLTK abgeleitete und erweiterte Klassen für Widgets. Zur
Kommunikation zwischen der graphischen Oberfläche und StateMachine wird ein
Controller verwendet. Weiter dazu im Kapitel 7.
* wird bei dieser Arbeit nicht näher betrachtet
Seite 21

Die Bibliothek „libStateMachine.so“ wurde nach in ihr enthaltener Singleton-Klasse
genannt, deren Objekt (weiter einfach StateMachine) alle Prozesse in Dialogsystemen
steuert und die graphische Oberfläche kontrolliert. Für jede Applikation von asrLib
muss eine Konfigurationsdatei vorhanden sein, die das Verhalten von StateMachine
beschreibt. Ein Beispiel für solche Konfigurationsdatei könnte wie folgt aussehen:
frage1
AUDIO_OUT
1 fahren_sie_allein.raw
0
erkennung_ja_nein
erkennung_ja_nein
RECOGNIZE
2 jn.syn M_rec
2 w_nein w_ja
frage2 goodbye
goodbye
frage2
AUDIO_OUT
1 wieviel_personen.raw
0
erkennung_zahl
erkennung_zahl
RECOGNIZE
3 number.syn M_rec B_nummer
0
goodbye
goodbye
AUDIO_OUT
1 goodbye.raw
0
exit
Die oben angegebene Konfiguration eines Dialogsystems ergibt keinen wirklichen Sinn,
es fehlt der Anfang und das Ende. Diese Konfiguration besteht aus fünf Absätzen mit
jeweils sechs Zeilen. Jeder Absatz stellt einen Zustand des Zustandsautomaten dar.
„STATE“ enthält den Namen vom Zustand und „ACTION“ ist sein Verhalten oder
Funktion, die ausgeführt werden soll, während StateMachine sich in diesem Zustand
befindet. „ACTION_PARS“ und „TRANS_SEL“ sind entsprechend die Übergabe- und
mögliche Rückgabe- Parameter dieser Funktion, wobei die ersten Ziffer deren Anzahl
angeben. Die Rückgabeparameter sind Bedingungen für den Zustandsübergang der
StateMachine. In welche Zustände der Zustandsautomat vom aktuellen Zustand
Seite 22

übergehen kann, ist unter „TRANS_STATE“ festgesetzt. Zu jedem Übergang soll also
genau eine Bedingung vorhanden sein. Falls gar keine Rückgabeparameter von der
aktuellen Action vorgesehen sind oder falls ein Parameter zurückgegeben wird, der
nicht unter „TRANS_SEL“ aufgelistet ist, kommt „DEFAULT_TRANS“ in Betracht,
das den Namen des Zustandes enthält, in den StateMachine vom aktuellen Zustand bei
default wechseln soll. Wenn der aktuelle Zustand hier seinen eigenen Namen hat, bleibt
StateMachine in diesem Zustand und die Action wird nochmal ausgeführt.
Damit man diese Beschreibung des Verhaltens von StateMachine besser nachvollziehen
kann, soll man diese in einem Zustandsübergangsdiagramm ansehen:
STATE: frage1
ACTION: AudioOut
w_nein
STATE: frage2
ACTION: AudioOut
STATE: erkennung_ja_nein
ACTION: Recognize
STATE: erkennung_zahl
ACTION: Recognize
w_ja
STATE: goodbye
ACTION: AudioOut
Abbildung 15: Beispiel Zustandsautomat
In Wirklichkeit sind diese Actionen keine ausführbare Funktionen, sondern Klassen, die
von „asrlib::Action“ aus der StateMachine- Bibliothek abgeleitet wurden.
Class AudioOut : public asrlib::Action
{
void execute();
}
Die States sind Objekte der Klasse „asrlib::State“, die jeweils ein entsprechendes Objekt
von Action besitzen und sich anhand der Namen unterscheiden.
Class State
{
State(std::string name) {};
Action* action;
}
State* state1 = new State(„frage1“);
state1->action = new AudioOut();
State* state2 = new State(„erkennung_ja_nein“);
state2->action = new Recognize();
Seite 23

Bevor man StateMachine startet, soll die Konfigurationsdatei eingelesen werden. Es
sollen so viele Objekte der Klasse asrlib::State erstellt und in StateMachine in einem
Map gespeichert werden, wie viele States diese Datei enthält. In unserem Beispiel sind
das 5 Objekte. Nach dem Start von StateMachine wird die Funktion execute() des
Action-Objektes vom ersten State aus dem Map aufgerufen. Genau diese Funktion führt
die gewünschte Aktion durch, z.B. die Wiedergabe einer Audiodatei. Diese Schritte
könnten in einer vereinfachter Form so aussehen:
stateMap[„frage1“] = new State(„frage1“);
stateMap[„frage1“]->action->execute();
// Ein STATE erstellen
// ACTION ausführen
Nicht nur die States, sondern auch die zugehörige „TRANS_STATE“ und
„DEFAULT_TRANS“ werden in StateMachine gespeichert, damit diese weiß, welches
State als nächstes aus dem Map genommen werden soll.
Das war eine kurze Beschreibung der Hauptaufgaben von StateMachine- Bibliothek.
Eine weitere Bibliothek, die in diesem Kapitel noch ganz kurz beschrieben werden soll,
ist ASR, oder „libASR.so“. Wie schon früher geschrieben wurde, stellt diese Bibliothek
eine abstrakte Basisklasse für ein komplettes Spracherkennungssystem mit allen seinen
Komponenten zur Verfügung. Der Benutzer dieser Bibliothek kann selbst entscheiden,
welche Komponente beim jeweiligen System gebraucht werden und muss ihr Verhalten
selbst beschreiben, d.h. den Quellcode, für z.B. Erkennung, erstellen, dabei können
beliebige Verfahren eingesetzt werden und nicht nur die, die in Kapiteln „Analyse“ und
„Erkennung“ auf den Seiten 8 und 9 erwähnt wurden. Alle Spracherkennungssysteme
sollen im Ordner „plugins“ erstellt werden (s. Ordnerstruktur auf der Seite 17). Für die
bessere Übersicht wird es empfohlen, deren Bibliotheken getrennt von den Basis-
Bibliotheken abzuspeichern. Es gibt schon ein fertiges Spracherkennungssystem mit
dem Namen „AsrHGH“ (Bibliothek „AsrHGH.so“ unter „data/plugins“), das mit
Hidden-Markov-Modellen arbeitet und HirschLib- Bibliotheken verwendet. Dieses
System und seine Komponente werden im Kapitel 6 beschrieben.
ASR hat eine kleine Abweichung vom in der Abbildung 1 auf der Seite 7 dargestellten
Spracherkennungssystem. DC-Filter gehört nicht zu ASR- Komponenten, wie auf dem
Bild gezeichnet, sondern wurde als ein Teil des Erweiterungsmoduls „AudioFX“ unter
„plugins“ erstellt, dessen Bibliothek „AudioFX.so“ schon nach dem Start vom
Dialogsystem bei Bedarf geladen werden kann.
Seite 24

5.4. Plugins
Die Erweiterungsmodule, oder Plugins, unterscheiden sich von Basis- Bibliotheken,
indem sie zum beliebigen Zeitpunkt während der gesamten Laufzeit der jeweiligen
Applikation vom beliebigen Ort geladen werden können. Gewünschte Plugins können,
und in bestimmten Fällen sogar müssen, bei dem Start von Applikation als Parameter
übergeben werden. Wie man solche Applikationen startet, kann man am Beispiel vom
multimodalen Dialogsystem „GuiApp“ sehen:
./GuiApp -s StatFile -l ASRActions -l PluginGUI [-d Path] [-l PluginN]
StatFile Konfigurationsdatei für Dialogsystem
ASRActions Plugin mit Actionen des gewünschten Spracherkennungssystems
PluginGUI Plugin für graphische Oberfläche
PluginN Beliebige weitere Plugins, optional
Path Der optionale Pfad zum StatFile ('../../data' bei default)
Bei dem sprachbasierten Dialogsystem „DialogHGH“ wird der Parameter „PluginGUI“
ausgelassen. Alle zu ladende Plugins werden unter mit dem Parameter „Path“ gesetztem
Pfad (einschließlich Pfad/plugins und Pfad/lib) gesucht. Unter diesem Pfad sollten sich
neben der Konfigurationsdatei alle verwendeten Daten befinden (Listfiles, Audiodateien
u.s.w.), damit die Konfiguration leichter und übersichtlicher wird. Der Pfad ist
standardmäßig auf „../../data/“ von der Sicht des Stammordners der Applikation (z.B.
build.Codeblocks/bin, Ordnerstruktur auf der Seite 17) gesetzt. Falls die Plugins unter
dem Pfad nicht gefunden werden, wird dieser Stammordner (einschließlich ./plugins
und ./lib, falls vorhanden) durchsucht. Dies ermöglicht eine beliebige Strukturierung
von Dialogsystemen und eine trotzdem automatische Zuweisung von allen benötigten
Plugins. Beim Laden von Plugins reicht es, nur deren Namen mit Suffix anzugeben.
Falls ein Plugin aus einem von oben angegebenen Pfaden abweichenden Ordner geladen
werden soll, muss dessen Name mit dem vollständigen Pfad angegeben werden. In der
Plugin- Übersicht auf der nächsten Seite kann man alle schon verfügbare Plugins
kennenlernen. Diese Übersicht zeigt auch, welche von Diesen automatisch geladen
werden und welche man explizit bei dem Aufruf von Applikation laden muss.
Die im vorherigen Kapitel vorgestellte Basis- Bibliotheken werden noch während der
Kompilation in die Applikation eingebunden und dürfen nicht aus dem Ordner
verschoben werden, in dem diese erstellt wurden (s. Ordnerstruktur auf der Seite 17
Seite 25

oder Variable „OUTPUT_LIBDIR“ in der CMake- Konfigurationsdatei). Diese
Bibliotheken sollen also noch vor dem Start des Dialogsystems aus dem bekannten
Ordner geladen werden können. Um Basis- Bibliotheken etwas Dynamik zu verleihen,
kann man mit „link_directories()“ in „CMakeLists.txt“ einen (lieber zum Stammordner
der Applikation relativen) Pfad zum einen zusätzlichen Verzeichnis setzen, aus dem die
Bibliotheken alternativ zu laden sind. Plugins können dagegen nach der Kompilation,
wie oben beschrieben wurde, beliebig verschoben werden. Im Gegensatz zu Basis-
Bibliotheken hat jedes Plugin natürlich seinen eigenen Namensraum.
Actions (Actions.so) sind alle von asrlib::Action abgeleitete Klassen, die man zum
einen Zustandsautomaten mit einem breiten Funktionsumfang zusammenstellen kann
und die jeweils eine ACTION von StateMachine darstellen, z.B. „AudioOut“ in der
Abbildung 15. Namensraum: „asrActions“. *
ActionsHGH (ActionsHGH.so) ist eine Ergänzung von Actions um die Klassen zur
Initialisierung und Steuerung vom Spracherkennungssystem namens AsrHGH (s.u.),
z.B. Klasse „Recognize“, Abbildung 15. Namensraum: „actionsHGH“.
AsrHGH (AsrHGH.so) ist ein Spracherkennungssystem, das mit HMM's arbeitet und
HirschLib- Bibliotheken verwendet. Namensraum: „asrHGH“. *
AudioFX (AudioFX.so) stellt verschiedene Tools zum Bearbeiten von Audiosignalen
zur Verfügung, Zum Beispiel den schon früher erwähnten DC-Filter zur Beseitigung
von DC-Offset. Weitere Filter können hier erstellt werden. Namensraum: „audioFX“. *
GuiFKA (GuiFKA.so) stellt eine graphische Oberfläche zur Steuerung von einem
Fahrkartenautomaten dar. Soll zusammen mit einem Spracherkennungssystem- Plugin
aufgerufen werden. Namensraum: „guiFKA“.
GuiPHA (GuiPHA.so) ist ein weiteres Plugin für graphische Oberfläche. Damit kann
man einen Parkhausautomaten steuern. Namensraum: „guiPHA“.
* diese Plugins werden automatisch geladen und müssen nicht extra als Parameter bei dem Start der
jeweiligen Applikation übergeben werden. Voraussetzung dafür ist, dass die Plugins sich unter einem der
auf der vorherigen Seite beschriebenen Pfaden befinden. Falls das nicht der Fall ist, müssen auch diese
Plugins explizit vom Benutzer geladen werden.
Seite 26

5.5. Wichtiges
In diesem Kapitel werden noch einige wichtige Bemerkungen als Abschluss der
Beschreibung von asrLib gemacht, die für die beiden weiteren Kapitel nützlich sein
können. Die Tabelle auf der nächsten Seite gibt einen Überblick über die Actionen aus
dem Plugin „Actions“, die man bei den Konfigurationsdateien für Dialogsysteme
verwenden kann. Wie schon oben erwähnt wurde, muss für jedes Dialogsystem
mindestens eine solche Datei vorhanden sein. Man kann aber auch mehrere
Konfigurationsdateien erstellen und zwischen diesen mit „LOAD_STAT“ (s. Tabelle)
wechseln während das System läuft. Dabei werden die meisten Daten gelöscht, die bei
der Verarbeitung der aktuellen Konfigurationsdatei erstellt und im Speicher von
StateMachine abgelegt wurden. Deshalb gibt es bei diesem Projekt zwei Möglichkeiten,
die Daten währen der Laufzeit einer Applikation abzuspeichern.
Die erste Möglichkeit ist ein „lokaler“ Speicher, der die Daten nur für die aktuelle
Konfigurationsdatei behält. Wird eine andere '*.stat'- Datei geladen, wird ein neues
Zustandsautomat erzeugt und StateMachine vernichtet die ganze Information in diesem
Speicher. Die Klasse „Buffer“ aus der „StateMachine“- Bibliothek ist für diesen
Speicher zuständig, der im Weiteren einfach als Buffer bezeichnet wird. Buffer ist an
StateMachine gebunden und kann Daten von allen möglichen Typen abspeichern. In
einer Konfigurationsdatei sind diese Daten meistens vom Typ „std::string“ und
„std::vector“ (oder auch 2- und 3- dimensionale Vektoren). Dabei müssen
die Namen vom Buffer mit „B_“ anfangen, z.B. „B_syntax“ für ein Buffer, in dem der
Pfad zu einer Syntax- Datei gespeichert ist. Bei Verwendung des Buffers im Quellcode
werden diese Regeln nicht beachtet, man kann beliebige Namen und Typen nehmen.
Die zweite Art des Speichers wird vorwiegend im Quellcode benutzt und kann bei
jedem Objekt angewendet werden, der von der Klasse „Base“ abgeleitet wurde. In der
Konfigurationsdatei wird dieser Speicher zum Anlegen vom Spracherkennungssystem
verwendet, dessen Name mit „M_“ anfangen soll, um sich vom Buffer zu
unterscheiden. Wird eine andere Konfigurationsdatei geladen, bleibt dieses System
erhalten. Der Speicher muss extra gelöscht werden, wenn der nicht mehr benutzt wird.
stateMachine->addBuffer(new Buffer("B_Name", "Wert"));
stateMachine->addProperty("M_Name", "Wert");
stateMachine->rmProperty("M_Name");
Seite 27

Diese Tabelle enthält alle Namen der zur Zeit der Erstellung dieser Masterarbeit
vorhandenen Klassen aus dem Plugin „Actions“ und deren kurze Beschreibung.
Name der Action (Klasse)
AUDIO_OUT (AudioOut)
CALCULATOR (Calculator)
COMPARATOR (Comparator)
CONVERT_TO_DATE (ConvertToDate)
CONVERT_TO_MONEY
(ConvertToMoney)
CONVERT_TO_TIME (ConvertToTime)
EXIT (Exit)
INIT (Init)
ISDN_EXIT (ISDNExit)
ISDN_INIT (ISDNInit)
LOAD_COUNTER (LoadCounter)
LOAD_STAT (LoadStat)
PRINT_BUFFER (PrintBuffer)
RANDOM_NUMBER (RandomNumber)
READ_FROM_FILE (ReadFromFile)
READ_LIST_FILE (ReadListFile)
REPLACE (Replace)
SAVE_COUNTER (SaveCounter)
SEARCH_IN_BUFFER (SearchInBuffer)
SEARCH_IN_FILE (SearchInFile)
SET_TRANS_STATE (SetTransState)
TEST (Test)
TRANSCEIVER (Transceiver)
WAIT (Wait)
WAIT_FOR_CALL (WaitForCall)
WRITE_TO_BUFFER (WriteToBuffer)
Funktion
Gibt Audiodateien über die Lautsprecher oder über
ISDN wieder
Ein Taschenrechner mit Grundrechenarten
Vergleicht zwei Werte (Text, Zahlen, Datum)
Konvertiert den gegebenen Wert in Format
"tt.mm.jjjj"
Konvertiert den gegebenen Wert in Vector im
Format "[x euro y cent]"
Konvertiert den gegebenen Wert in Vector im
Format "[ss hour mm minutes]"
Löscht das gesamte Buffer und stoppt Applikation
Legt Parameter für Audioausgabe über die
Soundkarte fest
Entfernt alle Konfigurationen für
Sprachübertragung mittels ISDN
Legt Parameter für die Sprachübertragung mittels
ISDN fest
Liest eine Zahl aus der gegebenen Textdatei und
speichert diese intern als „SM_COUNTER“
Liest eine Konfigurationsdatei ('*.stat') und
verarbeitet deren Actionen
Gibt den Inhalt eines Buffers auf der Konsole aus
Zufallszahlengenerator
Liest die Daten aus einer Textdatei ein
Liest ein Listenfile komplett oder zeilenweise ein
Ersetzt oder löscht Inhalte eines Buffers
Schreibt eine Zahl in gegebene Textdatei
Durchsucht Buffer nach bestimmten Inhalten
Durchsucht eine Textdatei nach bestimmten
Inhalten
Gibt den Inhalt eines Buffers zurück
Testet das aktuelle stat-File auf Vollständigkeit
Schnittstelle für Kommunikation mit GUI
Wartet eine (un-)bestimmte Zeit auf ein Ereignis
Wartet eine bestimmte Zeit auf einen Anruf
Erstellt, kopiert, belegt und bearbeitet ein Buffer
Seite 28

Noch eine Klasse aus der Base- Bibliothek, deren Funktionen bei dieser Arbeit noch
erwähnt werden, ist „CallbackInterface“. Mit dieser Klasse kann eine Kommunikation
in der Form von Ereignissen, oder Events, zwischen beliebigen Klassen im asrLib-
Projekt realisiert werden. Die drei wichtigsten Funktionen, die dabei verwendet werden,
sind „registerCallback()“, „executeCallback()“ und „removeCallbak()“ aus
„include/Base/Callbak.h“. Wie der Name der ersten Funktion schon vermuten lässt,
kann man diese mit der Registrierung eines Postfaches vergleichen. Mit der zweiten
Funktion wird das Senden einer Nachricht durchgeführt. Im Weiteren wird so eine
Nachricht einfach als Callback bezeichnet, weil diese in Wirklichkeit ein Objekt der
Klasse „Callback“ ist. Um den belegten Speicher wieder freizugeben, kann man das
registrierte Callback mit der dritten Funktion löschen. Die Klasse „CallbackInterface“
wurde als Basisklasse für die Klasse „Base“ genommen, deshalb kann man Callbacks
direkt bei Objekten der von „Base“ abgeleiteten Klassen registrieren. In diesem Fall
sind die registrierten „Postfächer“ nur für diese Objekte zu sehen. Man kann die
Callbacks auch so registrieren, dass die aus allen Klassen gesendet werden können.
Dafür ist die Klasse „CallbackBuffer“ mit ihrem globalen Singleton- Objekt gedacht.
1. Callback* cb =
new Callback(_adaption, &AdaptionHGH::adaptionCallback);
2. _recognizer->registerCallback("adaptionCallback", cb);
3. _recognizer->executeCallback("adaptionCallback", (void*)(data));
4. _recognizer->removeCallback("adaptionCallback", _adaption);
In diesem Beispiel- Quellcode wird, als Erstes, ein Callback erstellt. Sein Konstruktor
soll zwei Parameter erhalten: ein Objekt, an den das Callback später gesendet werden
soll, und eine Referenz auf die Funktion von diesem Objekt, die dabei aufgerufen
werden soll. Als Zweites wird dieses Callback mit einem speziellen Namen registriert.
Man kann Callback bei einem Objekt registrieren, dann wird es an dieses Objekt
gebunden, wie in diesem Beispiel. Damit Callback nicht objektbezogen ist, soll man
„CallbackBuffer->getInstance()“ statt „_recognizer“ verwenden. Das gilt auch für die
letzten zwei Zeilen. Als Drittes wird Callback gesendet. Die zu sendenden Daten
werden (standardmäßig implizit) zum Typ „Zeiger auf void“ konvertiert. Man kann
mehrere Callbacks mit gleichen Namen registrieren, die an unterschiedliche Objekte
gesendet werden. So kann man mit einer einzigen Nachricht mehrere Funktionen
aufrufen. Deshalb soll man beim Löschen vom Callback auch den Empfänger eingeben.
Seite 29

6. Parallele Erkennung
Wie es schon in der Aufgabenstellung geschrieben wurde, sollen mehrere Erkenner bei
einer Spracherkennung gleichzeitig eingesetzt werden, um eine schnellere und, was sehr
wichtig ist, bessere Erkennung gewährleisten zu können. In diesem Kapitel geht es um
die Realisierung von dieser Methode, um die dabei aufgetretene Schwierigkeiten und
um die Problematik der Implementierung. Der Einblick in den Quellcode wird von einer
Erläuterung gefolgt, wieso es gerade so gemacht wurde und nicht anders.
Bevor wir uns mit der parallelen Erkennung beschäftigen, soll die Funktionsweise eines
Spracherkennungssystems dargestellt werden. Das einzig zum Zeitpunkt der Erstellung
dieser Dokumentation vorhandene Spracherkennungssystem ist „AsrHGH“. Das in
vorherigen Kapiteln schon erwähnte Plugin wird hier etwas ausführlicher beschrieben.
Bis jetzt wurde das Plugin „AsrHGH“ einfachheitshalber als Spracherkennungssystem
bezeichnet. In Wirklichkeit ist das nur ein Erweiterungsmodul oder eine Bibliothek, in
der das in der Abbildung 1 auf der Seite 7 dargestellte Spracherkennungssystem
enthalten ist. Dieses System und alle seine Komponenten haben ihre eigenen Namen,
mit denen diese auch angesprochen werden können. So hat die Komponente, die für die
Analyse des Eingangssignals zuständig ist, den Namen „AnalyzerHGH“ und der
Erkenner heißt „RecognizerHGH“. Diese Komponenten und alle Bestandteile von
anderen Plugins sind Objekte bestimmter Klassen, anhand denen die Namen vergeben
wurden. Dateien mit Quellcode und zugehörige Headerfiles befinden sich bei Plugins in
einem Ordner (Diese von Grundbibliotheken wurden in „src“ und „include“ aufgeteilt,
s. Ordnerstruktur auf der Seite 17). Eine Zusammenfassung des Plugins „AsrHGH“ im
Zusammenhang mit der Abbildung 1:
asrLib
| --- plugins // Ordner mit Quellcode für alle Erweiterungsmodule
| --- AsrHGH // Plugin für Spracherkennungssystem
| --- AdaptionHGH // Adaption
| --- AnalyzerHGH // Analyse
| --- ApplicationHGH // Spracherkennungssystem
| --- NoiseEstimator // Sprachdetektion
| --- RecognizerHGH // Erkennung
Seite 30

Um das Spracherkennungssystem benutzen zu können, muss sein Objekt erstellt
werden. Das soll in einer der Actionen von StateMachine passieren. Wie auf den Seiten
22 und 23 bei der Beschreibung von StateMachine geschrieben wurde, sind Actionen
die von asrlib::Action abgeleitete Klassen. Man kann beliebig viel solcher Klassen, z.B.
für Audioausgabe (wie „AudioOut“) oder für den Start eines Spracherkennungssystems
(wie „Recognize“), erstellen und als Plugins der asrLib- Sammlung beifügen. So wurde
die schon mehrmals erwähnte Klasse „Recognize“ zusammen mit anderen Klassen für
die Steuerung des Spracherkennungssystems „ApplicationHGH“ (Plugin „AsrHGH“)
unter dem separaten Plugin mit dem Namen „ActionsHGH“ erstellt:
asrLib
| --- plugins // Ordner mit Quellcode für alle Erweiterungsmodule
| --- ActionsHGH // Plugin für die Steuerung von „AsrHGH“
| --- Recognize // Hier findet die gesamte Spracherkennung statt
| --- RecognizeExit // Löscht das Spracherkennungssystem
| --- RecognizeInit // Erstellt und Initialisiert das Spracherkennungssystem
| --- RecognizeTest // Hier wird die Spracherkennung getestet
Der gesamte Quelltext von diesem Plugin befindet sich in den Headerfiles. Alle diese
Klassen und die Klassen aus dem Plugin „Actionen“ (s. Plugin- Übersicht auf der Seite
26) werden in den Konfigurationsdateien für Dialogsysteme jeweils als eine ACTION
dargestellt. Wie man im Beispiel für so eine Konfigurationsdatei auf der Seite 22 sehen
kann, haben diese Actionen andere Namen als die zugehörige Klassen. Das wurde extra
für eine bessere Darstellung gemacht. Die Übersetzung der Namen ist in einer einzelnen
bei dieser Art von Plugins Quellcodedatei „export.cpp“ mit POCO festgelegt, z.B.:
POCO_EXPORT_NAMED_CLASS(Recognize,RECOGNIZE)
Das Spracherkennungssystem „ApplicationHGH“ wird in der Klasse „RecognizeInit“
erstellt. Zuerst sollte aber seine Bibliothek geladen werden, falls noch nicht geschehen.
Die beiden Schritte sind in einem Auszug aus „RecognizeInit.h“ zu sehen:
PluginFactory::get()->loadLibrary("AsrHGH.so");
// vereinfacht, s. Quelltext
ASRApplication* asrApp =
dynamic_cast(PluginFactory::get()->create("ApplicationHGH"));
Seite 31

„PluginFactory“ ist eine Singleton- Klasse aus der Base- Bibliothek, die für das
Einbinden von Bibliotheken mit Hilfe von POCO zuständig ist. „ASRApplication“ aus
der ASR- Bibliothek ist die Basisklasse für alle Spracherkennungssysteme. Wie der
Name „RecognizeInit“ schon sagt, wird das Spracherkennungssystem hier nicht nur
erstellt, sondern auch konfiguriert. Die gewünschte Konfiguration kann man in der
Konfigurationsdatei vornehmen (vgl. diese auf der Seite 22):
RECOGNIZE_INIT
[SM_DC_BLOCK] [] [] [] []
Anzahl der folgenden Komponenten
Listenfile mit allen zu verwendeten HMM- Mustern
SM_DC_BLOCK DC-Filter einschalten, optional(AudioFX.so wird geladen)
Erkennung mit zusätzlichen Funktionen durchführen, optional
SM_ADAPTION Erkennung mit Adaption der Muster
SM_ROBUST Robuste Erkennung
SampleRate in Hz (8000, 11000, 16000), optional
SampleDataFormat (INT16, INT32, FLOAT32), optional
VectorType (MFCC_E, MFCC_E_0, MFCC_E_D_A, MFCC_E_D_A_0) opt
Der Name des zu erstellenden Spracherkenners
Mit dem Spracherkennungssystem können die direkt vom Mikrophon aufgenommene
Daten, die Daten über eine Telefonleitung oder sogar Audiodateien verarbeitet werden.
Im letzten Fall soll man die zu erkennende Audiodatei an „Recognize“ übergeben.
RECOGNIZE
[] [] [] []
SM_GUI
SM_BUTTON
SM_KEY
Anzahl der folgenden Komponenten
Erkennung darf extern unterbrochen werden, optional
Unterbrechung durch GUI
Unterbrechung durch den Knopf am Infokasten
Unterbrechung durch eine Taste auf der PC-Tastatur
Syntaxfile
Die zu erkennende Audiodatei, optional
Der Name des zu verwendeten Spracherkenners
Weitere Spracherkenner zum parallelen Betrieb, optional
Ein Speicher für die Erkennungsergebnisse, optional
Für die Spracherkennung mittels ISDN soll die ISDN-Schnittstelle mit ISDN_INIT aus
dem Plugin „Actions“ noch vor RECOGNIZE_INIT konfiguriert werden. Während der
Seite 32

Erkennungsphase wird es automatisch erkannt, um welche Quelle es sich handelt. Bei
der Erkennung von einer Audiodatei wird diese gleichzeitig über die Lautsprecher oder
Telefonhörer wiedergegeben. Diese Funktion kann man nur durch die Änderung im
Quellcode abschalten. Falls man die Erkennung von mehreren Audiodateien einfach
testen möchte, könnte es sehr lange dauern, bis alle Dateien abgespielt werden. In
diesem Fall greift man zur einen abgekürzten Version von „Recognize“, die
„RecognizeTest“ heißt und die nur Audiodateien bearbeiten kann und keine Verbindung
zur ISDN- oder Sound- Karte hat. „RecognizeTest“ unterstützt parallele Erkennung
nicht und kann nicht extern (z.B. durch GUI) unterbrochen werden.
RECOGNIZE_TEST
[]
Anzahl der folgenden Komponenten
Syntaxfile
Die zu erkennende Audiodatei
Der Name des zu verwendeten Spracherkenners
Ein Speicher für die Erkennungsergebnisse, optional
Ein Spracherkennungssystem kann nur einmal bei der Erstellung konfiguriert werden,
deshalb passiert nichts, wenn man es nochmals an „RecognizeInit“ übergibt. Um es
umkonfigurieren zu können, muss man es mit „RecognizeExit“ komplett löschen.
RECOGNIZE_EXIT
1
Der Name des Spracherkenners, der gelöscht werden soll
Das war eine kurze Einführung in die Möglichkeiten eines Spracherkennungssystems,
damit man eine Vorstellung hat, wie ein Spracherkenner erstellt und betrieben werden
kann. Für etwas ausführlichere Beschreibung von beiden Plugins „ActionsHGH“ und
„Actions“ soll man Dokumentation des Projektes (s. Ordnerstruktur auf der Seite 17)
lesen und/oder den Quellcode ansehen. Im Weiteren wird nur noch der Quellcode von
„Recognize“ und „RecognizeInit“ im Zusammenhang mit der Darstellung der
Funktionsweise eines Spracherkennungssystems betrachtet.
Wir wissen jetzt, wie man ein Spracherkennungssystem mit einer Konfigurationsdatei
steuern kann. Nun kommen wir zu seiner Beschreibung zurück und werden uns den
inneren Ablauf anschauen.
Seite 33

Da „ASRApplication“ die Basisklasse für alle mögliche Spracherkennungssysteme im
asrLib- Projekt ist, werden auch die grundlegende Funktionen und Zwischenschritte, die
für diese Systeme gleich sind, hier ausgeführt. In dem Quellcode des von dieser Klasse
abgeleiteten Spracherkennungssystems wird nur seine spezifische Bearbeitungsweise
von Daten beschrieben, wie z.B. die Erkennung von Mustern selbst. Bei jedem System
muss ein Objekt erstellt werden, der für alle Audioeinstellungen zuständig ist und den
Austausch von Audiodaten zwischen einzelnen Schnittstellen kontrolliert, sozusagen ein
Manager (weiter einfach AudioManager). Dieser wird in „RecognizeInit“ bzw. in
„ISDNInit“, wenn die Datenübertragung über ISDN geführt werden soll, erstellt und
speichert alle dabei erhaltene Einstellungen, so wie Datenformat, Frequenz und die
Länge eines Signalabschnittes (s. Kapitel 3.2.2), oder, um genauer zu sein, die Anzahl
der Abtastwerte in einem Abschnitt. Bei einem 8 kHz Signal und einer Länge von 25
ms sind das 200 Werte, bei 11 kHz und 16 kHz sind das entsprechend 275 und 400
Abtastwerte. In der Zeit der Erstellung dieser Masterarbeit werden nur die drei
Frequenzbereiche vom asrLib- Projekt unterstützt. Falls AudioManager bei der ISDN-
Initialisierung erstellt wurde, wird dieser vom Spracherkennungssystem während seiner
Konfigurierung übernommen. Das Ganze funktioniert folgendermaßen:
Allen selbständigen Komponenten eines Dialogsystems bei asrLib (sei das ein Objekt,
das eine Audiodatei darstellt, eine Schnittstelle für die Audioausgabe über die
Lautsprecher oder ein Spracherkenner) muss derselbe AudioManager zugewiesen
werden, um eine reibungslose Kommunikation und eine richtige Ein- bzw. Ausgabe von
Daten realisieren zu können. Eine Übergabe vom Audiomanager könnte so aussehen:
audioDatei->setAudioManager(asrApp->getAudioManager());
Bei ISDN_INIT wird eine Schnittstelle namens „ISDN_FRONTEND“ für die
Datenübertragung mittels ISDN mit eigenem AudioManager erstellt und als Property
(ein „globaler“ Speicher, s. Kapitel 5.5) bei StateMachine gespeichert. Jedes Mal, wenn
Audiodaten ausgegeben oder aufgenommen werden sollen, wird es auf das
Vorhandensein dieser Schnittstelle geprüft. Bei Erfolg wird Diese verwendet und ihr
AudioManager wird übernommen. (sm = StateMachine, a = AudioManager,
getProperty() = gib Speicher, get() = gib Objekt in diesem Speicher)
if (sm->getProperty("ISDN_FRONTEND"))
a = sm->getProperty("ISDN_FRONTEND")->get()->getAudioManager();
Seite 34

Hier könnte man auf die Idee kommen, AudioManager im asrLib- Projekt global zu
deklarieren, damit alle Komponente ihn bei Bedarf verwenden können, ohne diese
aufwendige Übergabe machen zu müssen. Es kann aber vorkommen, dass man die
Daten über Mikrofon mit 8 kHz aufnehmen möchte, dabei aber nur die 16 kHz- Daten
für die Ausgabe über die Lautsprecher zur Verfügung hat. In diesem Fall müssen
mindestens zwei AudioManager erstellt werden, einen für die Aufnahme und einen für
die Ausgabe. Bei dem Start von jedem Dialogsystem wird StateMachine erstellt und
initialisiert, dabei wird eine Schnittstelle für die Audioausgabe über die Lautsprecher in
der Action „INIT“ (ist in der Funktion „StateMachine::initialize()“ festgelegt, unter
„src/StateMachine/StateMachine.cpp“, muss also in der Konfigurationsdatei nicht extra
angegeben werden) als Property „SOUNDCARD_FRONTEND“ an StateMachine
automatisch angehängt. AudioManager bekommt hier Standardeinstellungen (Frequenz
8000, Datentyp INT16, Abtastwerte 200). Man kann diese Einstellungen jede Zeit in der
Konfigurationsdatei mit „INIT“ ändern. „ISDN_FRONTEND“ hat eine höhere Priorität,
„SOUNDCARD_FRONTEND“ wird erst dann für die Audioausgabe verwendet, wenn
die erste Komponente nicht vorhanden ist.
Es ist schon klar, dass man zwei unterschiedliche AudioManager für die Aufnahme und
Audioausgabe verwenden soll. Ein weiteres Problem tritt auf, wenn man zwei, oder
noch schlimmer, mehrere, Spracherkenner mit Modellen mit unterschiedlichen
Frequenzen bei einer parallelen Erkennung einsetzen möchte. Die Lösung ist, bei jedem
Spracherkennungssystem ein eigenes „SOUNDCARD_FRONTEND“ mit eigenem
AudioManager zu erstellen. Dabei wird es als Property mit dem Namen
„AudioFrontend“ (für die bessere Unterscheidung) dem Spracherkennungssystem
zugewiesen und nicht mehr der StateMachine. Alle Bedingungen bleiben erhalten.
Eine weitere wichtige Einstellung für AudioManager ist der Zeitintervall für einen
iterativen „Wecker“, der wie folgt gesetzt wird („* 1000.0“ für Millisekunden):
audioManager->setTimeStep((float)frameSize / (float)sampleRate * 1000.0);
Bei einem Verhältnis der Anzahl der Abtastwerte zur Frequenz von 1 zu 40 (200/8000)
wird die Funktion „ASRApplication::onTimer()“ unter „src/ASR/ASRApplication.cpp“
alle 25 ms von diesem Wecker aufgerufen. Der Wecker wird zusammen mit dem
Spracherkennungssystem gestartet und gestoppt. Das ist ein selbständiger Prozess, der
mit Hilfe von POCO ausgeführt wird und parallel zum Dialogsystem läuft. Die von
Seite 35

diesem Prozess angesprochene Funktion muss komplett abgearbeitet werden, bevor sie
wieder vom Wecker aufgerufen werden kann, auch wenn die Bearbeitungszeit länger als
25 ms dauert. Das muss man bei der Programmierung beachten. Diese Funktion führt
eine andere, abstrakte Funktion „tick()“ aus, die in einer abgeleiteten Klasse (in diesem
Fall „ApplicationHGH“) erstellt werden soll und den ganzen Prozess der
Spracherkennung beschreiben soll.
Aber bevor ein Spracherkenner startet, soll sein vorher initialisiertes „AudioFrontend“
gestartet werden, bei dem ein zweites Wecker genauso als paralleler Prozess in
Funktion tritt. Diesmal ist der Wecker die Soundkarte des Rechners, oder ihr Treiber,
der von dem externen Tool „portaudio“ zur Verfügung gestellt wird. Jedes Mal, wenn
der für die aufgenommenen Daten reservierte Platz voll ist, wird die Funktion
„SoundcardFrontend::paCallbackFun()“ unter „src/Audio/SoundcardFrontend.cpp“ in
Gang gesetzt. Bei 8 kHz und 200 Werten ist das ein Zeitintervall in genau 25 ms.
Um besser zu verstehen, wozu diese zwei „Wecker“ benötigt werden, sollte man die
Abbildung 16 ansehen. Die im AudioManager registrierte Komponente kann z.B. DC-
Filter sein. In diesem Fall werden die aufgenommenen Daten von „SoundcardFrontend“
direkt an „DCBlocker“ übergeben und dieser stellt dann die von ihm bearbeiteten Daten
als Signalabschnitte zur Verfügung.
alle 25 ms
alle 25 ms
SoundcardFrontend::
paCallbackFun()
ASRApplication::
onTimer()
ApplicationHGH::
tick()
Alle Komponenten des
Spracherkennungssystems
AnalyzerHGH::analyze()
NoiseEstimator::estimate()
[ AdaptionHGH::adapt() ]
RecognizerHGH::process()
0 1 2 3 4 5 6 ...
Signalabschnitte
Abtastwerte
0 1 2 3 4 5
Merkmalsvektoren
AudioManager::
tickCb()
Für alle im AudioManager
registrierten Komponenten:
tick()
BufferedIOAdaptor::tick()
[ DCBlocker::tick() ]
...
Abbildung 16: Ablaufplan einer Spracherkennung
Seite 36

Auch „AudioFile“ kann als eine weitere Komponente im AudioManager registriert
werden. Dabei werden die Daten vom „SoundcardFrontend“ ignoriert und durch die
Daten aus einer Audiodatei ersetzt, die weiter bearbeitet werden können. Man kann also
beliebige Komponente, die von der Klasse „AudioComponent“ (libAudio.so) abgeleitet
wurden, im AudioManager registrieren, indem man diese Komponenten einfach startet.
audioFrontend->getInput(0)->setSource(audioFile->getOutput(0));
audioFrontend->getInput(1)->setSource(audioFile->getOutput(0));
audioFile->start();
dcBlocker->getInput(0)->setSource(audioFile->getOutput(0));
dcBlocker->start();
asrApp->getInputAdaptor()->getInput(0)->setSource(dcBlocker->getOutput(0));
audioFrontend->start();
asrApp->start();
In diesem Beispiel für einen möglichen Quellcode werden die Daten aus einer
Audiodatei (0 = links, mono) an „audioFrontend“, das sowie ein Objekt der Klasse
„SoundcardFrontend“ als auch der Klasse „ISDNFrontend“ sein kann, zur Ausgabe über
die Lautsprecher (1 = rechts) bzw. Telefonhörer übergeben. Diese Daten werden mit
dem DC- Filter bearbeitet. Von diesem Filter werden die Daten als Signalabschnitte an
„BufferedIOAdaptor“ geleitet (die dritte Zeile von unten). Mit „audioFrontend“ und
„asrApp“ wird der ganze Prozess gestartet, entsprechend rechte und linke Seiten der
Abbildung 16. Mit diesem vereinfachten Quelltext kann man also eine Audiodatei
wiedergeben und gleichzeitig mit dem Spracherkennungssystem erkennen lassen. Da
diese Art der Datenübergabe bidirektional funktioniert, kann man eine Spracherkennung
über Mikrofon während der Audiodatei- Wiedergabe durchführen.
Die in der Abbildung 16 punktiert dargestellten Bereiche von Abtastwerten und
Merkmalsvektoren sind gelöschte Werte. Die Abtastwerte werden in einer Reihe
abgespeichert, so wie das ganze Signal aussehen würde. Analyzer nimmt jedes Mal die
ersten 200 Werte (bei einer Abtastfrequenz von 8000 Hz) und verarbeitet diese, die
ersten 80 davon werden dann gelöscht. So kommt es zu einer Überlappung (s.
Abbildung 2 auf der Seite 8). Das wird mit dem folgenden Quellcode aus
„plugins/AsrHGH/AnalyzerHGH.cpp“ realisiert:
AudioFrame* frame1 = _inputBuffer->getFrame(200);
AudioFrame* frame2 = _inputBuffer->removeFrame(80);
Seite 37

„_inputBuffer“ ist ein Teil vom „BufferedIOAdaptor“ (wurde bei dem Start von asrApp
zugewiesen), der zweite Teil ist „_outputBuffer“. Man kann also die Daten für die
Ausgabe auch bei Analyzer angeben, soweit das sinnvoll ist. „frame1“ wird analysiert
und „frame2“ wird mit seinen 80 Werten in einem Stack („_frameContainer“) für die
weitere Verwendung abgelegt, z.B. für die Abspeicherung des aufgenommenen Signals
als eine '*.wav' Datei. Gespeichert wird nicht das komplette Eingangssignal, sondern
nur ein Teil davon, bei dem die Sprache erkannt wird, evtl. eine halbe Sekunde vor und
nach der Sprache. Ein Auszug aus „plugins/ActionsHGH/Recognize.h“ (af = audioFile):
af->open(MODE_WRITE, FMT_WAV, 1, asrApp->getAnalyzer()->getFrameContainer());
af->save(asrApp->getRecognizer()->_speechBegin,
asrApp->getRecognizer()->_speechEnd);
Die Größe vom in der Abbildung 16 dargestellten Stack für die Merkmalsvektoren kann
maximal 6 sein. Die im „ApplicationHGH“ eingesetzte Sprachdetektion, die immer
angewendet wird, arbeitet zeitversetzt. Wenn diese Komponente das Vorhandensein der
Sprache in einem Signalabschnitt erkennt, wird das erst nach 4 weiteren Abschnitten
gemeldet (falls diese auch Sprache enthalten), um sicher zu sein, dass es keine Störung
war. Damit Recognizer keine wichtigen Daten verpasst, werden diese für kurze Zeit
(~25ms * 5) aufbewahrt. Sobald Analyzer den sechsten Objekt mit Merkmalsvektoren
in den Stack schiebt, wird das erste Objekt aus dem Stack vom Recognizer entfernt. Mit
diesem Trick wurde eine Zeitversetzung realisiert.
Die Abbildung 16 zeigt, wie der Datenaustausch zwischen einzelnen Komponenten
funktioniert. Aber wie Analyzer die Daten an den Sprachdetektor übergibt, wurde nicht
gezeichnet. Das passiert mit einem Callback (s. auf der Seite 29). Um nicht jeden Schritt
mit Worten zu beschreiben, wird hier ein sehr vereinfachter Quelltext der Funktion
„AnalyzerHGH::analyze()“ angegeben:
AudioFrame* frame1 = _inputBuffer->getFrame(_frameSize); // 200 Werte nehmen
anal_cep_frame(frame1, &_featurePar);
// und analysieren
// die gewonnene Merkmale aus _featurePar zu einem Objekt kopieren,
// der im Stack für Recognizer abgespeichert werden soll
FeatureVector v(_featurePar.vector, _featurePar.vector+_featurePar.vec_size);
pushFeatures(v);
// Objekt in den Stack schieben
// die Merkmale mit Callback zum Sprachdetektor senden
this->executeCallback("estimateCallback", &_featurePar);
// "estimateCallback" ruft Funktion "NoiseEstimator::estimate()" auf
Seite 38

In diesem Quelltext wurde zum ersten Mal eine Funktion, „anal_cep_frame()“, aus den
HirschLib- Bibliotheken erwähnt, die eigentlich der Kern des Spracherkennungssystems
„ApplicationHGH“ sind. In dieser Funktion werden die Daten komplett analysiert und
die dabei gewonnene Merkmale werden im Objekt „_featurePar“ zurückgeliefert. Für
die Analyse bei einer robusten Spracherkennung soll eine Funktion mit Reduzierung der
Störgeräusche verwendet werden:
anal_cep_nr_frame(frame1, &_featurePar, &_nest_hgh);
Um die beiden Funktionen für die Merkmalsextraktion überhaupt verwenden zu
können, muss Analyzer vorher initialisiert werden („AnalyzerHGH::initialize()“):
anal_cep_init(_sampleRate, DELTA_HTK, &_featurePar);
// bzw. für eine robuste Spracherkennung:
estimate_noise_spec_init(&_nest_hgh, 256);
anal_cep_nr_init(_sampleRate, DELTA_ETSI, &_featurePar);
Der damit reservierte Speicher wird später freigegeben („AnalyzerHGH::reset()“):
anal_cep_exit(&_featurePar);
// bzw. nach einer robusten Spracherkennung:
estimate_noise_spec_exit(&_nest_hgh);
anal_cep_nr_exit(&_featurePar);
Um die rechtzeitige Initialisierung und um das abschließende Rücksetzen (einige
Komponenten initialisieren sich nach dem Rücksetzen neu) muss man sich bei der
Erstellung von Plugins nicht kümmern. Das alles wird automatisch in der Basisklasse
für Spracherkennungssysteme erledigt. Die Initialisierung von allen Komponenten wird
in „RECOGNIZE_INIT“ mit „asrApp->initialize()“ durchgeführt. Am Ende des
gesamten Spracherkennungsprozesses, wenn keine Daten mehr benötigt werden, soll
nur „asrApp“ zurückgesetzt werden. „src/ASR/ASRApplication.cpp“:
ASRApplication::reset() {
_inputAdaptor->resetBuffers();
_analyzer->reset();
_recognizer->reset();
_noiseEstimator->reset();
_adaption->reset();
_audioManager->reset();
}
Seite 39

Auf der vorherigen Seite wurde schon geschrieben, was beim Rücksetzen des
Spracherkennungssystems nach der Spracherkennung passiert, aber was dieses System
während der Spracherkennung macht, wurde noch nicht erklärt. Das kann mit der
folgenden Abbildung gemacht werden:
Abbildung 17: Sequenzdiagramm Spracherkennungssystem
Die iterative Funktion „ApplikationHGH::tick()“ wird alle 25 ms aufgerufen (vgl.
Abbildung 16 auf der Seite 36). Nach der erfolgten Analyse mit der Sprachdetektion
wird der Zustand des Sprachdetektors abgefragt. In Abhängigkeit davon, was Dieser in
Seite 40

analysierten Daten erkannt hat, nimmt er einen von insgesamt sechs möglichen
Zuständen an, die in seiner Basisklasse „VAD“ (Voice Activity Detector) unter
„include/ASR/VAD.h“ deklariert und in folgender Tabelle aufgelistet sind:
Nr Zustand Bedeutung Folgezustand
1 VAD_NO_SPEECH Keine Sprache erkannt, pause 1, 2, 6
2 VAD_SPEECH_BEGIN Anfang der Sprache erkannt, zeitversetzt 3, 5
3 VAD_SPEECH Sprache erkannt 3, 4, 6
4 VAD_SPEECH_END Ende der Sprache erkannt, pause 1
5 VAD_SPEECH_SHORT Ende der Sprache zu früh erkannt, pause 1
6 VAD_OTHER Andere Ergebnisse der Sprachdetektion 1
Falls der Sprachdetektor sich im Zustand „VAD_OTHER“ befindet, weil z.B. entweder
nur die Pause oder nur die Sprache seit zu langer Zeit erkannt wird, wird das gesamte
Spracherkennungsprozess gestoppt, um nicht in der Schleife hängen zu bleiben. Welche
Zeiten als „zu lang“ gelten sollen, ist im Konstruktor des Sprachdetektors unter
„plugins/AsrHGH/NoiseEstimator.cpp“ festgelegt, z.B. 5 Sekunden für die Vorpause
und 10 Sekunden für die Dauer der Sprache. Bei allen anderen Zuständen vom
„NoiseEstimator“ wird Erkenner nach eventueller Adaption der Muster angesprochen.
Da die Erkennung in Funktionen der HirschLib- Bibliothek durchgeführt wird, wie
übrigens alle Prozesse von Spracherkennungssystemkomponenten, und in diesen
Komponenten selbst nur die Vorbereitungen, Zwischenschritte und Auswertungen
gemacht werden, wird es hier nicht auf die Details eingegangen. Die Beschreibung von
diesen Funktionen wird bei dieser Arbeit ausgelassen. Um alle nötigen Zwischenschritte
hier zu beschreiben oder um den Quelltext darzustellen, müssen mehrere Seiten in
Anspruch genommen werden. Deshalb werden nur die Namen von verwendeten
HirschLib- Funktionen mit kurzen Kommentaren im Weiteren angegeben. Wofür genau
diese Funktionen gebraucht werden und was in diesen passiert, kann man unter
„lib/HirschLib/sources/recog“ nachsehen. Im Quellcode vom Plugin „AsrHGH“ kann
man sehen, welche Übergabeparameter dabei eingegeben werden, wie diese vorbereitet
werden und wie die Rückgabeparameter ausgewertet werden.
Genau wie Analyzer muss man auch andere Komponenten vor der Verwendung
initialisieren. Bevor der Erkennungsprozess weiter beschrieben wird, wird eine kleine
Übersicht dieser Maßnahmen gezeigt.
Seite 41

Die Initialisierung des Sprachdetektors mit „NoiseEstimator::initialize()“:
estimate_noise_init(_nest, _featurePar);
Wenn Analyzer die Funktion „NoiseEstimator::estimate()“ aufruft:
estimate_noise(_nest, _featurePar, _frameIndex);
Die Rücksetzung nach jeder erfolgten Spracherkennung, „NoiseEstimator::reset()“:
estimate_noise_exit(_nest);
Dabei wurden folgende Parameter verwendet:
_nest
_featurePar
_frameIndex
Objekt, in dem die Ergebnisse der Sprachdetektion
zurückgegeben werden, z.B. der Zustand
Objekt mit Merkmalen, die Analyzer erzeugt
Nummer des aktuellen Signalabschnittes
Die Initialisierung der Adaption mit „AdaptionHGH::initialize()“ (Syntaxfile benötigt):
adapt_hmm_all_init(&_adaptionData, _featurePar, _originalReferences, MSF);
adapt_hmm_all_set(&_adaptionData, _originalReferences);
adapt_hmm_all_reset(&_adaptionData, _syntax);
„AdaptionHGH::adapt()“ beim Zustand „VAD_SPEECH_BEGIN“:
adapt_copy_noise_spec(&_adaptionData, _nest);
adapt_copy_pars(&_adaptionData, _originalReferences);
adapt_hmm_all_doit(&_adaptionData, _originalReferences);
_owner->getRecognizer()->setReferences(_adaptionData.ref_adapt);
extract_c0_ref(_adaptionData.ref_adapt, _featurePar->ncep4);
In der Funktion „AdaptionHGH::adapt()“ beim Zustand „VAD_SPEECH“ werden die
Ableitungen des nullten Koeffizienten aus dem Vektor entfernt und der Koeffizient
selbst wird auf das Ende des Vektors verschoben:
C1 ... C12 C0 E ... ΔC12 ΔC0 ΔE ... ΔΔC12 ΔΔC0 ΔΔE ...
C1 ... C12 E ... ΔC12 ΔE ... ΔΔC12 ΔΔE ...
C0
Seite 42

Als Weiteres wird Adresse des Vektors an die HirschLib- Funktion übergeben:
adapt_hmm_all_buf_spec(&_adaptionData, &(fb->front())[0], MSF, _frameIndex);
Bei einem Callback vom Recognizer, „AdaptionHGH::adaptionCallback()“:
adapt_hmm_all_estim_h(&_adaptionData, _originalReferences, dataHGH->bestPath,
_syntax, dataHGH->viterbiData, dataHGH->nvec);
adapt_hmm_all_t60(&(dataHGH->results), _originalReferences, _syntax,
&_adaptionData, _nest, dataHGH->nvec);
Beim Entfernen des Objektes im Destruktor, „AdaptionHGH::reset()“:
adapt_hmm_all_exit(&_adaptionData, MSF);
Dabei wurden folgende Parameter verwendet:
_adaptionData
_featurePar
_originalReferences
MSF
_syntax
_nest
fb->front()
_frameIndex
dataHGH
Objekt, in dem die Ergebnisse der Adaption
zurückgegeben werden, z.B. adaptierte Modelle
Objekt mit Merkmalen, die Analyzer erzeugt
die vom Recognizer eingelesene unbearbeitete Modelle
MaxSpeechFrames, maximale Anzahl von Abschnitten mit
Sprache, 1000 bei 10 Sekunden (s. vorletzte Seite)
geladene Daten aus der Syntax- Datei
Objekt mit Ergebnissen der Sprachdetektion
der erste Merkmalsvektor im Stack für Recognizer
Nummer des aktuellen Signalabschnittes
Daten vom Recognizer nach erfolgreicher Erkennung
Die Initialisierung vom Recognizer läuft etwas anders ab. Dabei werden nur die HM-
Modelle eingelesen. Erst bei dem Start vom Spracherkennungssystem wird auch die
Syntax- Datei geladen (falls diese Datei schon beim letzten Start geladen wurde,
passiert das nicht noch einmal, um etwas Zeit zu sparen).
_references = load_hmm(Pfad);
_syntax = load_syn(Pfad, _references);
Erst jetzt kann auch die Adaption initialisiert werden. Im Kapitel 3.2.1 wurde
geschrieben, dass Recognizer nur dann startet, wenn der Sprachdetektor die Sprache
erkennt. In Wirklichkeit läuft „RecognizerHGH“, wie die anderen Komponenten, immer
Seite 43

mit. Dabei rechnet er aber nichts aus und sorgt nur noch dafür, dass die Größe vom
Stack mit Merkmalsvektoren nicht größer als 5 ist. Erst wenn der Sprachdetektor den
Zustand „VAD_SPEECH_BEGIN“ annimmt, werden die Objekte für die Berechnungen
vom Viterbi- Algorithmus und vom besten Pfad initialisiert (s. Kapitel 3.2.3).
Funktion „RecognizerHGH::process()“ bei dem Zustand „VAD_SPEECH_BEGIN“:
viterbi_syn_init(_viterbi, _references, _syntax);
viterbi_syn_set(_viterbi, _references);
viterbi_syn_reset(_viterbi, _references, _syntax);
best_path_init(_bestPath, _references, _syntax, MaxSpeechFrames);
Im Zustand „VAD_SPEECH“ wird der aufwendige Viterbi- Algorithmus mit der
Bestimmung des besten Pfades für die Mustererkennung angewendet.
viterbi_syn_calc(&(_fb.front())[0], _viterbi, _references, _syntax, 0,
_speechFrame);
best_path_copy(_bestPath, _references, _syntax, _viterbi, _speechFrame);
Nachdem ein Merkmalsvektor aus dem Stack mit Viterbi- Funktion verarbeitet wurde,
wird geprüft, welche Modelle in diesen Merkmalen erkannt wurden. Falls es sich um
die Modelle für die Pause oder Störung handelt, wird der Pausen- Zähler inkrementiert.
Andernfalls wird der zugehörige Signalabschnitt als ein Abschnitt mit der Sprache
anerkannt. Wenn der Zähler für die „leere“ Abschnitte einen bestimmten, in der Syntax-
Datei festgelegten Wert erreicht hat, nachdem mindestens ein Sprachabschnitt anerkannt
wurde, wird es bei allen bisherigen Ergebnissen zusammen mit der folgenden Funktion
geprüft, ob eine sinnvolle Erkennung doch vorhanden sein könnte:
res_syn = backtrack_viterbi_score(bestref, fromframe, _viterbi, _bestPath,
_syntax, _references, _speechFrame);
Falls „res_syn“ mindestens ein Model enthält, das weder der Pause noch der Störung
gehört, werden alle Ergebnisse mit der Funktion „RecognizerHGH::recognize()“
ausgewertet und das gesamte Spracherkennungsprozess abgebrochen, weil das Ende der
Sprache vom Recognizer erfolgreich erkannt wurde.
Dasselbe passiert, wenn der Sprachdetektor als Erster das Ende der Sprache erkannt hat
und in den Zustand „VAD_SPEECH_END“ gewechselt hat. Falls aber „res_syn“ kein
für die Spracherkennung sinnvolles Model enthält oder sogar kein Signalabschnitt als
Sprache vom Recognizer erkannt wurde, wird alles sofort zurückgesetzt:
Seite 44

viterbi_syn_exit(_viterbi, _references, _syntax);
best_path_exit(_bestPath, _syntax, MaxSpeechFrames);
Diese Funktionen werden auch bei allen verbleibenden Zuständen aufgerufen.
Es kann auch sein, dass das Spracherkennungssystem von Außerhalb gestoppt wurde,
weil z.B. die zu erkennende Audiodatei zu Ende abgespielt wurde oder der
Sprachdetektor in den Zustand „VAD_OTHER“ gewechselt hat, Recognizer aber einige
sinnvolle Ergebnisse ausgerechnet hat und nicht geschafft hat, diese auszuwerten. Um
die Verluste von Ergebnissen auszuschließen, wartet das System in dessen Funktion
„ASRApplication::stop()“ bis Recognizer fertig ist, „RecognizerHGH::wait()“:
void RecognizerHGH::wait()
{
if (!_speech_detected && _speechFrameDetected)
recognize();
}
Mit „_speech_detected“ wird geprüft, ob das Ende der Sprache vielleicht doch richtig
erkannt wurde und die Ergebnisse ausgewertet wurden, um die doppelte Auswertung zu
vermeiden. Falls das nicht der Fall ist und in mindestens einem Signalabschnitt die
Sprache erkannt wurde, wird die Funktion „RecognizerHGH::recognize()“ aufgerufen:
_realResults = backtrack_viterbi_syn(bestref, fromframe, _viterbi, _syntax,
_references, _speechFrame);
best_path_calc(_bestPath, _references, _syntax, _viterbi, _speechFrame);
Alle berechneten Objekte werden in „dataHGH“ gepackt und an Adaption als Callback
gesendet (s. Seite 43, oben). „_realResults“ enthält alle Informationen über die
erkannten Äußerungen und wird in der Funktion „RecognizerHGH::saveLabel(Pfad)“
für das Abspeichern von Labeln verwendet.
create_label(Pfad, &_realResults, _references, _syntax);
Nachdem das Spracherkennungssystem „ApplicationHGH“ erfolgreich beendet aber
noch nicht zurückgesetzt wurde, kann Funktion „RecognizerHGH::processResults()“
aufgerufen werden, die nur die Namen der erkannten Wortmodellen zurückliefert, ohne
diesen der Modellen für die Pause und Störung. Das passiert z.B. in der Funktion
„Recognize::startThread()“, in denen alle Schnittstellen wie Spracherkennungssystem,
„audioFrontend“, DC-Filter usw. aneinander angepasst, gestartet und beendet werden.
Seite 45

Nach der Darstellung des Plugins „AsrHGH“, nach der Erläuterung der Einsatzmöglichkeiten
von Actionen aus dem Plugin „ActionsHGH“, nach der Beschreibung der
Funktionsweise des Spracherkennungssystems „ApplicationHGH“ und nach der
Auflistung von allen bei diesem System verwendeten HirschLib- Funktionen kommen
wir endlich auf die Frage zur parallelen Spracherkennung zurück.
Bei der Arbeit am asrLib- Projekt wurde ein sehr großer Wert darauf gelegt, die
möglichst universell einsetzbaren Bibliotheken zu erzeugen und deren Benutzern eine
Möglichkeit zu geben, nicht nur verschiedene Spracherkennungssysteme mit vielseitiger
Anwendung ohne großen Aufwand zu erstellen, sondern auch diese miteinander nach
Belieben kombinieren zu können. Ein Beispiel für einen möglichen
Spracherkennungsprozess bei einer Kombination aus mehreren Spracherkennungssystemen
ist in der Abbildung 18 gegeben, vgl. mit der Abbildung 16 auf der Seite 36.
Wie man sieht, gibt es hier nur eine Schnittstelle für die Kommunikation mit der
Soundkarte, dafür aber zwei Analyzer und gleich 4 Recognizer.
alle 25 ms
Signalabschnitte
0 1 2 3 4 5 6 ...
SoundcardFrontend::
paCallbackFun()
Signalabschnitte
0 1 2 3 4 5 6 ...
BufferedIOAdaptor::tick()
Abtastwerte
Abtastwerte
AnalyzerHGH::analyze()
AnalyzerHGH::analyze()
0 1 2 3 4 5 0 1 2 3 4 5
0 1 2 3 4 5 0 1 2 3 4 5
Merkmalsvektoren
Merkmalsvektoren
RecognizerHGH::process()
RecognizerHGH::process()
RecognizerHGH::process()
RecognizerHGH::process()
Abbildung 18: Möglicher Verlauf einer parallelen Spracherkennung
Seite 46

Wir haben hier also 4 Spracherkennungssysteme. Wie im Kapitel 3.2.1 geschrieben
wurde, muss ein Spracherkennungssystem aus mindestens zwei Komponenten bestehen:
Analyzer und Erkenner. Genau wie ein AudioManager auf der Seite 34 können alle
Komponente eines Systems dem anderen zugewiesen werden. Wie schon oben
geschrieben, kann man bei einem Analyzer die Callbacks für mehrere Sprachdetektoren
registrieren. Für den Datenaustausch zwischen Analyzer und Recognizer (und somit der
Adaption) werden die Stacks für Merkmalsvektoren registriert.
_analyzer1->registerCallback("estimateCallback", cb1);
_analyzer1->registerCallback("estimateCallback", cb2);
_analyzer1->registerFeatureBuffer(_recognizer1->getFeatureBuffer());
_analyzer1->registerFeatureBuffer(_recognizer2->getFeatureBuffer());
Es gibt also fast keine Grenzen. Man kann verschiedene Spracherkennungssysteme mit
beliebiger Struktur erstellen und für eine gleichzeitige, oder parallele, Spracherkennung
einsetzen. Es gibt aber eine einzige Voraussetzung: die Daten, die von den kombinierten
Komponenten bearbeitet werden, müssen zueinander passen. Man darf nicht einen
Erkenner, der für eine robuste Erkennung erstellte Muster geladen hat, mit einem
Analyzer kombinieren, deren Merkmalsvektoren nicht dafür vorgesehen wurden. Man
muss auch auf die Frequenzen achten. Bei der Erstellung von solchen
Spracherkennungssystemen (oder bei deren Initialisierung oder Start) muss man schon
überlegen, wie man deren Komponente am Besten kombinieren soll und welche Art von
Daten für die Spracherkennung verwendet wird.
Plugins „AsrHGH“, für ein Spracherkennungssystem, und „ActionsHGH“, für dessen
Actionen, wurden für den Einsatz von kompletten Spracherkennungssystemen gedacht,
also ohne Kombinationen. Man kann verschiedene Varianten von „ApplicationHGH“ in
„RecognizeInit“ erstellen und in „Recognize“ starten. Dabei können maximal 10
Systeme gleichzeitig ausgeführt werden, jedes von denen wie in der Abbildung 16
strukturiert ist. Weil diese Systeme unabhängig voneinander laufen, können die beliebig
konfiguriert werden (z.B. beliebige zulässige Frequenzen).
Um zu sehen, wie eine parallele Erkennung funktioniert, vertiefen wir uns in den
Quellcode der Klasse „Recognize“ unter „plugins/ActionsHGH/Recognize.h“.
Als Erstes werden alle in der Konfigurationsdatei eingegebenen Parameter eingelesen
(s. Seite 32). Mit Parameter „SM_BUTTON“ wird Funktion „Recognize::
waitForButton()“ als ein Thread (selbständiger, paralleler Prozess) gestartet, die in einer
„ewigen“ Schleife den Zustand des parallelen Ports des Rechners prüft. Falls der Knopf
Seite 47

am Infokasten, der mit diesem Port verbunden ist, betätigt wird, wird die Variable
„_breakAction“, die standardmäßig „0“ ist, auf „1“ gesetzt (das Abbrechen der
Erkennung von Außen erzwingen) und die Funktion wird verlassen. Was bei dem
Parameter „SM_GUI“ passiert, wird im nächsten Kapitel geschrieben.
Bei jedem Parameter, der mit „M_“ anfängt (Zeichen für ein Spracherkennungssystem),
wird die Funktion „Recognize::startThread()“ als ein neuer Thread gestartet. Also wenn
auch nur noch ein Spracherkennungssystem vorhanden ist, wird der Erkennungsprozess
als ein separater Prozess ausgeführt.
for (nrOfThread = 0; nrOfThread < 10; nrOfThread++)
if (_parameterVector[count].substr(0,2) == "M_")
pthread_create(&thread[nrOfThread], NULL, startThread, (void*) this);
else
beak;
Nachdem alle Threads gestartet wurden, wird einfach gewartet, bis „_breakAction“
einen von „0“ abweichenden Wert annimmt oder bis alle Threads beendet wurden.
Weitere Beschreibung gilt für alle parallel laufenden Spracherkennungsprozesse.
In der Funktion „Recognize::startThread()“ wird zuerst das aktuelle Spracherkennungssystem
„asrApp“ geladen und im Vektor „_asrAppContainer“ abgelegt. Dann wird die
als Parameter übergebene Syntaxdatei eingelesen, falls das noch nicht geschehen ist:
asrApp->getRecognizer()->initSyntax(_syntaxFile);
Falls die Erkennung mit der Adaption erfolgen soll, wird diese initialisiert:
asrApp->getAdaption()->initialize();
Beim ersten Aufruf vom aktuellen System wird „audioFrontend“ (ISDN_FRONTEND
oder SOUNDCARD_FRONTEND, s. Seiten 34 - 36) erstellt und als Property im
„asrApp“ gespeichert, andernfalls wird „audioFrontend“ aus Property geladen.
if (asrApp->getProperty("AudioFrontend") == NULL) {
if (StateMachine::getInstance()->getProperty("ISDN_FRONTEND")) {
audioFrontend = sm->getProperty("ISDN_FRONTEND")->get();
asrApp->addProperty("AudioFrontend", audioFrontend);
}
else {
audioFrontend = new SoundcardFrontend();
audioFrontend->setAudioManager(asrApp->getAudioManager());
audioFrontend->initialize();
asrApp->addProperty("AudioFrontend", audioFrontend);
}
}
Seite 48

Falls eine Audiodatei als Parameter eingegeben wurde, wird diese als Datenquelle
gesetzt (s. Quelltext auf der Seite 37). Andernfalls ist „audioFrontend“ die Datenquelle:
asrApp->getInputAdaptor()->getInput(0)->setSource(audioFrontend->getOutput(0))
Nachdem alle Komponente (Audiodatei, DC-Filter, „audioFrontend“ und „asrApp“)
gestartet wurden, läuft alles ab, wie oben in diesem Kapitel beschrieben wurde. Es wird
in der Funktion „ASRApplication::start()“ auf das Ende der Spracherkennung gewartet.
Wenn „asrApp“ gestoppt wird, weil: die Audiodatei zu Ende ist; das Ende der Sprache
vom Erkenner erkannt wurde; der Sprachdetektor in den Zustand „VAD_OTHER“
gewechselt hat; das parallel laufende Spracherkennungssystem etwas erkannt hat; die
Spracherkennung von Außen unterbrochen wurde, dann werden alle noch laufenden
Komponente gestoppt und die gesetzten Quellen entfernt.
audioFrontend->stop();
audioFrontend->getInput(0)->setSource(NULL);
if (audioFrontend->getInput(1))
audioFrontend->getInput(1)->setSource(NULL);
dcblocker->stop();
asrApp->getInputAdaptor()->getInput(0)->setSource(NULL);
Falls die Spracherkennung von Außen unterbrochen wurde (_breakAction = 1), wird
das gesamte Spracherkennungssystem mit allen seinen Komponenten zurückgesetzt und
Funktion „Recognize::startThread()“ wird verlassen, der aktuelle Thread wird beendet.
asrApp->reset();
In allen anderen Fällen werden die möglichen Ergebnisse des Erkenners ausgewertet:
asrApp->getRecognizer()->processResults();
std::vector results = asrApp->getRecognizer()->getResults();
Wenn „results“ leer ist, wird „asrApp“ zurückgesetzt, wenn nicht, wird „_breakAction“
den Wert „2“ annehmen als Zeichen dafür, dass etwas erkannt wurde.
Zurück zur „Recognize::execute()“. Alle noch laufende Spracherkennungssysteme
werden gestoppt und es wird noch gewartet, bis alle Threads beendet wurden.
for (int j = 0; j < (int)_asrAppContainer.size(); j++)
_asrAppContainer.at(j)->stop();
for (int j = 0; j < nrOfThread; j++)
pthread_join(thread[j], NULL);
Seite 49

Falls „_breakAction“ den Wert 0 hat (keines von Spracherkennungssystemen hat etwas
erkannt und auch keine Unterbrechung von Außen), wird „SM_TIMEOUT“ als
Ergebnis der Action „Recognize“ zurückgegeben (bei drei nacheinander folgenden
„SM_TIMEOUT“ wird „SM_MAX_TIMEOUT“ ausgegeben). Alle Systeme wurden
also schon vorher zurückgesetzt, muss nur noch „_asrAppContainer“ geleert werden.
Bei „_breakAction“ = 2 werden die Ergebnisse eines der Spracherkennungssysteme als
Rückgabe der Action „Recognize“ genommen (evtl. als Buffer, s. Kapitel 5.5):
this->setResult(results.front());
Bevor „asrApp“ zurückgesetzt und „_asrAppContainer“ geleert werden, können noch
die gewonnenen Daten abgespeichert werden, z.B. die aufgenommene Sprachäußerung
als eine Audiodatei (s. Seite 38, oben) oder die Labels (s. Seite 45, unten).
Das war eine oberflächliche Beschreibung der parallelen Erkennung ohne der
Berücksichtigung von allen möglichen Sicherheitsabfragen und kleinen Details. Wenn
man den Quellcode von „Recognize“ anguckt, sieht man, dass ein großer Teil des
Quellcodes aus diesen Abfragen und aus dem Setzen und Entfernen von Mutex besteht.
Wenn man mit parallelen Prozessen arbeitet (bei „asrLib“ wird eine große Menge davon
erzeugt), muss man darauf achten, dass auf ein Objekt zur gleichen Zeit aus
verschiedenen Prozessen zugegriffen werden kann. Wenn man keine Maßnahmen
vornimmt, könnte es zu einem Absturz der Applikation führen. Deshalb sollte man
solche Objekte mit Mutex schützen. Ein Prozess, das auf ein Objekt oder auf eine
Funktion zugreifen möchte, sperrt Mutex. Der nächste Prozess wartet, bis Mutex
entsperrt wird, dabei kann eine große „Schlange“ entstehen. Mutex soll global entweder
in einer Klasse oder in einem Namensraum oder sogar im gesamten Projekt deklariert
werden. Mutex wird auf mehreren Stellen im gesamten asrLib- Projekt zum Schutz von
vielen Objekten verwendet. Auch die Konsolenausgabe wird geschützt, wie in diesem
Beispiel aus „plugins/ActionsHGH/Recognize.h“:
// globale Deklaration im Namensraum „actionsHGH“
static pthread_mutex_t mutex_report_recognize = PTHREAD_MUTEX_INITIALIZER;
// Anwendung in den Funktionen
pthread_mutex_lock(&mutex_report_recognize);
std::cout

7. GUI
Die graphische Oberfläche ist ein Bestandteil des multimodalen Dialogsystems. Das ist
eine zusätzliche, in dieses System integrierte Applikation, die auf FLTK der Version 2.0
basiert und parallel zur StateMachine (Kapitel 5) läuft. Die beiden Komponenten
werden von einer Schnittstelle gestartet, die Controller genannt wird, und über die diese
miteinander auch kommunizieren können. Controller ist ein Objekt der von
„asrlib::GUIController“ abgeleiteten Klasse, das in der Hauptfunktion erstellt werden
soll. Jede graphische Oberfläche muss ihren eigenen Controller haben, der deren
Verhalten bestimmt und entscheidet, was passieren soll, wenn z.B. ein Button (= Taste
oder Schaltfläche) betätigt wird. Die Klasse des Controllers soll zusammen mit anderen
Klassen von allen GUI- Komponenten als Plugin erstellt werden, das beim Aufruf eines
Dialogsystems als Parameter übergeben wird. Eine Beschreibung von diesem Aufruf ist
im Kapitel „Plugins“ auf der Seite 25 gegeben. Die Applikation „GuiApp“ ist extra für
die Arbeit mit den graphischen Oberflächen gedacht und kann beliebige Plugins laden.
Eins von denen muss unbedingt ein GUI- Plugin sein. Der etwas vereinfachte Quellcode
der Hauptfunktion dieser Applikation unter „applications/GuiApp/GuiApp.cpp“ zeigt
die notwendigen Schritte für den Start eines Dialogsystems mit GUI:
int main()
{
StateMachine* sm = StateMachine::getInstance();
sm->setDataPath("../../data");
PluginFactory::get()->loadLibrary(sm->getDataPath()+"/Actions.so");
PluginFactory::get()->loadLibrary(sm->getDataPath()+"/"+ASRActions);
PluginFactory::get()->loadLibrary(sm->getDataPath()+"/"+PluginGUI);
asrlib::StatReader* statReader = new asrlib::StatReader();
if(!statReader->initStateMachine(StatFile, sm))
return 0;
GUIController* myController = dynamic_cast
(PluginFactory::get()->create("GUIController"));
myController->start();
};
sm->destroy();
delete statReader;
delete myController;
return 0;
Plugin „Actions.so“ mit allgemeinen Actionen für StateMachine (s. Tabelle auf der
Seite 28) wird immer automatisch geladen. Nachdem auch das gewünschte Plugin mit
Seite 51

GUI geladen wurde, kann sein Controller mit „GUIController“ aufgerufen werden. Im
Rahmen dieser Masterarbeit wurden zwei GUI- Plugins erstellt, deren Quellcode unter
„plugins/GuiFKA“ und „plugins/GuiPHA“ zu finden ist. „GuiFKA“ wurde für die
graphische Darstellung eines Fahrkartenautomaten geschrieben, der in diesem Kapitel
dargestellt wird. Sein Controller ist die Klasse „FKAController“. Mit „PHAController“
wird die graphische Oberfläche des Parkhausautomaten aus „GuiPHA“ gesteuert.
Damit beliebige Controller in der Hauptfunktion, wie im Quellcode auf der vorherigen
Seite, erstellt werden können, müssen deren Namen in „export.cpp“ übersetzt werden:
POCO_EXPORT_NAMED_CLASS(FKAController,GUIController)
Bevor wir uns mit dem Fahrkartenautomaten beschäftigen, soll die Basis- Bibliothek
„libGUI.so“ dargestellt werden, deren Quellcode sich unter „include/GUI“ befindet und
aus drei Headerfiles besteht: „Windows.h“, „Widgets.h“ und „GUIController.h“.
Die Klasse „asrlib::Windows“ wurde aus „asrlib::Base“ abgeleitet und ist eine abstrakte
Basisklasse für die Verwaltung von allen „Graphical User Interfaces” des „asrLib“-
Projektes. So ein GUI mit allen seinen Komponenten, zu denen alle Buttons, Bilder,
Ein- und Ausgabefelder und natürlich das Fenster selbst gehören, ist hier dargestellt:
Abbildung 19: Fahrkartenautomat
Seite 52

Alle GUI- Objekte werden also in der Klasse „asrlib::Windows“ verwaltet. Erstellt
müssen diese in der abstrakten Funktion „make_window()“ in den abgeleiteten Klassen.
Dabei soll im Kapitel 4.1 beschriebenes FLTK- Tool „FLUID“, das für die Erstellung
von graphischen Oberflächen gedacht ist, mit der Projektdatei „prototyp.fl“ unter
„plugins/GuiPrototyp“ verwendet werden, die extra für die von „asrlib::Windows“
abgeleitete Klassen vorbereitet wurde und als Prototyp für alle FLUID- Projekte dienen
kann. In dem geladenen Projekt soll man den Namen der Klasse ändern und die
gewünschten Objekte in „make_window()“ erstellen. Die Erstellung selbst ist ganz
einfach, wie man an Beispielen im Kapitel 4.1 sieht. Das Einzige, was man beachten
soll, ist, dass FLUID nicht mit relativen Pfaden arbeiten kann. Wenn man ein Bild ins
Projekt geladen hat (was übrigens mit dem „Widget“- Objekt gemacht werden kann),
wird dieses mit dem absoluten Pfad in der Projektdatei und im Quellcode gespeichert.
Bevor man den Quelltext kompiliert, sollen diese Pfade mit relativen Pfaden oder mit
dem ähnlichen Quelltext ersetzt werden:
asrlib::StateMachine* sm = asrlib::StateMachine::getInstance();
o->image(fltk::SharedImage::get(sm->getDataPath()+"/Images/50.jpg");
Das Fenster, das wir in der Abbildung 19 sehen, ist nicht das „Windows“ Objekt,
sondern nur sein Bestandteil. Ein „Windows“ Objekt kann gleich mehrere Fenster
enthalten, soweit das sinnvoll ist. Das Hauptfenster wird „_ownWindow“ zugewiesen.
Jedes zusätzliche Fenster soll nach seiner Erstellung in einer dafür vorgesehenen Map
mit seinem Namen abgespeichert werden, damit es später angesprochen werden kann:
_ownWindow = o;
insertWindow(o, "Zusätzliches Fenster");
// Hauptfenster setzen
// Nebenfenster speichern
Das soll auch mit allen anderen GUI- Objekten passieren, deren Zustand während der
Ausführungsphase durch den Benutzer (bzw. durch StateMachine) geändert werden
kann. Das sind z.B. fast alle Buttons und Ein- und Ausgabefelder. Falls mehrere
Objekte gleich behandelt werden sollen, wie z.B. das Ausblenden der ganzen Tastatur in
der Abbildung 19, können diese in einer Gruppe („fltk::Group“) erstellt werden, die in
der Map abgelegt wird und bei Bedarf daraus mit ihrem Namen aufgerufen wird:
insertGroup(fltk::Group* group, std::string name)
std::string getGroup(fltk::Group *group)
fltk::Group* getGroup(std::string name)
// in der Map ablegen
// Name ausgeben
// aus der Map holen
Seite 53

Um den Benutzer bei der Erstellung von solchen GUI- Objekten, wie die oben erwähnte
Tastatur, etwas zu entlasten, wurden in „include/GUI/Widgets.h“ einige Klassen für die
Gruppen fertiggestellt. Man erstellt ein Gruppen-Objekt in FLUID und ersetzt
„fltk::Group“ mit der Klasse „asrlib::KeyboardDeuGroup“ für eine fertige Tastatur mit
deutschem Layout. Man setzt nur die gewünschte Größe der Gruppe, die Größe und
Schrift von jedem Button werden automatisch durch die Berechnungen im Quellcode
angepasst. Diese Tastatur ist erstmal nicht sichtbar, weil die nicht mit FLUID erstellt
wurde. Erst nach der Kompilation wird diese während der Ausführung erstellt. Eine
weitere fertige Gruppe von GUI- Objekten ist die Klasse „asrlib::CalendarGroup“, mit
der man einen deutschen Kalender hat, dessen Größe sich ebenfalls dynamisch anpasst.
Abbildung 20:
GUI-Kalender
Die Basisklasse von beiden oben erwähnten Klassen ist „asrlib::OwnGroups“, die
ihrerseits von der Klasse „fltk::Group“ abgeleitet wurde und einige neue Funktionen zur
Verfügung stellt, z.B. zwei Funktionen zur unterschiedlichen Bearbeitung von Button-
Callbacks. Wenn ein Ereignis beim Betätigen des Buttons für die Auswahl des Monats
in der obigen Abbildung auftritt, soll dieses intern im Kalender bearbeitet werden. Nur
die Nachrichten von die Kalendertage repräsentierenden Buttons werden nach draußen
verschickt. Bei den meisten Schaltflächen reicht es aus, wenn deren Beschriftung als
Information in den Nachrichten gesendet wird, z.B. „OK“ oder „Abbrechen“. Damit
kommt man bei diesem Kalender nicht aus. Es ist in der Klasse „fltk::Button“ nicht
vorgesehen, irgendwelche zusätzliche Information abzuspeichern. Deshalb werden die
Tasten in den graphischen Oberflächen des asrLib- Projektes als Objekte der eigenen
Klasse „asrlib::OwnButton“ erstellt, die erlaubt, zusätzliche Information vom Typ
„std::string“ mit der Funktion „setData(std::string data)“ anzulegen und diese mit
„getData()“ abzufragen. Alle von Buttons gesendete Ereignisse werden mit der
Seite 54

Funktion „Windows::callbackButton()“ abgefangen. So könnte der Verlauf eines
Ereignisses beim Betätigen des Buttons „21“ in der Abbildung 20 vereinfacht aussehen:
o->setData(Tag+"."+Monat+"."+Jahr);
_owner->callbackButton(o, (void*)(o->getData());
// Information speichern
// Information senden
„_owner“ ist ein Objekt der von „asrlib::Windows“ abgeleiteten Klasse, dem die
Kalender- Gruppe hinzugefügt wurde. Für Buttons, die in FLUID erstellt wurden, muss
dieses Objekt nicht eingegeben werden. Die abgefangenen Nachrichten werden als
Callbacks, die uns aus dem Kapitel 5.5 bekannt sind, zum Controller gesendet.
void callbackButton(fltk::Widget* button, void* data)
{
this->executeCallback("callbackButton", data);
};
Controller ist eine Schnittstelle zwischen dem „Windows“- Objekt (und allen seinen
Komponenten) und StateMachine. Die Basisklassen für alle solche Controller ist
„asrlib::GUIController“. Nach dem Start vom Controller werden zuerst alle Standard-
Callbacks für die grundlegende Steuerung von GUI- Objekten, z.B. zum Aktivieren
oder Deaktivieren von Buttons oder selbst zum Starten von GUI, automatisch mit
„registerOwnCallbacks()“ registriert, damit diese später von beliebiger Stelle zu jeder
Zeit gesendet werden können. Alle von diesen Callbacks aufzurufenden Funktionen,
außer „updateFromSM()“, befinden sich unter „include/GUI/GUIController.h“. Die
abstrakte Funktion „updateFromSM()“, die mit dem oben genannten Callback für
irgendwelche, vom Benutzer definierte Aufgaben von StateMachine aufgerufen wird,
soll in der abgeleiteten Klasse erstellt werden. Dazu kommen wir etwas später.
CallbackBuffer::getInstance()->registerCallback("startGUI",
new Callback(this, &GUIController::startGUI));
Nach der Registrierung von allen Callbacks wird StateMachine initialisiert und in einem
Thread parallel zur laufenden Applikation gestartet. Nachdem auch GUI gestartet wurde
(dazu später, Seite 58), kommt es zu einer endlosen Schleife, „GUIController::start()“:
while (1) {
updateController();
pthread_mutex_lock(&mutex_redraw);
fltk::check();
pthread_mutex_unlock(&mutex_redraw);
usleep(10000);
}
// abstrakte Funktion für irgendwas
// Ereignisse prüfen und abarbeiten
Seite 55

Mit der Funktion „updateController()“ kann man festlegen, was alle 10 Millisekunden
passieren soll. Bei „FKAController“ wird diese Funktion für die Ausgabe vom Datum
mit Zeit verwendet, wie in der Abbildung 19, unten. Wie man im oberen Quellcode
sieht, wird auf der Seite 50 beschriebenes Mutex auch hier eingesetzt. Wenn das
Aussehen des aktuellen Fensters geändert werden soll, z.B. wegen der Deaktivierung
eines Buttons, soll dieses Fenster mit „redraw()“ neu gezeichnet werden. Da die meisten
solchen Änderungen durch den Aufruf von entsprechenden Funktionen mit Callbacks
von StateMachine durchgeführt werden, wird die Funktion „redraw()“ parallel zu
„check()“ ausgeführt. Wenn die beiden Funktionen sich überschneiden, wird das Fenster
nicht korrekt dargestellt, deshalb soll Mutex bei diesen verwendet werden.
Jetzt wissen wir, wie man eine graphische Oberfläche erstellt, wie diese mit dem
Controller kommuniziert und was man bei Callbacks von StateMachine beachten soll.
Nun kommen wir zum Teil dieses Kapitel, in dem erklärt wird, wie eine graphische
Oberfläche überhaupt gestartet wird und wie genau eine Kommunikation zwischen dem
Controller und StateMachine abläuft. Dazu betrachten wir folgende Abbildung und
nehmen Action „TRANSCEIVER“ aus der Tabelle auf der Seite 28 „unter die Lupe“.
start()
myController:
GUIController*
startSM()
sm:
StateMachine*
„createWindow“
createWindow()
„GUI_OK“
_currentWindows:
asrlib::Windows*
make_window()
_mainWindow:
fltk::Window*
„startGUI“
startGUI()
„GUI_OK“
show()
callbackButton()
„callbackButton“
„ … “
Abbildung 21: Kommunikation zwischen GUI und StateMachine
Seite 56

Zuerst wird der Controller gestartet, wie in der „main()“- Funktion auf der Seite 51
dargestellt. Weil dieser Controller ein Objekt der von „asrlib::GUIController“
abgeleiteten Klasse ist, wird zuerst ihre Start- Funktion ausgeführt (in dem Beispiel mit
dem Fahrkartenautomat ist das „FKAController::start()“), die ihrerseits die oben
beschriebene Funktion der Basisklasse aufruft, nachdem alle in der Basisklasse
fehlenden Callbacks mit der abgeleiteten Funktion „registerOwnCallbacks()“ registriert
wurden. Diese Callbacks sind spezielle Nachrichten des Fahrkartenautomaten. In der
Abbildung 19 dargestelltes Fenster hat mehrere Felder für die Textausgabe. Für jedes
Ausgabefeld, dessen Inhalt von StateMachine bestimmt wird, soll ein eigenes Callback
registriert werden. Die entsprechende Funktionen erstellt man in der abgeleiteten
Controller- Klasse. Das Setzten des gewünschten Inhaltes wird wie folgt realisiert:
GUIController::setOutput(NameVomAusgabefeld, Inhalt);
Nachdem StateMachine gestartet wurde, wird die Konfigurationsdatei für Dialogsystem
abgearbeitet. Für die Kommunikation mit dem Controller wird die Action der Klasse
„asrActions::Transceiver“ eingesetzt. Als Erstes soll jedes „Windows“- Objekt erstellt
werden, dessen Fenster beim aktuellen Dialogsystem angezeigt werden sollen. Wie
schon oben geschrieben wurde, soll jedes „Windows“- Objekt ein Hauptfenster haben
und kann mehrere Nebenfenster enthalten. Bei unserem Beispiel mit dem Fenster vom
Fahrkartenautomat in der Abbildung 19 ist dieses Objekt „FKA_deu“.
create_window_fka_deu
TRANSCEIVER
4 SM_SEND FKA_deu createWindow SM_RECEIVE
1 GUI_OK
start_window_fka_deu
exit
Statt diesen Auszug aus der Konfigurationsdatei zu erklären, wird eine allgemeine
Beschreibung der Action „TRANSCEIVER“ hier gegeben:
TRANSCEIVER
[SM_SEND ] | [SM_RECEIVE [] ]
Das Schlüsselwort für das Senden von Nachrichten
Die Information, die gesendet werden soll
Der Name vom Callback, mit dem gesendet werden soll
Das Schlüsselwort für den Empfang von Nachrichten
Ein Speicher für die empfangene Nachrichten, optional
Seite 57

Das Senden und das Empfangen kann man beliebig kombinieren und beliebig oft in
einer einzigen Action einsetzten.
Die Erstellung vom „Windows“- Objekt mit allen seinen Komponenten kann einige Zeit
in Anspruch nehmen, deshalb sollten alle Objekte, die benutzt werden, noch vor dem
Start des ersten Objektes erstellt werden. Dabei werden diese in einem Stack abgelegt.
Ein Auszug aus „GUIController::createWindow()“:
Windows* myWindows =
dynamic_cast(PluginFactory::get()->create(name));
myWindows->make_window();
_allWindows.insert(std::pair(name, myWindows));
Nachdem „Windows“- Objekt erstellt wurde, kann es genauso mit Callback „startGUI“
gestartet werden, „GUIController::startGUI()“:
asrlib::Windows* _currentWindows = getWindows(name);
fltk::Window* _mainWindow = _currentWindows->getWindow();
_mainWindow->show();
registerSMCallbacks();
Mit „GUIController::getWindows(name)“ wird das gewünschte „Windows“- Objekt aus
dem Stack geholt. Mit „Windows::getWindow()“ wird sein Hauptfenster zurück
gegeben, das in FLUID „_ownWindow“ zugewiesen wurde (Seite 53, zweiter Absatz).
Alle zusätzlichen Fenster können mit Callbacks „showWindow“ bzw. „hideWindow“
von StateMachine aus gesteuert werden. Alle oben erwähnten Callbacks beziehen sich
auf die Controller- eigene Funktionen und wurden schon vorher registriert, mit
„GUIController::registerOwnCallbacks()“. „GUIController::registerSMCallbacks()“ aus
dem obigen Quelltext registriert alle Callbacks, die vom Controller zu StateMachine
gesendet werden sollen, also in andere Richtung. Objekte, an die diese Callbacks
registriert werden, sind alle aus der Konfigurationsdatei eingelesenen Zustände, deren
Actionen in der Gruppe „GUIcompatible“ sind (nicht mit GUI- Gruppen verwechseln).
std::string getGroupName() { return "GUIcompatible";}
Diese Objekte empfangen die Nachrichten vom Controller über die Funktion
„setUserData(void* data)“. Erst jetzt, nachdem das Senden von Nachrichten in beiden
Richtungen eingerichtet wurde, kommt es zu einer endlosen Schleife (auf der Seite 55).
Das gesamte Dialogsystem mit der graphischen Oberfläche wird automatisch beendet,
Seite 58

nachdem StateMachine mit der Action „EXIT“ („asrActions::Exit“) gestoppt wird.
Bevor dieses Kapitel abgeschlossen wird, kommen wir nach der Beschreibung der
Kommunikation zwischen verschiedenen Prozessen zur Abbildung 21 zurück. Wenn ein
Ereignis bei einer Schaltfläche auftritt, wird die Funktion „Windows::callbackButton()“
aufgerufen, die eine Nachricht als Callback zum jeweiligen Controller sendet (in
unserem Fall ist das „FKAController“). In der von diesem Callback aufgerufenen
Funktion „FKAController::callbackButton()“ wird es entschieden, was mit dieser
Information passieren soll. Hier wird diese einfach erneut versendet, diesmal als
Callback zum aktuellen Zustand von StateMachine. Wenn man an die in der Abbildung
19 dargestellte Tastatur denkt, dann sieht es nicht mehr sinnvoll aus, eine Mitteilung bei
jedem Ereignis an StateMachine zu senden, weil die aktuell laufende Action dabei
abgebrochen wird. Für Ereignisse, die von dieser Tastatur kommen, ist eine weitere
Funktion vorgesehen: „GUIController::callbackKeyboard()“. Das Verhalten dieser
Funktion kann in der abgeleiteten Klasse festgelegt werden. Bei „FKAController“
werden die Buchstaben, die dabei empfangen werden (das ist ja eine Tastatur)
zusammengesetzt und jedes Mal an StateMachine gesendet. In der Konfigurationsdatei
wird es entschieden, wann das aufhören soll, z.B. bei einem erkannten Wort („Köln“).
Mit Callback „updateFromSM“ kann StateMachine diese Information nochmal
anfordern. Danach wird diese in der Funktion „FKAController::updateFromSM()“
endgültig gelöscht. Man kann also diese Funktion auch extra dafür aufrufen.
Zum Schluss noch eine kurze Zusammenfassung des Quellcodes der Bibliothek
„libGui.so“:
Die Klasse „asrlib::Windows“ aus „include/GUI/Windows.h“ ist die Basisklasse für alle
Verwalter von graphischen Oberflächen. Alle GUI- Elemente werden in FLUID in der
Funktion „make_window()“ in der von „asrlib::Windows“ abgeleiteten Klasse erstellt.
Die FLUID- Projektdatei „prototyp.fl“ in „plugins/GuiPrototyp“ ist dafür vorbereitet.
Die Klassen in „include/GUI/Widgets.h“ sind Erweiterungen von FLTK- Klassen für
GUI- Elemente. Bei Bedarf kann man weitere Klassen hinzufügen.
Die Schnittstelle zwischen der graphischen Oberfläche und StateMachine ist ein Objekt
der von „asrlib::GUIController“ abgeleiteten Klasse, das in der „main()“ Funktion
erstellt wird und das sowie StateMachine als auch die graphische Oberfläche startet.
Seite 59