Entwicklung einer Automatenbedienung mit einer leistungsfähigen Spracherkennung und einer graphischen Benutzerschnittstelle unter C++

Transkript

1 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 Viersen Matrikelnummer abgegeben am: Erstgutachter: Prof. Dr.-Ing. Hans-Günter Hirsch Zweitgutachter: Prof. Dr.-Ing. Roland Hoffmann

2 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.

3 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

4 Inhaltsverzeichnis 1. Aufgabenstellung Einleitung Grundlagen Dialogsystem Graphisch Sprachbasiert Multimodal Spracherkennung Spracherkennungssystem Analyse Erkennung Betriebsmittel, Software FLTK POCO Hilfsmittel asrlib asrlib und CMake asrlib und Code::Blocks Bibliotheken Plugins Wichtiges Parallele Erkennung GUI...51 Tabellenverzeichnis Vorhandene Actionen eines Zustandsautomaten aus dem Plugin Actions.so...28 Mögliche Zustände einer Sprachdetektion mit HirschLib- Funktionen...41

5 Abbildungsverzeichnis Abbildung 1: Spracherkennungssystem...7 Abbildung 2: Aufteilung des Audiosignals...8 Abbildung 3: Merkmalsextraktion...8 Abbildung 4: FLUID Hauptfenster Abbildung 5: FLUID Hauptfenster 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

6 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

7 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

8 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 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 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

9 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 s 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 [ 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

10 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

11 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 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

12 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

13 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

14 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

15 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. [ 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 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. [ 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

16 ( 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

17 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 <stdlib.h> #include <fltk/window.h> #include <fltk/widget.h> #include <fltk/button.h> #include <fltk/run.h> 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

18 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

19 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. [ 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 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

20 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, s 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

21 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. [ 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. [ 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

22 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

23 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 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

24 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 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

25 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 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

26 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

27 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: <STATE> frage1 <ACTION> AUDIO_OUT <ACTION_PARS> 1 fahren_sie_allein.raw <TRANS_SEL> 0 <TRANS_STATE> <DEFAULT_TRANS> erkennung_ja_nein <STATE> erkennung_ja_nein <ACTION> RECOGNIZE <ACTION_PARS> 2 jn.syn M_rec <TRANS_SEL> 2 w_nein w_ja <TRANS_STATE> frage2 goodbye <DEFAULT_TRANS> goodbye <STATE> frage2 <ACTION> AUDIO_OUT <ACTION_PARS> 1 wieviel_personen.raw <TRANS_SEL> 0 <TRANS_STATE> <DEFAULT_TRANS> erkennung_zahl <STATE> erkennung_zahl <ACTION> RECOGNIZE <ACTION_PARS> 3 number.syn M_rec B_nummer <TRANS_SEL> 0 <TRANS_STATE> <DEFAULT_TRANS> goodbye <STATE> goodbye <ACTION> AUDIO_OUT <ACTION_PARS> 1 goodbye.raw <TRANS_SEL> 0 <TRANS_STATE> <DEFAULT_TRANS> 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

28 ü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

29 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

30 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

31 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

32 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<std::string> (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<std::string>("B_Name", "Wert")); statemachine->addproperty<std::string>("m_name", "Wert"); statemachine->rmproperty("m_name"); Seite 27

33 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

34 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<AdaptionHGH>* cb = new Callback<AdaptionHGH>(_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

35 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

36 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<asrapplication*>(pluginfactory::get()->create("applicationhgh")); Seite 31

37 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): <ACTION> <ACTION_PARS> RECOGNIZE_INIT <N> <hmm> [SM_DC_BLOCK] [<Add>] [<SR>] [<SDF>] [<VT>] <M_rec> <N> Anzahl der folgenden Komponenten <hmm> Listenfile mit allen zu verwendeten HMM- Mustern SM_DC_BLOCK DC-Filter einschalten, optional(audiofx.so wird geladen) <Add> Erkennung mit zusätzlichen Funktionen durchführen, optional SM_ADAPTION Erkennung mit Adaption der Muster SM_ROBUST Robuste Erkennung <SR> SampleRate in Hz (8000, 11000, 16000), optional <SDF> SampleDataFormat (INT16, INT32, FLOAT32), optional <VT> VectorType (MFCC_E, MFCC_E_0, MFCC_E_D_A, MFCC_E_D_A_0) opt <M_rec> 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. <ACTION> <ACTION_PARS> RECOGNIZE <N> [<break>] <syn> [<audio>] <M_rec> [<M_recN>] [<Buffer>] <N> <break> SM_GUI SM_BUTTON SM_KEY <syn> <audio> <M_rec> <M_recN> <Buffer> 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

38 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. <ACTION> <ACTION_PARS> RECOGNIZE_TEST <N> <syn> <audio> <M_rec> [<Buffer>] <N> <syn> <audio> <M_rec> <Buffer> 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. <ACTION> <ACTION_PARS> <M_rec> RECOGNIZE_EXIT 1 <M_rec> 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

39 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<isdnfrontend*>()->getaudiomanager(); Seite 34

40 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 ( * für Millisekunden): audiomanager->settimestep((float)framesize / (float)samplerate * ); 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

41 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() Signalabschnitte Abtastwerte Merkmalsvektoren AudioManager:: tickcb() Für alle im AudioManager registrierten Komponenten: tick() BufferedIOAdaptor::tick() [ DCBlocker::tick() ]... Abbildung 16: Ablaufplan einer Spracherkennung Seite 36

42 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

43 _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

44 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

45 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

46 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

47 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

48 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 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

49 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

50 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

51 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 SoundcardFrontend:: pacallbackfun() Signalabschnitte BufferedIOAdaptor::tick() Abtastwerte Abtastwerte AnalyzerHGH::analyze() AnalyzerHGH::analyze() Merkmalsvektoren Merkmalsvektoren RecognizerHGH::process() RecognizerHGH::process() RecognizerHGH::process() RecognizerHGH::process() Abbildung 18: Möglicher Verlauf einer parallelen Spracherkennung Seite 46

52 Wir haben hier also 4 Spracherkennungssysteme. Wie im Kapitel 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

53 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<isdnfrontend*>(); asrapp->addproperty("audiofrontend", audiofrontend); } else { audiofrontend = new SoundcardFrontend(); audiofrontend->setaudiomanager(asrapp->getaudiomanager()); audiofrontend->initialize(); asrapp->addproperty("audiofrontend", audiofrontend); } } Seite 48

54 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<std::string> 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

55 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 << "\n!!! ERROR!!!"<< std::endl; pthread_mutex_unlock(&mutex_report_recognize); Soviel zu einer parallelen Erkennung. Näher im Quelltext oder in der Dokumentation. Seite 50

56 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<guicontroller*> (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

57 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

58 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

59 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