Timo Baumann : Home Page > aeh ja
Spielsystem: Zwei Dialogpartner, die jeweils auf den anderen antworten, wenn dieser ausgesprochen hat (vgl. hier).
Tipps zur Inbetriebnahme:
- zunächst müssen Sphinx und OAA installiert werden.
- dazu aus meinem Homeverzeichnis die Datei sphinx+oaa.tar.bz2 herunterladen
- die Datei nach /opt/ entpacken (muss man natürlich root für sein, dafür ist es dann aber auch gleich für alle auf dem Rechner installiert)
- gegebenenfalls /opt/bin/ in PATH mit aufnehmen:
- echo export PATH=\$PATH:/opt/bin/ >> .bashrc
- gegebenenfalls dafür sorgen, dass alle JARs in /opt/java/ dem CLASSPATH hinzugefügt werden:
- echo for name in \`ls /opt/java/*.jar\` \; do export CLASSPATH=\$CLASSPATH:\$name \; done >> ~/.bashrc
- das Projekt aus SVN auschecken:
- svn co svn+ssh://helios/home/das/INPRO_SVN/Code/Java
- nach belieben kompilieren (ich benutze Eclipse, das macht das von selbst. Bei Bedarf könnte ich auch ein ant-buildfile mit einchecken).
- in folgender Reihenfolge -- am besten jeweils in einem eigenen Terminal -- starten:
- zunächst den Facilitator
- einen DispatcherAgent
- java org.cocolab.inpro.agents.dispatcher.DispatcherAgent dispatcher.a.xml
- den zweiten
- java org.cocolab.inpro.agents.dispatcher.DispatcherAgent dispatcher.b.xml
- entsprechend die Receiver:
- java org.cocolab.inpro.agents.vad.VADAgent vad.a.xml
- java org.cocolab.inpro.agents.vad.VADAgent vad.b.xml
- und schließlich die Audioplayer:
- java org.cocolab.inpro.agents.audioplayer.AudioplayerAgent audioplay.a.xml
- java org.cocolab.inpro.agents.audioplayer.AudioplayerAgent audioplay.b.xml
- damit jetzt etwas passiert, muss einer der Agenten anfangen zu sprechen:
- dafür den OAA Debugger starten
- auf den Solve-Knopf drücken und das X im IclRequest durch berndPlayAudio oder durch antoniaPlayAudio ersetzen.
Realzeit-Fähigkeit:
wird durch die Einstellung in org/cocolab/inpro/agents/global.parameters.xml bestimmt. Im Moment ist mehr als 0.05 nicht drin, das wird aber besser, wenn wir die Audiodaten nicht mehr per OAA verschicken.
- Der Dispatcher ist ein Flaschenhals: wenn er eingehende Pakete verarbeitet, dann kann er keine Anfragen bearbeiten.
- die outQueue wird "verlängert", wenn der Realzeit-Thread ins Hintertreffen gerät. Dies wird (bisher) durch den sprechenden Dialogpartner verursacht, nicht durch den hörenden. Es wäre also unfair, wenn der hörende darunter leiden müsste
- weniger Pakete erzeugen weniger Overhead. Andererseits können kleinere Pakete schneller verarbeitet werden und sorgen für geringere Latenz.
- der AudioPlayer verschickt exponentiell größer werdende Pakete. Dadurch bleibt die Paketzahl möglichst gering.
- Um die Paketverarbeitung im Dispatcher zu entzerren, wartet er zwischen dem verschicken 9*Anzahl Frames ms. Die Übertragung dauert zwar länger, die Lastkurve wird aber gleichmäßiger. (TODO: Es wäre Zweckmäßig, die Wartezeit vom Echtzeitfaktor in der Verarbeitung abhängig zu machen. Allerdings müsste der AudioPlayer ihn dann kennen)
- zu große Pakete beschäftigen den Dispatcher lange am Stück, sodass er zwischendurch keine Audio-Anfragen beantwortet. Die maximale Paketgröße im AudioPlayer ist deswegen z.Zt. auf 16 Frames begrenzt.
- insgesamt müssen wir drauf achten, dass zumindest das Basissystem mit dem Echtzeitfaktor zurechtkommt. Wird er verändert, müssen andere Variable wahrscheinlich daran angepasst werden: outQueue-Länge, maximale Paketgröße im AudioPlayer, Prozess-Niceness
- Mit einem Dialogparter (der sich selbst zuhört), erreicht mein Computer halbe Echtzeit.
Probleme:
- Irgendwann steigt der Facilitator aus: "! the atom table is full" (es ist also notwendig, alte SpeechEnd-Fakten zu löschen)
timo, 07/12/07 10:06 (GMT)
Add a new page under this one
