Kalliope client / server architecture

[bacardi55]

Hi

This is more a meta issue or at least a non urgent issue but something we should have in mind for the future.
I do believe that updating Kalliope to work as a client / server app could add multiple benefits:

• Installation of Kalliope "clients" in multiple rooms, but still leveraging only 1 brain and 1 configuration (server)
• Installation on powerful server while running the client Kalliope on "smaller" machines
• Avoiding duplication of brain files in each room where kalliope is installed.

[Sispheor]

Hi @bacardi55 . This is totally something we have in mind. And the last update of the API should help us in that way.
We will discuss about that for the next release.
We need to :

• identify the job of each part (client only forward the captured audio or process it directly with a STT, etc..)
• review the main controller to be server or client
• discuss about the implementation (TCP messages through a socket? Via the API?). This is the big deal in this feature for performance issue.

[bacardi55]

So I thought a bit about that… and i'm a big fan of the "release early / release often" methodology… so here are my thoughts:

• Doing this in multiple steps - 1st via API (simple and faster to do) - and maybe find a method with better performance latter on. That would speed the process and not touch current Kalliopé code in the first place (so like a 1st test)
• I would start with doing a small application outside of the existing Kalliopé code, to make it small and minimal (so it would run faster than the full kalliopé on a raspberrypi or even a raspberrypi 0 W). That application would only run snowboy to catch "kalliopé" and then send and audio file via the API, thanks to your PR in 4.4
• Main issue i see for client side, is that it will need to have an STT to say the returned info via API … Other option would be to return an audio file to the client, but that might be in a 2nd step as it would mean changing Kalliopé code to return an audio file. The client would then just need mplayer…

Just random thoughts in there :)

[Sispheor]

I did a couple tests for this.

• The API is a little bit slow. Passing through the HTTP protocol and the code take some precious milliseconds.
• Tested via MQTT protocol. Not bad. But finally, a client or a server will need to have kalliope installed. So I'm wondering if it's useful to implement this feature.

Maybe I could try to split the current audio part to make a "lib". This lib would be used as usual when installing kalliope core. But it could be installed as standalone.

[Sispheor]

I think this one will be the next big refactor of kalliope.
We need to be able to split the core from modules.
What we want:

• being able to start kalliope from multiple room
• being able to send messages from one module to another with a generic messaging method
• start kalliope with -client or -server flag
• centralize the config in the server side

After more concideration, MQTT seems the best choice for us. We need to plan a meeting to discuss about this part. AS it's a big change, we need to be sure of the new architecture.

[tigre-bleu]

I do not (yet) use Kalliope due to the fact that STT is required on the same machine as the microphone/speaker but the project looks interesting. Just to help the process of architecture making, here is my use case:

I have a rather powerfull central server in the house which is in the basement with no audio connection (neither speakers nor microphones).
I have multiple raspberrys in different rooms that have each one a speaker connected to (bluetooth or directly). Some of them have USB microphones (USB microphones are cheap and can be deployed easily on all RPIs).

What I expect from a software like Kalliope in the future:

• I should be able to use the powerful central server for brain and for offline STT/TTS computations (especially offline STT which is too ressource intensive for RPI zeros, and event RPI3. In the cloud STT is a 'no-go' for me for privacy reasons).
• Brain shall be centralized to prevent difficult configuration management across the RPIs
• Kalliope shall wake up on orders recorded by the 'remote' microphones on the RPIs.
• Depending on where the order comes from, the output shall either be broadcasted to the full house or just a single room (potentially not the same room as where the trigger came from. Here is an example to illustrate that: We could wake-up a child remotely by talking to his room from the parents room)

I'll follow this thread with care to see what architecture you are heading to :-)