You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
since we are leaving snips behind we can change some things in the dialog flow. This issue is a lost of some ideas of what we could do better:
split sentences before sending them to the tts
when generating the sentences in multiple steps we can already generate them while alice says the previous sentence resulting in faster reactions from alice, since e.g. with the Who Are You question it takes a noticeable delay. This does not change pricing for online tts, since they are payed per character anyways
allow asr to listen while playing the feedback sound using some kind of acoustic echo cancelation we could directly react to alice while she still plays the feedback sound. This results in a faster reaction time for alice -> improves usability
add offline only intents right now when we use a online asr we will always use it unless we lose the internet connection. While I did not find a way for use to detect which one to use for the first intent (without serious time loss), it is rather simple for every other intent in a dialog flow. For these intents it could be specified by skill whether a intent should be offline only, since e.g. a YesOrNo intent absolutely requires no online asr. When all currently activated intents are offline only it could simply use an offline asr. This would be faster, since we do not have to send them over the internet, improve privacy for the user, since less audio recordings are send over the internet and reduce costs, since they do not have to pay for these simple speech to text conversions.
allow reactions while tts is speaking allowing reactions while alice speaks e.g. to cancel her speaking would be useful, even though this requires further considerations as to what would be the expected behaviour in different scenarios.
allow concurrent sessions people might want to use alice in different rooms in the house so having concurrent sessions would make sense. Requires further considerations as to what the session should be bound to. e.g. room appears to be a logical approach, but leaves the question what happens when a user is walking into a new room while the session is still active
The text was updated successfully, but these errors were encountered:
since we are leaving snips behind we can change some things in the dialog flow. This issue is a lost of some ideas of what we could do better:
split sentences before sending them to the tts
when generating the sentences in multiple steps we can already generate them while alice says the previous sentence resulting in faster reactions from alice, since e.g. with the Who Are You question it takes a noticeable delay. This does not change pricing for online tts, since they are payed per character anyways
allow asr to listen while playing the feedback sound using some kind of acoustic echo cancelation we could directly react to alice while she still plays the feedback sound. This results in a faster reaction time for alice -> improves usability
add offline only intents right now when we use a online asr we will always use it unless we lose the internet connection. While I did not find a way for use to detect which one to use for the first intent (without serious time loss), it is rather simple for every other intent in a dialog flow. For these intents it could be specified by skill whether a intent should be offline only, since e.g. a YesOrNo intent absolutely requires no online asr. When all currently activated intents are offline only it could simply use an offline asr. This would be faster, since we do not have to send them over the internet, improve privacy for the user, since less audio recordings are send over the internet and reduce costs, since they do not have to pay for these simple speech to text conversions.
allow reactions while tts is speaking allowing reactions while alice speaks e.g. to cancel her speaking would be useful, even though this requires further considerations as to what would be the expected behaviour in different scenarios.
allow concurrent sessions people might want to use alice in different rooms in the house so having concurrent sessions would make sense. Requires further considerations as to what the session should be bound to. e.g. room appears to be a logical approach, but leaves the question what happens when a user is walking into a new room while the session is still active
The text was updated successfully, but these errors were encountered: