DEFUNCT

[black-snow]

Does this mean it stopped working? Are you planning to take a new path? Like integrating wit.ai or others? Japser is dead imho. There's things happening on the dev branch but nothing's ever coming to master and I never got it working on my raspi. It's a huge pita.

A simple npm i electron-speech would be awesome. I'm very interested into contributing to this :)

[hackergrrl]

Yes, the service that Google built into Chromium doesn't appear to be working in shell environments like Electron anymore.

I'm still very interested in having an offline-friendly easy-to-use voice recognition module, but I think this particular module isn't the road forward. Let me know if you get anything new underway!

[zeke]

It seems that Google has shut down the Chrome Speech API for use in shell environments like Electron, which electron-speech relies on.

I think this is probably happening because Electron has a baked-in Google API Key. In the early days of Electron it worked, but now there are enough users that we've cross the API limit and now we all get 403s when we try to do geolocation or speech recognition.

It might be possible to revive this project by using your own Google API key: http://electron.atom.io/docs/api/environment-variables/#google_api_key -- I know this works for geocoding. Not sure if it works for the speech APIs.

[bcomnes]

@zeke I'll test that out and report back sometime soonish.

[bcomnes]

Hrmmm... Not working even when I set the API env var after generating a key and enabling the speech api for it in the google apps dashboard.

$ export GOOGLE_API_KEY=xxxxx
$ ./cli.js
listening..
err network
done

Which looks like a possible credential error. @zeke Does the above approach look correct? The API key can be read from the ENV and doesn't need to be compiled into electron itself does it?

[zeke]

The API key can be read from the ENV and doesn't need to be compiled into electron itself does it?

In the case of geocoding, I know you don't have to compile the var into your build. You just set it in your environment: https://github.com/electron/electron/blob/master/docs/api/environment-variables.md#production-variables

I'm not sure if the same applies to speech recognition. It seems really hard to get a straight story on Google's support for this.

[zeke]

Just came across this issue: https://github.com/noffle/electron-speech/issues/10 -- sonus appears to be actively maintained. Could be a good alternative.

[bcomnes]

I came across that last night before giving up for the evening. Will check it out. Thanks for the info!

[bcomnes]

Aw shucks, requires a peer dependency of Sox. 🤔

[zeke]

Looks like sox is a dependency of snowboy -- maybe that could be made optional in sonus?

cc @evancohen

[evancohen]

@zeke it's only a dependency for their C++ and Python libraries - not the Node lib. You need some way to record 16bit wav audio, so sonus supports both sox and arecord.

You might want to check out sonus-electron-boilerplate, just be aware of evancohen/sonus-electron-boilerplate#1.

[bcomnes]

I tried using https://github.com/otalk/getUserMedia + https://github.com/kapetan/audio-stream + https://github.com/kapetan/pcm-stream but it didn't work. I'm not a wav expert, but at this point I would have to dig into the differences between what that pipeline produces and https://github.com/gillesdemey/node-record-lpcm16 + sox.

[bcomnes]

I got it working! https://github.com/bcomnes/speech-test/blob/master/renderer.js Had the sample rate set wrong initially, but its working great now using getUserMedia an no Sox or peer deps. It does require a big old ugly Auth token though. Maybe we can ship one or add a setup step to get one generated on first use.

[zeke]

Awesome.