Open KJ7LNW opened 1 year ago
Do you use original gigaspeech model or did you modify it? I can't see a way original model to return non-utf8 char.
Original, unmodified.
We need to reproduce it somehow. The 0xa0 output is very strange to be honest, feels more like a memory corruption. How often do you see this issue?
I've only seen it once. If it happens again I'll let you know.
Ok, lets keep it open, I'll think how to catch it better.
There is a possibility that this was triggered because the Vosk object was reset (rec.reset()
) from a signal context while the API was executing. Nerd-dictation supports suspend through SIGTSTP/SIGSTOP
, so when it gets a stop signal it issues a reset
on the Vosk API object. If Vosk happened to be executing at that moment than it may create an inconsistency in the library. (Note that this is not multi-threading, just interruption from a signal.)
This is only speculation, but I wanted to point it out in case it's a problem being caused external to your API library.
In terms of troubleshooting, are there any 0xa0
characters in the text generated by the vosk-model-en-us-0.42-gigaspeech
model, even if some of them are part of a Unicode sequence? If it is actually a character representation issue in the model and not an issue related to suspending the process and issuing a reset, then by finding all text examples that contain 0xa0
, and we can try triggering it with those words.
So far I've not been able to reproduce this problem, but while using nerd-dictation, we have hit a Vosk decoding issue that appears to be rooted in the Bosk Python API code. I am running Python version 3.6 on CentOS 7 (which gets updates form Red Hat until 2024) while using the
vosk-model-en-us-0.42-gigaspeech
model.You can see the backtrace below. Notice that the last line triggers an error within the Vosk API at "vosk/init.py", line 194, in FinalResult
@ideasman42, the developer of nerd-dictation suggests that this could be fixed in Vosk by adding
errors=ignore
. For example:There are 4 different locations where text is decoded to UTF-8, so perhaps they need fixed up as well: