Montag, 19. Mai 2014

How to share a DocumentBuilder instance in Java

I tried to optimize parsing of XML document in JVoiceXML by using a DocumentBuilder as a static member:

    private final static DocumentBuilder BUILDER;

    static {
        final DocumentBuilderFactory factory =
                DocumentBuilderFactory.newInstance();
        factory.setNamespaceAware(true);
        factory.setIgnoringComments(true);
        DocumentBuilder builder = null;
        try {
            builder = factory.newDocumentBuilder();
        } catch (ParserConfigurationException e) {
            e.printStackTrace();
        }
        BUILDER = builder;
    }

When I used this construct by multiple threads, I stumbled across the following exception:
 
    org.xml.sax.SAXException: FWK005 parse may not be called while parsing

A quick search with google came up with results like this.Bad news: Parsing XML in Java is not thread safe. An immediate solution is synchronization. However, synchronization adds a lot of overhead and is actually only needed, if calls are actually coming from different threads. A better solution for me was to use ThreadLocal. My current soultion in JVoiceXML is the following:

    private static final ThreadLocal LOCAL_BUILDER
        = new ThreadLocal() {
        @Override
        protected DocumentBuilder initialValue() {
            final DocumentBuilderFactory factory =
                    DocumentBuilderFactory.newInstance();
            factory.setNamespaceAware(true);
            factory.setIgnoringComments(true);
            DocumentBuilder builder = null;
            try {
                builder = factory.newDocumentBuilder();
            } catch (ParserConfigurationException e) {
                e.printStackTrace();
            }
            return builder;
        };
    };

The implementation of ThreadLocal usage is very fast. However, creation of new objects is also very fast in current JVMs. I still have to check if caching really makes sense in this scenario, espacially, in the light of possible memory leaks as indicated by Nancy Deschenes.

Freitag, 12. April 2013

JNI causes XML parsing problems when using a custom ClassLoader

Recently, I discovered some strange problems, when I was trying to parse XML files when being called via JNI. The special thing here was that this method was called from a class that I loaded with a custom Java ClassLoader. Here, I got a NullPointerException when I was trying to obtain an XPathFactory via

XPathFactory xpathFactory = XPathFactory.newInstance();

Usually, this works out of the box, but I got an exception similar to this one: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6245257 
The strange thing is: The same code works if it was not called from a JNI method but from my own Java method.

Searching via Google reveiled a preliminary solution at https://forums.oracle.com/forums/thread.jspa?threadID=1626887 
They suggest to use

ClassLoader cl = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(new URLClassLoader(new URL[0], cl));

...
Thread.currentThread().setContextClassLoader(cl);

This code pretty much resets the ClassLoader to some more reasonable value. However, my problems did not vanish completely. The next error popped up, when I utilized some spring beans parser that threw strange exceptions about some XSD files claiming they were not readable. Again, the same code worked when being called from plain Java. So I started to dig into the problem. JNI guarantees that the ClassLoaders are the same when a Java method is called from JNI that were used to load the JNI library (see section 11.2 at http://192.9.162.55/docs/books/jni/html/design.html). This was true. A quick check with

System.out.println(getClass().getClassLoader());

showed the same ClassLoader for the time the library was loaded and for the time when the method from JNI was called. However, this was not true for the context ClassLoader. When the library was loaded, the method returned the usual URLClassLoader, but when being called from JNI, it simply returend null, which is the system ClassLoader. This was also true if the code above was used. This means that you will be able to access all class files that reside in rt.jar plus those that you added in your own class loader. Other classes that are subject to the endorsed capabilities will not be accessible anymore (see http://docs.oracle.com/javase/6/docs/technotes/guides/standards/). This includes the XML parsing libraries.

My solution for now was to adapt the context ClassLoader with

ClassLoader loader = getClass().getClassLoader();
Thread.currentThread().setContextClassLoader(loader);


This sets the context ClassLoader to the same value as it was when the JNI library was loaded.





Montag, 8. April 2013

OpenNI 2 with Fedora 18

The current Fedora 18 still ships with an older version of OpenNI. Therefore, I just tried to compile OpenNI2 from source [1] on my Fedora 18 system. There were some differences with regard to the required packages as they are noted for the usual Linux build instructions.

libUSB was installed by
sudo yum install libusbx-devel

freeglut3 does not exist, but
sudo yum install freeglut-devel 
seemed to be sufficient

libGL can be installed by either
sudo yum install mesa-libGLU-devel
or by installing the whole group via
sudo yum groupinstall "X Software Development"

In addition I added the following to line 73 of OpenNI2/ThirdParty/PSCommon/BuildSystem/CommonCppMakefile

LDFLAGS += -lpthread -lrt $(LIB_DIRS_OPTION) $(USED_LIBS_OPTION)
was: LDFLAGS += $(LIB_DIRS_OPTION) $(USED_LIBS_OPTION)

It is important that pthread and rt are linked prior to the rest. Afterwards calling make ran without failures.

[1] https://github.com/OpenNI/OpenNI2

Freitag, 11. September 2009

Spoken feedback in multimodal interaction: Effects on users experience of qualities of interaction

Üblicherweise beschäftigt sich die Forschung multimodaler Interaktion damit, wie verschiede Eingabemodalitäten zusammen genutzt werden können, um die Mensch-Maschine-Interaktion zu verbessern. Wenn es darum geht, verschiedene Ausgabemodalitäten gemeinsam zu nutzen, lichtet sich die Forschungslandschaft deutlich. Pernilla Qvarfordt hat in http://www.ida.liu.se/~perqv/paper/MMNordic03.pdf untersucht, wie sich Sprachausgaben mit redundanten Informationen parallel zur graphischen Ausgabe auf die Benutzerinnen solcher Systeme auswirkt. Sie folgt damit der Beobachtung, dass in alltäglichen Gesprächen ebenfalls oft redundante Informationen gegeben werden.

Für die Untersuchung hat sie eine Wizard-of-Oz Studie mit einem multimodalen Fahrplan durchgeführt. Die Benutzerinnen konnten mit dem Fahrplan entweder über Sprache oder aber durch Berühren eines Touchscreens interagieren. Die Spracherkennung und die Gestenerkennung wurden simuliert. Die Abfragen des Fahrplans waren echt.

In der Studie wurden drei Fälle unterschieden:
1. Keine Sprachausgabe
2. Begrenzte Sprachausgabe
3. Volle Sprachausgaben
In allen drei Fällen gab es graphische Rückmeldungen. Diese wurde z.B. genutzt, um anzuzeigen, dass das System gerade arbeitet, das eine Eingabe erwartet wird, für Fehlermeldungen oder aber um den Status des Spracherkenners anzuzeigen.
Begrenzte Sprachausgabe bedeutete hier, dass Sprachausgaben für Teile der Einleitung, für Fehlermeldungen oder für die Hilfe genutzt wurden. Volle Sprachausgabe bedeutete, dass Sprachausgaben auch dann erfolgen konnten, wenn die Benutzerin eine längere Pause machte.

Erstaunlicherweise wurde kein Einfluss der Sprachausgaben auf die Zeit, die zur Erledigung der Aufgabe benötigt wurde, beobachtet. Ebenso hatten die Benutzerinnen in allen drei Fällen jederzeit das Gefühl, das System zu kontrollieren. Unterschiede gab es aber, wenn es darum ging, herauszufinden welche Spracheingaben in der aktuellen Situation möglich waren. Sowohl ohne Sprachausgabe als auch bei voller Sprachausgabe waren die Systemenausgaben hilfreich. Lediglich bei der begrenzten Sprachausgabe waren sich die Benutzerinnen nicht sicher. Eine ähnliche Beobachtung gab es auch bei der Beurteilung der Benutzbarkeit des Systems. Das System mit begrenzter Sprachausgabe wurde als weniger komfortabel empfunden.

Insgesamt lässt sich also sagen, dass die Hinzunahme der Sprachausgabe keinen signifikanten Einfluss auf die Benutzbarkeit des Systems hat. Wenn Sprachausgaben verwendet werden, sollte dies jedoch auf möglichst natürliche Art und Weise erfolgen oder aber vermieden werden. Je natürlicher die Sprachausgaben sind, desto einfacher fällt die Benutzung des Systems und die Auswahl der Spracheingaben. Die Benutzerinnen fühlen sich sicherer und begegnen dem System positiver.

Donnerstag, 10. September 2009

Using Prosody for Automatic Sentence Segmentation of Multy-Party Meetings

Spracherkenner liefern in der Regel einen Strom von Worten die sie erkannt haben. Was sie nicht liefern sind wichtige strukturelle Informationen wie z.B. die Interpunktion. Diese ist aber wichtig, um dem menschlichen Leser das Verständnis des Gesagten zu erleichtern. Weiterhin sind Satzgrenzen wichtig für eine weitere Verarbeitung im Bereich des Natural Language Processing.

Bisherige Ansätze haben versucht solche Satzgrenzen unter Zuhilfenahme von lexikalischen und prosodischen Merkmalen in gelesenen Äußerungen von Nachrichtensprecher oder aber in spontanen Telefongesprächen zweier Parteien zu erkennen. Neuere Ansätze versuchen diese Erkennung in Meeting Szenarien mit mehreren Parteien. Ein solcher Ansatz wird in dem Paper von Kolàr und anderen http://www.speech.sri.com/papers/tsd2006-kolar-ProsSentSeg.pdf vorgestellt.

Eine interessante Frage, die die Autoren gleich zu Beginn aufwerfen, ist: "Was ist überhaupt ein Satz im spontan gesprochener Sprache?". Um dieser Frage nachzugehen haben sie mehrere Stunden von Meeting Mitschnitten transkribieren lassen. Dabei sollten die Durchführenden schnellstmöglich vorgehen. Hier kam es zu keinem einheitlichen Ergebnis. Satzgrenzen werden von unterschiedlichen Personen in spontan gesprochener Sprache also unterschiedlich wahrgenommen.

Für die Untersuchung wurden 270 prosodische Merkmale untersucht, wie z.B. Pause, Grundfrequenz, Dauer und Energie in verschiedenen Ausprägungen. Eine ganze Reihe dieser Merkmale hatte eine Korrelation und wurde zu Gruppen zusammengefasst. Für die Klassifikation wurden zwei Ansätze herangezogen:
1. ein HMM Framework und
2. ein eigener Ansatz mit Namen BoosTexter

Die Autoren konnten bei beiden Ansätzen zeigen das prosodische Informationen durchaus dabei helfen kann Satzgrenzen oder Dialogabschnitte zu erkennen. Dabei waren
die Pause nach dem aktuellen Wort, die Dauer des Wortes, die Pausen nach dem folgenden Wort und die normalisierte Dauer des letzten Wortes die wichtigsten Merkmale.

Diese Untersuchungen zeigen auf, das die Untersuchung prosodischer Merkmale durchaus für die Analyse im Rahmen von Meeting Szenarien Anwendung finden kann.

Montag, 7. September 2009

Gnome Voice Control

Nachdem ich ein wenig mit den Vista Spracherkenner herum gespielt habe, war ich auf der Suche nach etwas ähnlichem für Linux. Dabei stieß ich ziemlich schnell auf Gnome voice control.

Nach dem Herunterladen aus dem Subversion Repository war zunächst noch die Installationen weiterer Bibliotheken erforderlich. Weiterhin war für mein Fedora System der Server Pfad für /usr/lib nach Aufruf von make install anzupassen:
sudo ln -s /usr/local/lib/bonobo/servers/GNOME_VoiceControlApplet_Factory.server /usr/lib/bonobo/servers
Anschließend lässt sich das Applet mit der rechten Maustaste einem Panel hinzufügen.

Leider funktioniert das Applet nur, wenn der Desktop auf English umgestellt wurde. Das Applet läss sich zwar auch dann Laden, wenn der Desktop auf Deutsch eingestellt ist, sürtzt aber beim Starten des Erkenner gnadenlos ab.

Im Hintergrund werkelt der Spracherkenner PocketSphinx aus dem CMU Sphinx Projekt. Derzeit wird leider nur Englisch unterstützt und auch nur wenige Befehle, wie z.B. Run Terminal oder Run Editor. Weiterhin gibt es auch Unterstützung zur Kontrolle des Desktops wie Minimize Window oder Maximize Window.

In der aktuellen Version ist das Programm nur kurze Zeit benutzbar bevor es abstürzt oder aber der Desktop einfriert.

Insgesamt ein interessantes Programm, das aber noch einige Entwicklung benötigt, bevor es wirklich von Nutzen sein kann.