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

Extensions of the voice services (KS, STT, TTS) #1063

Closed
lolodomo opened this issue Sep 30, 2019 · 6 comments
Closed

Extensions of the voice services (KS, STT, TTS) #1063

lolodomo opened this issue Sep 30, 2019 · 6 comments

Comments

@lolodomo
Copy link
Contributor

The current Key Spotting service and Speak-To-Text service are requiring an openHAB audio source as input. Snips API give the opportunity to create a KS service and a STT service but the audio source is "hidden" and audio files cannot be retrieved.
So I would like to extend the current KS and STT services to add a property we could named "audioSourceEmbedded".
In case a KS or STT service defines this property to true, the openHAB dialog processor will call these services without considering any audio source.
Of course, it requires a breaking change of the current voice API. But as we have until now no STT or KS services included in the openHAB distribution, I don't think it is a problem. It also requires a little change in the openHAB dialog processor which is a feature implemented but not used in the openHAB distribution.

This change is a requirement to integrate Snips ASR as a KS and STT service in openHAB.

Is there any objection ?

@lolodomo
Copy link
Contributor Author

lolodomo commented Oct 1, 2019

I could also extend the Text-To-Speak service with a property "audioSinkEmbedded".
In this case, the existing TTS services of the distribution should be enhanced to set this property to false.

@lolodomo lolodomo changed the title Extensions of Key Spotting and Speak-To-Text services Extensions of the voice services (KS, STT, TTS) Oct 1, 2019
@lolodomo
Copy link
Contributor Author

lolodomo commented Oct 1, 2019

If I implement a specific dialog processing in the Snips binding, I can avoid all these changes. So I think there are not a requirement for Snips integration.

@lolodomo
Copy link
Contributor Author

lolodomo commented Oct 1, 2019

One alternative would be keep untouched STTService and TTSService and define new services.

@ghys
Copy link
Member

ghys commented Oct 1, 2019

This reminds me of a similar proposal (eclipse-archived/smarthome#1081 (comment)) from 3.5 years ago distinguishing "external" and "local" STT services, i.e. handling the audio part externally or locally. Never actually pursued it (I abandoned the idea) but referring to it since it's related to this issue.

@lolodomo
Copy link
Contributor Author

lolodomo commented Oct 1, 2019

Yes, we are clearly on the same subject, even if your focus was on the TTS service.
I will work on a PR based on your solution.
This change will require a change to all existing STT/TTS bindings.

@lolodomo
Copy link
Contributor Author

I close the subject, finally I don't need any of these changes to integrate Snips in a binding.

Rosi2143 pushed a commit to Rosi2143/openhab-core that referenced this issue Dec 26, 2020
* Update events.md

* Update events.md

Fix typo.
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