Performance optimization is broken down into two stages. The first stage is described here:

We've looked at a number of techniques to improve the speed of the recognizer.

• Unigram Smear - including unigram probabilities in the lex tree
• Tighter Word Beams - tightening up the absolute word beam
• Grow Skipping - deferring state transitions
• Token Stacks - limiting the number of paths through a lex state
• Frame Skew Pruning - prune based upon recent history of a state
• Simple Acoustic Look Ahead - prune based on likelihood that we'll stay in current state for a while
• Profile And Optimize The Code - using a good profiler we identify and tune bottlenecks.

Other things that we could do (but haven't yet):

• Second Pass - Rescore the lattice
• Fast Match - a fast way of constraining the search.

There is also a S3 vs S4 Performance comparision page.

This chart shows summarizes the effect of these various optimizations on the speed and accuracy of hub4 quick (which is 7 short utterances from hub4).

Test notes:

• Tests run with 7 short sentences of hub4. Note that the WER here is not representative of the WER for the entire hub4 test. The full hub4 test is generally around 6% higher than this).
• Runtimes are for glottis.east
• HMM State Reuse - reused self-looping hmm states to reduce object creation

Based on the tuning experiments we will now try a select set of full runs to see where we stand in terms of our speed and accuracy goals.

The full test consists of about 51 minutes of audio. Thus a 10XRealtime run will take 510 minutes or 8.5 hours. The quick tests are a quicker version that run in about 1 3/4 hours.

This is the full f0 test (215 utterances). Tests are on glottis unless otherwise noted.