Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enable cloud reco without hotword detection #103

Open
wants to merge 32 commits into
base: dev
Choose a base branch
from

Conversation

sdetweil
Copy link

for a conversational app, we need the ability to capture spoken phrases one at a time.

my google assistant app has a few processes which take multiple question/answer cycles
add a calendar entry, label, when, what time, save?
the 1st starts with a hotword cycle, but the rest become unusable with hotword and app targeting

all I did was move things around and use hotwords=-1 as a flag (you allow hotwords=null already

start Streaming reco on start request

this allows the current usage unchanged and a new usage in sequence

@sdetweil
Copy link
Author

ok, i have a problem,with the last change.. when we do a Sonus.stop, we tell the node-record-lpcm16 module to stop, killing the arecord engine.. but that yanks the stream out from under snowboy, who rightfully throws an error

Error [ERR_STREAM_WRITE_AFTER_END]: write after end
    at writeAfterEnd (_stream_writable.js:248:12)
    at SnowboyDetect.Writable.write (_stream_writable.js:296:5)
    at Socket.ondata (_stream_readable.js:710:20)
    at Socket.emit (events.js:203:15)
    at addChunk (_stream_readable.js:288:12)
    at readableAddChunk (_stream_readable.js:269:11)
    at Socket.Readable.push (_stream_readable.js:224:10)
    at Pipe.onStreamRead [as onread] (internal/stream_base_commons.js:94:17)
Emitted 'error' event at:
    at errorOrDestroy (internal/streams/destroy.js:107:12)
    at SnowboyDetect.onerror (_stream_readable.js:734:7)
    at SnowboyDetect.emit (events.js:198:13)
    at errorOrDestroy (internal/streams/destroy.js:107:12)
    at writeAfterEnd (_stream_writable.js:250:3)
    at SnowboyDetect.Writable.write (_stream_writable.js:296:5)
    [... lines matching original stack trace ...]
    at readableAddChunk (_stream_readable.js:269:11)

which appears on the smart-mirror , npm start console.

so, I wanted to hide the expected error
adding the detector.on('error'...) does get triggered, but..

the detector is in an unrecoverable state
and it looks like he restarts arecord. but the stream is gone to the sonus library detector object.

then I later send a new 'Sonus.start() and he creates another detector, which starts arecord again..

the under the covers one doesn't stream as the pipe is broken
and the new one can't work as the hardware is already in use, but the second arecord continues to run(same process id), not restarting cause hardware busy..

if I let the error flow to the npm start console, all works ok..

i looked at the snowboy library and don't see a stop() function . there is reset(), but I can't tell what it does.

is there a better way to capture the detector error when the pipe is killed below it?

@sdetweil
Copy link
Author

the error above is fatal, smart-mirror sonus background process crashes, and smart-mirror starts it back up, so now we are out of sequence so, doesn't work.. works great on fast intel box.

without the keyword spotter, its graceful , down on stop() and back up on start()

@sdetweil
Copy link
Author

never mind, staring me right in the face!.. unpipe the mic! before stop.. it gets repiped on start

stop just needs to have the sonus object passed back in (like Start).. this could be a breaking change if anyone used stop

@sdetweil
Copy link
Author

works great!

@sdetweil
Copy link
Author

I have a reliable working version now. the restart of arecord (before its .wav file 2 gig limit) needed time to shutdown, and there was a possibility that there could be more buffers over the data limit before we could actually get arecord stopped.

@sdetweil
Copy link
Author

on two of my machines, when we do the arecord stop/restart because of the node-record-lpcm16 wav file overflow, the existing process takes over 300 milliseconds to stop. i had created a library to do this in the code for sharing the mic, so use it here as well.
finally recovery works reliably

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants