ESP32 client is being made

[monte-monte]

Maybe it's a wrong place to post it, but I wanted to attract attention to the fact that Jørgen Jakobsen has wrote a ESP32 client for snapcast: https://github.com/jorgenkraghjakobsen/snapclient

I haven't tested it myself but he reports that it works smoothly. The only thing for now is that he uses uncommon i2s dac/amplifier that makes it hard to try his code without additional work to adapt it to something more common (if I understand correctly).
Hope to see ESP32 support in mainline sometime.

[miLORD1337]

Yep, see #520

[badaix]

I'm aware of Jørgen's project and I'm really excited about it!
But I don't see official support now in context of this "mainline" project. This (badaix/Snapcast) is just one (C++) implementation of the Snapcast protocol, while Jørgen's Snapclient is a C implementation for the ESP32 SoC (the real bare metal embedded stuff - ARM is for beginners 😉 ).
And there is yet another Snapclient implementation in Python available.
I think the best we can do at the moment to support each other is to add links to the project's Readme files.

[jorgenkraghjakobsen]

Yes - My implementation is still work in progress and ESP-IDF FreeRTOS tailored code. I use the library https://github.com/bridadan/libsnapcast that @bridadan has created and yes I use an odd codec/amplifier because I made one my self :-)

I also ripped it out of the ESP32 ADF (Audio framework) - be cause I have something better in the making as well. One day it mite get back when code start to mature.

All my respect goes to Badaix who is the goal keeper of the protocol and concepts. His C++ implementation is highly abstracted and space grade build. Not easy for me to follow as I am just an IC designer and use to build thing from custom made transistors, resistors and caps.

But the code is a good reference model and I am getting there feature by feature.

Add the end of my tunnel is see an snapclient ESP-IDF component that do partial protocol support and fit into an open source multiroom audio streaming eco system.
/J

[StuartIanNaylor]

@jorgenkraghjakobsen That would be so great as had the idea but the implentation never got further than the ESP32-Audio-Kit board that has been gathering dust for some time.

PS my alternative was a https://wiki.radxa.com/RockpiS which is sort of Pi ZeroW price with built in audio codec and also an Cortex-A35.
PS my interest is Voice AI where speaker satellites are both media capable multi-channel audio that also mic capable.
It would be so good if a client could have multiple instances and be able to connect to multiple servers and output through different sink devices.
Thinking of using docker and loopbacks as read with a single instance this is not possible?

Would be great to see ESP32-Snapcast as thought the same but for any others those Rockchip RK3308 chips are also great value.
Would also be great to get a Aaarch64 as can compile but a .deb would be great.

[jorgenkraghjakobsen]

That RockpiS is cute - But much bigger power and system footprint the needed for a snapclient.

[monte-monte]

@StuartIanNaylor I want to try MT7688 it's the chipset that is used in Onion Omega 2, and is available in bare modules similar to ESP32 (only slightly bigger) for around 10$. It runs Openwrt which already has snapcast in its repository and has I2S for external DAC.
But anyway ESP32 would be so much more accessible for simple projects and due to its low price and wide availability it can be a single-function device

[StuartIanNaylor]

That RockpiS is cute - But much bigger power and system footprint the needed for a snapclient.

@jorgenkraghjakobsen
Guess so but it does have embedded single channel VAD that wakes it from deep sleep its actually quite low power when not providing service.
But ESP32-audio-kit would be great and bow down to your efforts as looked at was entailed and far, far too much for me :)

@monte-monte
I just purchased a a 512mb RockpiS for $13.99 and you prob want to take a look at the spec sheet.
https://dl.radxa.com/rockpis/docs/hw/datasheets/Rockchip%20RK3308TRM%20V1.1%20Part1-20180810.pdf

Its not a general purpose arm chip its a specific low price audio soc very similar to the allwinner R328 but cortex-a35.
Its sort of great for me as it has enough oomf to do software AEC without hardware DSP.
The ESP-32-Audio-Kit was $1-2 cheaper I think and don't think there is much difference in accessability or price as a single function device, that is why I mentioned.
Its also almost a quarter of the size of my ESP-32-audio kit board.
I found the RockPiS after thinking I will never dev a working solution on ESP-32 and why I can only steal the great work and thunder of the likes of @badaix

