Hi, I have been using pocketsphinx_continuous with custom language and
acoustic model and it has been working very well but after while it just
stops. Below is the usual output of two last utterances before halt. I would
be very grateful if someone can give some advice where I should be looking for
solution before I lost myself in code completely :)
That sounds like a bug. What version are you using? Can you reproduce it with
recent trunk? Can you provides models to let me reproduce it locally? Can you
enable audio dump with -rawlogdir . and share last audio chunk that auses
issue as well.
Are you running on the system with restricted memory? It looks you need some
tigher beams then.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using sphinxbase and pocketsphinx both version 0.6 on embedded system with
256MB, I can try to reproduce it with recent trunk and with -rawlogdir later
today or tomorrow and send you results.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Today I finally managed to make some tests and here is what I found out.
Pocketsphinx_continuous is stuck in continuous listening mode and these
messages (memory related?) are consequence of wanna-be-infinite utterance.
When I introduce break (if the utterance is more than few seconds long) in the
listening loop then it continuously breaks out of it with (null) or some
other, mainly wrong, hypothesis.
I tried to find out what triggers that behavior but I cant put my finger on
it. It seems like sensitivity to noise suddenly gets really high. When the raw
files are played I can hear a little elevated noise (interference) in
background but nothing too loud or out of the ordinary. If you would like to
help me I can send you the raw files before and after the constant listening
mode kicks in.
Also, there is one more thing that probably is not related - at the beginning
of each raw file there a little stuttering can be heard. When I make normal
rec (parallel with pocketsphinx) in another terminal it sounds ok so I wonder
is that normal behavior and what is the cause?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey, thank you for the tip, but it seems that memory is not the problem,
problem is infinite utterance loop. I looked into it further and real problem
seems to be silence/speech filtering in sphinxbase cont_ad module. Source
might be the fact that my program often mutes capture device so by
recalibration in muted periods this module becomes too sensitive to
noise/interference and thinks it's speech. If that is the case solution is
avoidance of muting the device and keeping interference as low as possible by
solving some hardware issues.
There is one other thing that bothers me and I cant figure it out and that is
stuttering in raw files. I'm sending you the recordings via mail.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've got your file, it seems it has DC offset. Please try to add "-remove_dc
yes" option to remove it. Also please send me long continuous recording
bypassing pocketsphinx from your device. I'll try to test cont_ad locally.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, it took me a while. I checked your file and it seems ok. It might be
indeed like you said when you mute energy endpointer breaks. Can you try to
insert into your code
cont_ad_set_logfp(cont, stdout);
and share the log of the endpointer?
Also, I wonder if you mute the device, why don't you stop recording as well.
You can just pause cont_ad_read for a while,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi thank you for looking into it. Conditions that had to be satisfied for
problem to occur are very subtle and difficult to grasp but anyway the
solution was not so hard to make - removing the mute part. Indeed, it should
have been avoided in the first place as it was only a bad temporary-shortcut
code to real solution (which is pausing cont_ad_read like you said).
Second problem in my last post is a little bit harder to trace: as you can
hear from files in my last mail, usual rec (parallel to pocektsphinx) records
a perfect sound file but raw audio files that are logged from pocketsphinx at
the same time have stutterings all over. I wonder what is the cause and if
solving this problem can enhance recognition accuracy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In order to investigate this can you dump the raw input to the file please?
Not a parallel recording but actual data that
appears in the device. You need to insert this chunk of code into the
application.
if((rawfp=fopen(copyfile,"wb"))==NULL)E_ERROR("Failed to open raw output file '%s' for writing: %s\n",copyfile,strerror(errno));elsecont_ad_set_rawfp(cont,rawfp);
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you have the same problem maybe the same solution can help you. You just
need to configure the frontend to split the audio on utterances properly. Also
you can increase frame_idx_t type to int32 to make utterance size bigger. See
hmm.h header for details.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I have been using pocketsphinx_continuous with custom language and
acoustic model and it has been working very well but after while it just
stops. Below is the usual output of two last utterances before halt. I would
be very grateful if someone can give some advice where I should be looking for
solution before I lost myself in code completely :)
Hello
That sounds like a bug. What version are you using? Can you reproduce it with
recent trunk? Can you provides models to let me reproduce it locally? Can you
enable audio dump with -rawlogdir . and share last audio chunk that auses
issue as well.
Are you running on the system with restricted memory? It looks you need some
tigher beams then.
Hi,
I'm using sphinxbase and pocketsphinx both version 0.6 on embedded system with
256MB, I can try to reproduce it with recent trunk and with -rawlogdir later
today or tomorrow and send you results.
Today I finally managed to make some tests and here is what I found out.
Pocketsphinx_continuous is stuck in continuous listening mode and these
messages (memory related?) are consequence of wanna-be-infinite utterance.
When I introduce break (if the utterance is more than few seconds long) in the
listening loop then it continuously breaks out of it with (null) or some
other, mainly wrong, hypothesis.
I tried to find out what triggers that behavior but I cant put my finger on
it. It seems like sensitivity to noise suddenly gets really high. When the raw
files are played I can hear a little elevated noise (interference) in
background but nothing too loud or out of the ordinary. If you would like to
help me I can send you the raw files before and after the constant listening
mode kicks in.
Also, there is one more thing that probably is not related - at the beginning
of each raw file there a little stuttering can be heard. When I make normal
rec (parallel with pocketsphinx) in another terminal it sounds ok so I wonder
is that normal behavior and what is the cause?
If I would be able to reproduce it I could solve this easily. That parallel
recording file will also help
As for embedded device there are number of tricks to make memory usage low.
For example -maxhmmpf 3000 should be better.
Hey, thank you for the tip, but it seems that memory is not the problem,
problem is infinite utterance loop. I looked into it further and real problem
seems to be silence/speech filtering in sphinxbase cont_ad module. Source
might be the fact that my program often mutes capture device so by
recalibration in muted periods this module becomes too sensitive to
noise/interference and thinks it's speech. If that is the case solution is
avoidance of muting the device and keeping interference as low as possible by
solving some hardware issues.
There is one other thing that bothers me and I cant figure it out and that is
stuttering in raw files. I'm sending you the recordings via mail.
Hi
I've got your file, it seems it has DC offset. Please try to add "-remove_dc
yes" option to remove it. Also please send me long continuous recording
bypassing pocketsphinx from your device. I'll try to test cont_ad locally.
Hi
Sorry, it took me a while. I checked your file and it seems ok. It might be
indeed like you said when you mute energy endpointer breaks. Can you try to
insert into your code
cont_ad_set_logfp(cont, stdout);
and share the log of the endpointer?
Also, I wonder if you mute the device, why don't you stop recording as well.
You can just pause cont_ad_read for a while,
Hi thank you for looking into it. Conditions that had to be satisfied for
problem to occur are very subtle and difficult to grasp but anyway the
solution was not so hard to make - removing the mute part. Indeed, it should
have been avoided in the first place as it was only a bad temporary-shortcut
code to real solution (which is pausing cont_ad_read like you said).
Second problem in my last post is a little bit harder to trace: as you can
hear from files in my last mail, usual rec (parallel to pocektsphinx) records
a perfect sound file but raw audio files that are logged from pocketsphinx at
the same time have stutterings all over. I wonder what is the cause and if
solving this problem can enhance recognition accuracy.
Hello
In order to investigate this can you dump the raw input to the file please?
Not a parallel recording but actual data that
appears in the device. You need to insert this chunk of code into the
application.
Hi, I have inserted the code and files are sent by mail.
Hi,
Yes, I know this bug is a bit older, but I have the same problem running
pocketsphinx over gstreamer:
ngram_search_fwdtree.c:825: prune_nonroot_chan: Assertion `(&hmm->hmm)->frame
Bug is in both version 0.7 and current svn trunk.
Hello nxdefiant
If you have the same problem maybe the same solution can help you. You just
need to configure the frontend to split the audio on utterances properly. Also
you can increase frame_idx_t type to int32 to make utterance size bigger. See
hmm.h header for details.
Just to be on the save side: This means configuring vader in gstreamer, right?
And that too
ok with frame_idx_t as int32 it is way more stable (no single crash yet)
Thanks.