Base / Satellite configuration

Yes this is solved if you install the snips-satellite package instead of snips-audio-server. This package unites snips-audio-server and snips-hotword.

Yes that’s what I did two updates ago !

Maybe it is an internal brocker not flowing on the network. It’s not between satellites and master, strange.

But well, another problem lol, hope I will be able to migrate to rhasspy in production soon !

I am new to rhasspy having been forced to look for alternatives after the snips disaster. One thing I feel snips had going for it’s master/satellite setup was the idea of context.

instead of just a site_id. The satellites could be identified by things like “what room.” This could be utilized in whatever you are using to handle your intents.

For example “turn off the lights” But which lights? Missing a slot of “location” but your processor could also look at the slot “satelliteID” and see “living_room”

Now your intent processor knows the intent is to turn off lights, and where the request came from. So you could have it turn off the living room lights. But if you said “turn off living room lights” but you were in the kitchen, you have provided the location slot already. So the satellite_id isn’t used.

This “location” context was very appealing to me as it allowed me to not only create multiple listeners/responders but also to have location based context.

Not sure if that type of concept is in the works with rhasspy, but so far it seems to be a REALLY good offline “true” open source option.

1 Like

This is exactly what siteId is for. siteId is in wakeword detected and intent recognized payload, so you can test for room slot and if not, use siteId.

Actually rhasspy doesn’t really need it without working master/satellite configuration, but all is there and working for such context.

siteId is also usefull for the opposite, send tts text to one room.

4 Likes

A post was merged into an existing topic: Fully support the Hermes or Hermod protocol

Thank you, @CrankyCoder and @KiboOst !! I was coming to ask a similar question. Now, if only someone could document an example and post it here. (hint, hint!) I’d do it right now, but cannot reach into my home network from work. :frowning:

1 Like

I honestly believe Rhasspy is going to be hugely sucessful because of federation to services as other packages start creak with the all-in-one aka Wordperfect bloat problem.

Also the sattelite mode is a very performance/cost effective natural product model.

I am still confused that media playback is and will be a major mode of use for AI especially in domestic Rhasspy style adoptions.
Without AEC, VAD doesn’t matter as the Mic source is saturated with media echo, without AEC any media will not be stopped by voice in an arena that is flooded by media.
I guess a stop button on a satelite might be a welcome option, but its slightly contary to what Voice AI is supposed to be.

Yes its me ranting on about AEC but I am honestly confused that more isn’t stripped from the satelite model.
The satelite model is so simple that its purely a audio streamer that is connected to a an input stream and on KWS initiates an output stream.
Apart from LED control and authoritive overrides it doesn’t need to serve any other purpose.
Also much can be embedded into the metadata of an audio stream that no further control protocol is required.

Can I ask honestly why Hermes always seems to surface when it seems to lack channel, latency and compression techniques that are surely essential in room multichannel audio and wide array microphone systems?

Its not that its just simpler to use snapcast it would seem to my noob initial appreciation hermes-audio is lacking essential functionality and splitting and sending as wav’s also is a large network overhead.

Audio output from satelites is just a matter of being a snapcast client.
Audio output from a base is like any other audio provider and just connects to a snapcast server.

Mic audio output means each satelite is a snapcast server and a base needs to be able to run concurrent snapcast mic clients.

As @banderson mentioned I think it is better to target a device due to how simplistic those needs are and the lack of multiple services it requires.

As I say I am loving the efforts to federate service with Rhasspy but confused at the percieved complexity that seems to be being attached to satelites?

A satelite just has a initiate KWS and snapcast service and if media is to be played it needs audio processing such as AEC.
Due to diversification of use the server model of a base of complex functionality serving simple clients of specific function is vastly more cost effective and possible?

Wish snapcast was a little better document the json rpc seems like it would cover all needs for satellites.