Chapter 8 Audio Codec
8
8.1 Overview
Audio Codec is a low power, high resolution, stereo CODEC solution which employs SigmaDelta noise-shaping technique. The ADC, DAC and power amplifier are integrated to provide
total solutions. With 24 bits resolution for DAC and 24 bits resolution for ADC, Audio Codec
is suitable for applications in high end consumer digital audio systems, automobile audio,
multimedia and digital systems. It supports following features:
 24 bits DAC with 93dB(A-weighted) SNR
 Support 16~32Ω headphone out and 10kΩ line output
 24 bits ADC with 92dB(A-weighted) SNR
 Support single-ended or differential microphone input
 Automatic Level Control (ALC) for smooth audio recording
 Pure logic process: no need for mixed signal layers and less mask cost
 Low power: DAC 3mA per channel, ADC 2.5mA per channel, less than 0.05mA for
standby
 Support Mono, Stereo, 5.1 and 7.1 HiFi channel performance
 Programmable input and output analog gains
 Digital interpolation and decimation filter integrated
 Sampling rate of
8kHz/11.025kHz/12kHz/16kHz/22.05kHz/24kHz/32kHz/44.1kHz/48kHz/64kHz/88.2kHz
/96kHz/128kHz/176.4kHz/192kHz
 1.8V supply for analog and 1.0V supply for digital

[jorgenkraghjakobsen]

Hi All
I succeeded add a large sample buffer to the ESP32 client.
On ESP32 with external ram the buffer will be allocated in PSRAM and allow all the buffers sized needed.
On ESP32 with internal ram we can do only around 200 ms - Snapcast is default 1000ms with a minimum of 400 ms.
My code has been updated to current ESP-IDF release and builds using legacy make and new Cmake/ninja build flow.
Still a lot of coding to be done - but added a dynamic second size buffer has been that last task on prove of concept. /Jakobsen

[palitu]

Awesome! Well done!

[miLORD1337]

On ESP32 with external ram
On ESP32 with internal ram

Just a quick sum up buyers guide:
WROVER has 8 MB of PSRAM
WROOM has no PSRAM

So if you want to be on the safe side regarding buffering, definitely go for the WROVER.

[badaix]

FYI just read about this ESP32 based audio kit in the news:
https://www.aliexpress.com/i/32957553086.html?spm=a2g0x.12057483.1000001.8.72af21fdeYSPU0

[TekniskSupport]

Looks very similar to the LyraT from espressif
https://www.mouser.com/Search/Refine?Keyword=lyraT

[palitu]

that looks promising for a low cost device! includes 3W ampl it would seem,

[oliv3r]

I really tried going down this route, first by just trying to see if I can run the standard esphome media player. While some streams work, it looks like (for at least wroom32; i'll try to get my hands on some wrover32 modules) the poor ESP32 seems to be slightly too weak. I can open an mp3 stream, to find most of them to be stuttering and playing back to slow. (google) tts seems to work; but that's also just an mp3 of course. Compression probably matters a lot here obviously.

Has anybody else had any luck/explored this further? I'm running snapcast client on an opewrt access point with an USB speaker, which is working quite well. But ESP32 seems like it might simply not handle useable codecs. @jorgenkraghjakobsen seems to also have abbandoned his repo ...

[StuartIanNaylor]

Nope think was only @jorgenkraghjakobsen but also Rpi0, Radxa tried to make an audio specific low cost Arm board RockPi S but the support for that board is pretty bad.
I think jorgenkraghjakobsen hit a brick wall of not enough cpu as it is 2 cores but its better not overload the wifi/bt core.
Likely the S3 that has some vector instructions where certain FFT ops are x10 faster could do the job.
https://docs.espressif.com/projects/esp-dsp/en/latest/esp32/esp-dsp-benchmarks.html

[miLORD1337]

I think Jørgen hit a roadblock, because he was trying to mostly use IDF and ADF provided by espressif. The breakthrough I think was, when @bridadan decided to ditch ADF and re-implement the playback/buffering/timing from scratch. @CarlosDerSeher then took it from there. He even just ported it to IDF5. Really nice work by all of them! 🚀

Check it out: https://github.com/CarlosDerSeher/snapclient

Edit: Or was it Carlos who ditched ADF and reimplemented everything? Can't remember anymore. Sorry if I mixed things up here.

[bridadan]

Oh I didn't realize this was taken this far, nice work to all involved! I think my proof of concept used the ADF still. Nice work @CarlosDerSeher for actually making it all functional!

[CarlosDerSeher]

You are welcome, though it isn't really all functional as you can see from the issues. But it still can be used as a daily driver for your speakers :)

[oliv3r]

Ironically I had a tab open 'somewhere' in one of my browser windows :p But I had forgotten you. Now that your name and repo is mentioned on this discussion topic, I can continue with that approach again :D