Snapcast is not like what you describe with Wyoming as its clients work as the software is mature and production ready for a long time from its initial dev of a decade or more ago? The licence in the repo is 10 years old…
Add snapcast on a Pi it works…
But yeah on ESP32 it would be a massive dev investment, but 2 repos as above do exist.
You’re not stopping there i see… 
When you try to merge two or more technologies, that are working with same set of hardware (e.g. speaker in this case), the amount of edge cases to solve isn’t arithmetical progression, it’s exponential.
If you’re saying it’s easy and doable - i think you can do it. Pi + Respeaker Lite via USB is sufficient hardware, and you already have all the software you need. Please do it, i will be first to test.
I don’t dev on Xmos or micro-controller as too low level.
I had a look at the Xmos docs to try and workout what they where using for speech enhancement it it could be some form of conv-tas-net.
I did notice the USB audio device software exists in there repo’s, so likely it could make USB device with maybe the 2 mics on a 70mm daughter board with maybe balanced line drivers.
Its you who are saying microcontroller dev is easier.
The esphome people have managed the other libs so presume the usb audio lib is equally possible, but that is for the microcontroller lower level dev than me.
Likely I would be better with 2 channel audio via a usb soundcard and see how well a 2 channel conv-tas-net works and quantises on a Pi using the tensorflow toolset and already existing repos.
I doubt I will as sort of confused at where VA is going at the moment but you could prob drop the Xmos on a Pi but the AEC on the Xmos seems to work super well.
There is a lack of low level audio DSP in the community hence why the Xmos and libs is purchased in.
Ok, i hardly understand what was written, but i assume you won’t write anything.
Let’s keep this thread clean. The discussion cam be started in HA discord, or in dedicated topic here.
I am talking about the respeaker lite which is based on the Xmos chip and its libs.
If you don’t understand a comment about the very hardware in the title of a thread then maybe, you just should not comment.
fwk_voice/modules/lib_aec at main · xmos/fwk_voice · GitHub (Acoustic Echo Cancellation) seems to work well on the xmos chips which doesn’t seem true with the linux libs of web_rtc or Speex.
Its got something to do with the Rtos of a microcontroller with exact routine times than a scheduled OS such as linux preempt does not.
The bit of magic of the farfield processing might actually be a tflite model that may run on a pi or once more might be better on a rtos.
We do seem to have a lack of audio DSP in the community and as said hence why the Xmos and libs are purchased in.
Talking specifically about this hardware where the ref designs shows it supports USB Audio Class 2.0 and USB Audio Class 1.0
This is exactly my point and why it should be here as rather than restricting the xmos316 through its I2S to the constraints of an ESP32-S3 running software that doesn’t care if on a RTOS or preemptOS it could use its USB interface where there are no constraints in comparison from a N100 Nuc, to Mac Mini to Pi USB Audio Class 2.0 and USB Audio Class 1.0 are cross platform standards.
You could even have multiple X316 devices on your choice of platform.
So you get the best of both worlds with the DSP that seems to prefer an RTOS and without the shackles of just another microcontroller such as the ESP32-S3.
It would still have the mics but on a daughter board by a 3.5mm jack and the headphone out still being a 3.5mm jack, but essentially look like a USB soundcard that comes with a wired 2mic microphone…
That way all these requests for further functionality are no problem as long running code already exists, by simply getting rid of the esp32-S3 and utilising the XMOS USB audio libs…
Reason why here is the ESP32 and microcontroller nerds and guru’s are the very people who could make the Xmos be a soundcard for Arm and X86 devices.
ESPhome if you wish make a constrained version using a ESP32-S3, do so, but if you are doing dev work with the XMOS maybe have a look at dropping the ESP32-S3 and using the XMOS libs so it is a USB device so it can be used on a wide range of much more powerfull devices…
So its not just for @formatBCE who doesn’t seem to know what the ‘Respeaker Lite’ is but also if there are any dev’s who do, maybe the USB device might catch favor…
What I hope/wish is that both Nabu Casa / Home Assistant developers and Espressif get behind and become a driving force for the new “Matter Casting” (“Matter Casting Client”) standard in Home Assistant, ESPHome, Music Assistant for standardized media playback on their Voice Assistants.
I also read about matter but if you read Streaming smart speakers are on track to come to Matter - The Verge
What Matter probably won’t do is enable multiroom music, a feature likely to remain at the ecosystem level. Additionally, don’t hold out hope that Apple and Google, and possibly Amazon, will enable their speakers as Matter device types. While it’s technically possible with Matter, controlling your Apple HomePod from your Google Nest Hub just doesn’t feel likely. I’d love to be proven wrong, though.
All three companies have been bullish about Matter as an industry collaboration, but I can see Apple and Google drawing the line at making their speakers interoperable with competitors outside of their ecosystems. However, Amazon may be more open to the idea, as it has already implemented Matter Casting for its Prime Video service as a nonproprietary alternative to AirPlay and Chromecast for streaming video.
So dunno as casting to different ecospheres, is a pain but likely to continue and for me that is what HA should be. A cast controller to enable different types and conversion as it does with so many device protocols but the actual media player should be the best of open source and again choice. I doubt many may opensource the cast source code, but guess we will have to wait and see.
I don’t have trouble in technical part of your thoughts. I struggle with your grammar and unfinished sentences.
Your theory is very… interesting… And I tried to use Respeaker Lite via USB, it works. What I imply is - there’s no practical solution to the problem you describe. No software, that will bind Snapcast, VA and Respeaker on Pi platform together, and connect that to the HA.
So since you claim to be pretty experienced in it, I’m asking to start making it instead of theoretizing.
Wow, that’s nice thing!
Why would I? When obviously you don’t know but it already exists. Getting started - Local - Home Assistant
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. 
If we speak about Respeaker Lite board, and it has USB interface with USB firmware - why not to use it as is on Pi?
The usb DFU driver is done ReSpeaker_Lite/xmos_firmwares/respeaker_lite_usb_dfu_firmware_v2.0.7.bin at d272ef8059b7f39dbadb9d791b67a75ecd4b6dbd · respeaker/ReSpeaker_Lite · GitHub
- USB 48K Firmware: TODO
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.
1 Like
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?
I lost the interest in this conversation. Bye.
4 Likes
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!
Deep breath, lols…
@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.
I am asking if the microcontroller guys could enable the usb audio drivers on the respeaker lite, ie the title thread.
Ugh, was happy to see so many new messages in the thread but it was just someone complaining.
User mads03dk har started something here on snapcast for esphome.
I’m so sad I don’t have the experience to even know where to start helping unfortunatly. I know some simple Python, yaml and matlab and that’s it.
1 Like
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.
Please respect that!
2 Likes