-
Notifications
You must be signed in to change notification settings - Fork 0
Implementierung
Die hier implementierte Anwendung realisiert ein sprachgesteuertes Realzeitsystem. Die Kernkomponenten des Systems sind die Input Task, Interpreter Task, Simulation Task und Mapper Task, sowie die gemeinsamen Resourcen der Audio Queue, Hypothesis Queue, die Simulation, der Audio Buffer Pool und der String Pool, über welche die Tasks miteinander kommunizieren.
Der Datenfluss des Systems wird in diesem Datenflussdiagramm beschrieben.
Audio Buffer Pool: Hierbei handelt es sich um einen im vorraus reservierten Speicherbereich mit einer festen Anzahl an Audio Puffern. Aus diesem Speicherbereich können sich Tasks dynamisch Audio Puffer reservieren und auch wieder freigeben. Somit wird ein underterministischer Weg über das Betriebssystem (malloc) vermieden.
String Pool: Dieser Pool dient dem gleichen Zweck wie der "Audio Buffer Pool", nur dass der String Pool Strings fester Größe verwaltet.
Die Input Task ist für das Aufnehmen und Speichern von Audiodaten verantwortlich. Dabei werden die Audiodaten live, also zur Laufzeit aufgenommen. Das Aufnehmen der Daten beginnt durch einfaches Audiodaten werden in einer audioBuffer_t Struktur gespeichert. Dabei handelt es sich um einen einfachen Puffer mit einer festen Größe, der bei einem Überlauf weitere eintreffende Daten verwirft. Dieser Puffer wird mithilfe des Audio Buffer Pools reserviert. Ist die Aufnahme beendet, wird der Puffer in der Audio Queue eingereiht. Hierbei handelt es sich wiederrum um eine Blocking Queue. Das Beenden einer Aufnahme wird entweder durch eine kurze Ruhephase (100ms) oder durch einen Pufferüberlauf ausgelöst.
Die Interpreter Task verarbeitet die gesammelten Audio Daten zu Strings, sogenannten Hypothesen. Zuerst wird aus der Audio Queue Für die Hypothese wird eigens ein String aus dem String Pool reserviert. Danach wird die Hypothese in die Hypothesis Queue eingereiht. Zuletzt wird der aus der Audio Queue entnommene Audio Puffer wieder freigegeben.
Die Simulation Task simuliert eine Art "Crash Test". Dabei gibt es einen Spieler, der durch Kommandos gesteuert werden kann, und Hindernisse, die sich auf den Spieler zu bewegen. Der Spieler hat 2 Bahnen, auf denen er sich befinden kann. Diese muss der Spieler nutzen, um den Hindernissen auszuweichen. Die Task simuliert dabei in einem Schritt die Spiellogik und zeichnet danach das ganze Geschehen auf den Bildschirm.
Die Mapper Task übernimmt das Übersetzen der Hypothesen zu Kommandos für das System. Zuerst entnimmt die Task eine Hypothese aus der Hypthesis Queue. Danach wird über eine "if-else" Abfrage bestimmt, welches Kommando auszuführen ist. Zum Schluss wird die erhaltene Hypothesis wieder freigegeben.
Das System benutzt zur Spracherkennung die Bibliothek Pocketsphinx. Die Simulation wird mithilfe von Allegro 4 grafisch dargestellt.