I am trying to get my head round rhasspy-satellite and if its wrongly named or I need to think of another infrasture name.
I probably had preconcieved ideas on what satellite should be and maybe being too specific but to enable a mode where voice clients have a really simple layout and are basically mic/speaker wifi satellites to a singular more powerfull SoC.
I have been playing with snapcast for this and it looks like it should very much fit the bill, I need to do actual tests of multiple clients on a host but think you can actually hardcode IP and Port if needed.
If I take a simple 2 satellite system of left/right speaker/mic broadcasting is just a standard snapcast where the channel of the stream are set.
Each satelite can also contain a server and the thing to test is multiple streams/instances client side as not sure if this can be a singular server or instance, but there is always docker to the rescue.
Each stream can go to a loopback and on the other side would just look like another alsa source.
So essentially that is my satelite mode and it has some advantages as audio processing load is pushed to the left/right satelites or however many you may include in a room.
I am looking at the collection of libraries for satellites only and wondering why you would need so much if these are satellite only
as it would seem to be practically a complete rhasspy install.
Even KWS is not needed on a satelite but an initialise KWS to an authoritive KWS brings some load advantages to the server if needed but everthing else should be server located and not satellite as its no advantage to satellite load.
By using snapcast you can vastly reduce latency as steams as they happen without the need for âvad silenceâ processing into wav chunks also the streams of multiple satellites are latency adjusted by the shared network time of the snapserver.
The multiple devices of the loopback can be aggregated via type multi
then routed and summed as a quick start, but would be great to maybe add some finnesse to the audio routing of satellites, but as base its ready to go.
Looking at the modules included in rhasspy-satellite is not rhasspy-mesh more appropriate?
As it would seem from the modules included a distributed mesh of modules might be the idea?
Naming isnât really a problem apart from maybe it might confuse but for want of a better name I have a very specific and what would seem a logical model for a rhasspby satellite that actually requires nothing of the current rhasspy-satellite repo and curious to what rhasspy-satellite is supposed to be?
I would like to take a look at adding rhasspy custom rpcjson to snapcast to include channel vad for channel selection and return back state signals that could be used for LED indication, but after that due to diversification of use and what I can think of thats a complete satellite system.