Skip to content

nodejs: fix accept_waveform error handling and add missing recognizer/model methods - #2056

Open
Dhruvy0804 wants to merge 1 commit into
alphacep:masterfrom
Dhruvy0804:nodejs-api-parity
Open

nodejs: fix accept_waveform error handling and add missing recognizer/model methods#2056
Dhruvy0804 wants to merge 1 commit into
alphacep:masterfrom
Dhruvy0804:nodejs-api-parity

Conversation

@Dhruvy0804

Copy link
Copy Markdown

Two related changes to the Node.js binding.

Fix: accept_waveform errors were reported as end-of-utterance

vosk_recognizer_accept_waveform is declared to ffi as returning 'bool':

'vosk_recognizer_accept_waveform': ['bool', [vosk_recognizer_ptr, 'pointer', 'int']],

but the C API returns an int and documents three states:

 *  @returns 1 if silence is occured and you can retrieve a new utterance with result method
 *           0 if decoding continues
 *           -1 if exception occured

ffi coerces the non-zero -1 to true, so when Recognizer::AcceptWaveform throws and
vosk_api.cc returns -1, the Node caller sees exactly what it sees on a successful
endpoint. Every demo follows the if (rec.acceptWaveform(data)) ... rec.result() shape,
so the failure surfaces as a stale/empty result rather than an error.

This declares the return as 'int' and throws on a negative value, matching what the
Python binding already does:

res = _c.vosk_recognizer_accept_waveform(self._handle, data, len(data))
if res < 0:
    raise Exception("Failed to process waveform")

acceptWaveform and acceptWaveformAsync still resolve to a boolean, so existing
callers and all of the demo/ scripts are unaffected on the success path.

Add the configuration calls that were already exported

These are in vosk_api.h and reachable from the C, Python, Java and C# bindings, but
were not bound here — the README notes that "some methods are not yet fully implemented".

Added C function
Model.findWord() vosk_model_find_word
Recognizer.setNlsml() vosk_recognizer_set_nlsml
Recognizer.setGrammar() vosk_recognizer_set_grm
Recognizer.setEndpointerMode() vosk_recognizer_set_endpointer_mode
Recognizer.setEndpointerDelays() vosk_recognizer_set_endpointer_delays

Also exports an EndpointerMode enum mirroring VoskEndpointerMode, named as in the
Python binding:

const { Recognizer, EndpointerMode } = require('vosk');
rec.setEndpointerMode(EndpointerMode.SHORT);

setGrammar takes an array and stringifies it, consistent with how the grammar
constructor option is already handled; [] switches back to the default model graph.

All new symbols already ship in the 0.3.75 libraries that this package version pairs
with, so ffi.Library resolution is unaffected.

Notably left out: the batch/GPU calls (need a CUDA build to exercise) and the text
processor calls (vosk_text_processor_itn returns a strduped buffer with no
corresponding free in the C API, so binding it would leak).

JSDoc is kept in the existing style and the file still passes tsc --checkJs with no
new diagnostics.

…t_waveform error handling

vosk_recognizer_accept_waveform was declared to ffi as returning 'bool',
but the C API returns an int and documents -1 for the error case. ffi
coerces -1 to true, so a failure to process a chunk was reported to the
caller as "end of utterance" and the next result() call returned stale
data instead of surfacing the error. Declare the return as 'int' and
raise, like the Python binding does. acceptWaveform still returns a
boolean, so existing callers are unaffected.

Also bind the configuration calls that were already available in the C,
Python, Java and C# bindings but missing here:

  - Model.findWord()            -> vosk_model_find_word
  - Recognizer.setNlsml()       -> vosk_recognizer_set_nlsml
  - Recognizer.setGrammar()     -> vosk_recognizer_set_grm
  - Recognizer.setEndpointerMode()   -> vosk_recognizer_set_endpointer_mode
  - Recognizer.setEndpointerDelays() -> vosk_recognizer_set_endpointer_delays

along with an EndpointerMode enum mirroring VoskEndpointerMode.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant