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

Thoughts on Aenea reimplementation #16

Open
LexiconCode opened this issue Oct 21, 2019 · 1 comment
Open

Thoughts on Aenea reimplementation #16

LexiconCode opened this issue Oct 21, 2019 · 1 comment

Comments

@LexiconCode
Copy link
Member

LexiconCode commented Oct 21, 2019

There still needs to be a Aenea reimplementation. Some might say that Aenea has outlived its use case with Dragonfly implementing cross-platform support and Draconity for DNS.

I don't believe that to be the case. We are now bridging into using more open source technology for speech recognition. Aenea has some advantages yet to offer. Primarily separating the backend (speech recognition engine) from the frontend client over a network.

  • Larger models for speech recognition
  • Dictation on low power devices
  • Easier deployment
  • More...

Anyone who is used Aenea knows that it's hard to set up and difficult to maintain. So what would be the path of least resistance? Why not to allow two instances of Dragonfly to communicate proxied with audio streaming. The thought is for whatever speech recognition engine is available through dragonfly would be compatible including DNS.

Dragonfly cross-platform and implements much of what was in Aenea to provide Linux. Testing can be done on Dragonfly 'text' engine which does not require a backend to perform manual and unit tests.

I primarily wanted to share this thought with the community to gauge interest. While I recognize I do not have the technical skills to build this from the ground up, I'm willing to contribute.

@calmofthestorm
Copy link
Member

This would be neat, but I think it would likely be a lot of work to transport the audio stream and get it "into" the speech recognition engine, since they will want to talk to hardware, I think we'd have to pretend to be hardware. It's definitely feasible, but likely a ton of work.

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

No branches or pull requests

2 participants