Like it has been said several times, that seems to confuse you the only bit missing is the Xmos USB version but also preferably with a daughter board for the mics.
When the Xmos is a USB microphone from ALSA to practically any high performance linux audio lib from pulse to gstreamer to even a simple netcat socket will bind to a snapcast server and as I keep saying the software already exists and no I don’t need to do any dev apart from the use of proprietory wyoming audio protocols that nothing but HA uses.
Respeaker Lite has USB support. There’s USB software for it. And it works on Windows/Mac.
You seem to be interested in writing, but not reading it seems.
I know about Wyoming protocol, and as i stated, i tried to use Wyoming satellite with recommended hardware. It’s lacking a lot of functionality. And even without additional things like Snapcast it’s barely usable (and definitely isn’t ready for mass-usage). Replacing Respeaker 2-mic hat with Respeaker Lite over USB would improve the voice recognition with AEC, for sure. But adding Snapcast there would be tricky.
So in the nutshell:
yes, Respeaker Lite is usable with USB
in theory, it would work with Pi (IDK about drivers tho)
Wyoming satellite is not ready for wide adoption
pairing satellite with music playback is pretty challengeable
No as I have repeatabilly asked and said I have no microcontroller experience, I am a Linux hacker at best.
I am wondering why the xmos chip that provides farfield audio through its mics is excluded from us Pi, Arm, X86 users and isn’t the simple USB device that you say it can be.
The libs provide a USB Audio Class 2.0 and USB Audio Class 1.0 which is plug and play on any Mac, Linux, Windows, Android, IOS and if you can think of another common OS them as well…
What do you think a USB Audio Class 2.0 and USB Audio Class 1.0 device is?
Here more detail even if its M$ providing it, but I don’t know for how long but practically all audio devices on all platforms have been plug&play because they are either audio class 2.0 or 1.0 devices which is very much a standard protocol.
We don’t need to know that as Xmos have already provided the libs, just configured, but that is microcontroller knowledge that you say is easy.
That is still to be done so no thanks I will not buy and try until someone who knows how to link and configure the USB audio libs of the xmos than using the I2S libs, my Pi will have to wait.
That’s what I’m talking about. You will complain and wait for someone to do things instead of biting a bullet yourself.
48kHz firmware for i2s exists only because I convinced Seeed devs personally, that it’s needed and possible to tackle.
Then I bothered Nabu devs for weeks to make their components more generic, so we could use it with Respeaker Lite.
Then I was trying and failing for weeks to get into DFU characteristics (with no experience in DFU, and almost no experience in C++) to make it working.
Will you do something instead of complains and theory?
OMG how many times do I have to say I am a Pi hacker not a microcontroller guru!
Hence why I am here asking if someone could so us Pi users are not exluded also!
@stuartiannaylor please respect that this specific thread has nothing to do with Raspberry Pi, so please start a new separate thread if you want to discuss that.
Yeah and as the original poster of this thread I am telling you that your discussion about using it as a USB microphone with a other computer like a Raspberry Pi is off-topic here.
This specific thread here that I started is about using ReSpeaker Lite as a Voice Assistant Development Kit hardware by combining ESP32 with XMOS XU316 DSP chip for advanced audio processing as a ESPHome-based Home Assistant Assist Satellite voice devkit.
My point is that this thread is about building an ESPHome based voice solution running on an ESP32, following the same concept as the official Home Assistant Voice Preview Edition.
Thank you for moving off-topic discussions about using it as a USB microphone to a other thread.
Device works great, however, do you have either an older yaml and/or firmware (48k) that supports openwakeword archived some place and available? Much prefer the capability of using my own wakewords.
Hi! Sorry, there’s no version without Microwakeword. I guess it’s doable, but i’d make completely separate YAML for that, to be honest. It was hell of a work to merge both things together (before, on old devices).
MicroWakeWord is a classic low compute KWS and they are lite and accurate, the moat bigdata has is that they have big data, especially ondevice capture of the few keyword they provide.
They have huge regional datasets using profile data as metadata.
MicroWakeWord is one of the KWS hacked out from google-research/kws_streaming at master · google-research/google-research · GitHub which on Arm I have done a fair bit of work with and if you have a rolling window to capture the KW on KW hit its fairly easy to capture in a window with a bit of a margin each side.
Bigdata annoyed everybody by just using your data and eventually brought in opt-outs, with certain data being under opt-ins, which I can see no problem with.
If people in the community wanted to help make the current WakeWords far more accurate, then opt-in and fill in some meta data that is purely demographics and not identity.
That gold standard data is absent in opensource, collate locally and send to HA…
OpenWakeWord is from a Google embedding model and paper https://arxiv.org/pdf/2002.01322 on how to train a KWS on synthetic data and approach the accuracy of the much lighter models in google-research/kws_streaming at master · google-research/google-research · GitHub
For some reason users of opensource want to have custom KW such as OpenWakeWord can use, whilst bigdata shy’s from this because of the bloated compute this uses. As its not just the KW which they have datasets of choice KW for the upsteam VoiceExtraction also has known KW in its dataset to increase accuracy.
Targetted Voice Extraction provides SotA speech enhancement results so the subsequent ASR and system can be also SotA. Its quite a heavy process but uses known datasets of known KW as like MicroWakeWord vs OpenWakeWord thoose model types run with far fewer parameters and are much lighter.
It doesn’t really matter at the moment as Speech Enhancement is purchased in with a general model on the Xmos, that suffers far more from the ‘Cocktail Party’ problem of multiple speakers, where it fails below what many Big Data systems can handle.
Even OpenWakeWord is far less accurate https://arxiv.org/pdf/2002.01322 than standard models but bigdata like its AI models has gold standard data and lots of it.
Custom models is nice have, but makes it much harder for Opensource to compete or be as accurate and needs more compute and often the model layers are too complex for certain microcontrollers, hence why OpenWakeWord is not used.
One positive message to say that my build is progressing well. I’m missing few pieces to have it all. I’ll do a pull request in the github to add. 3mf version of the print files.
@stuartiannaylor You are again trying to discuss off-topic things in this thread. This thread has nothibg to do with OpenWakeWord so start a separate thread if you want to discuss that. Stay on-topic if you want to discuss related things here.
