I have been playing with GitHub - python-zeroconf/python-zeroconf: A pure python implementation of multicast DNS service discovery and it makes auto discovery super easy with just a very small script client /server.
In https://github.com/python-zeroconf/python-zeroconf/tree/master/examples its shows regustration browsing examples.
"_http._tcp.local.",
"Paul's Test Web Site._http._tcp.local."
Create a custom KWS server service _hakws._tcp.local Zone1._hakws._tcp.local or whatever.
In the more advanced https://github.com/python-zeroconf/python-zeroconf/blob/master/examples/async_registration.py
AsyncServiceInfo(
"_http._tcp.local.",
f"Paul's Test Web Site {i}._http._tcp.local.",
addresses=[socket.inet_aton("127.0.0.1")],
port=80,
properties={'path': '/~paulsm/'},
server=f"zcdemohost-{i}.local.",
There is a properties dictionary…
You can not really hardcode IP addresses as has been with wyoming as router adresses will periodically shed and renew leases.
Satelites should have the usual on new or long button press initialise search out for a server and wait for GUID identifier exchange which happens on enrollment and zone assignment.
Works on ESP32 also mDNS Service - ESP32 - — ESP-Protocols latest documentation
Its a standard non proprietory service where the only thing custom is service names that should be picked carefully so it doesn’t clash with other registered names such as…
HOMESHARING_SERVICE: str = "_appletv-v2._tcp.local."
DEVICE_SERVICE: str = "_touch-able._tcp.local."
MEDIAREMOTE_SERVICE: str = "_mediaremotetv._tcp.local."
AIRPLAY_SERVICE: str = "_airplay._tcp.local."
COMPANION_SERVICE: str = "_companion-link._tcp.local."
RAOP_SERVICE: str = "_raop._tcp.local."
AIRPORT_ADMIN_SERVICE: str = "_airport._tcp.local."
DEVICE_INFO_SERVICE: str = "_device-info._tcp.local."
Props is your protocol yaml of audio info and sub devices for registration but as a client relatively dumb that sends a conf yaml/json that is system agnostic and mapped to the driver registry of the KWS server.
GitHub - voice-engine/ec: Echo Canceller, part of Voice Engine project has opensource code of how a file ALSA PCM and credits the Snapcast named pipes implementation.
GitHub - voice-engine/alsa_plugin_fifo: An ALSA plugin, like the file plugin, but not requires a slave. has working example of both a sink/source of ALSA virtual mics and output. ALSA project - the C library reference: PCM (digital audio) plugins
Its just a file based ringbuffer that is registered as a standard Linux kernel PCM via system asound.conf or user based asoundrc, so that plug devices can do autoconversion and devices and apps can be system agnostic, Linux aware but nowadays is already ported to Windows & Android, but any virtual sink and source type can be used.
Server side the websockets audio stream creates a standard ALSA file plugin that is registered as a standard ALSA PCM.
Audio is presented as standard non proprietary for zero code implementations with 3rd party apps and modules…
File and stdout need to be merely cli ‘arecord’ to file or pipe to stdout and completely standard Linux kernel audio PCMs and utils for max compatibility and zero code use.
The text packet that isn’t embedded into the audio contains device control and handshaking that is for most parts a dumb client marshalled by the server.
Devices likely should have a QR URL indentity code that can be imported into a system registry without need of hardcoded defined protocol.
There is no real need for the concept as a satelite as everything is a device that is just a nested section of its parent json/yaml with its own unique QR URL indentity code that also is imported into a system registry.
A speech pipeline for most parts is a simple audio conveyor queue and route system where the same base container has an in/out server/client that will stream, route and queue.
This allows simplistic few instance containers to scale to complex multi-instance by reusing the same base container and chaining and routing to the complex if needed, simply by adding more instances in cases of high user load-balancing parallel routes, whilst maintaining complexity as a choice.
Its a standard based open protocol Linux speech pipline as opposed to proprietory branded protocol, so allowing use with any system and garnering a larger herd, maybe just LSP (Linux Speech Pipeline).