Need a growing lattice during the online decoding (C++)

[Maksym Sarana]

Dear all,

Is there an efficient way to get periodically a growing lattice concurrently with the online decoding? The lattice should be rescored and determinized.

I'm playing around with the following code (actually based on the GST plug-in gst_kaldinnet2onlinedecoder_nnet3_unthreaded_decode_segment function). It works as I need, but is inefficient and pretty expensive.

Is there a way not to do all the operations from the start again and again - each loop cycle? Is it possible just to add the new data on the each iteration?

Thank you.

The code I am using looks like:

SingleUtteranceNnet3Decoder decoder(...);
...
while (more_data) {
    ... // decoding of a chunk of audio 

    if ((num_seconds_decoded - last_lat > lat_freq) && (decoder.NumFramesDecoded() > 0)) {
        Lattice rlat;

        CompactLattice clat;
        bool eou = false;

        decoder.Decoder().GetRawLattice(&rlat, eou);

        DeterminizeLatticePhonePrunedWrapper(trans_model, &rlat, lat_beam, &clat, det_opts);

        if ((lm_fst != NULL) && (big_lm_const_arpa != NULL)) {

            CompactLattice rescored_lat;

            if (gst_kaldinnet2onlinedecoder_rescore_big_lm(filter, clat, rescored_lat)) {  // rescoring function from the GST plug-in code

                clat = rescored_lat;
            }
        }

        ... // following processing

        last_lat = num_seconds_decoded;

    }
}   

[Daniel Povey]

Making an incremental version of the determinization algorithm is very nontrivial and it's something we haven't done.

If what you care about in the end is mostly the best path, and you want to rescore with a big LM, one possibility is to use the "biglm" type decoder (search for binaries with "biglm" in them), where the FST (HCLG) that we decode with is dynamically composed with the difference between the small and big LM.  Determinization won't be needed if you just want the best path.

We generally don't use the "biglm" decoder much as it's not very efficient.  If you do use it, be careful to use a relatively high optimization level in the C++.  We discovered recently that the optimization level of the code defaults to zero, and adding something like -O2 to the compilation flags in kaldi.mk may make a substantial difference to decoder speed; OpenFst is quite sensitive to the optimization level.

Actually I suspect that all this will be very hard for you, because it requiresd a level of familiarity with Kaldi that you probably don't have.  But my response may be helpful for others.

Dan

--
Go to http://kaldi-asr.org/forums.html find out how to join
---
You received this message because you are subscribed to the Google Groups "kaldi-help" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kaldi-help+unsubscribe@googlegroups.com.
To post to this group, send email to kaldi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kaldi-help/35d108b8-5f17-4ad0-9486-0430acbec15e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.