How I finally got LE Audio running on the ESP32-C6, steps that actually worked

Nov 07, 2026 Last reply: 3 hours ago 3 Replies

First reply

ForgePilot693

I got something similar running last month with a pair of cheap JBL earbuds and a C6 dev board on my desk, single chip setup. The audio works but I would echo the timing warning hard. My first attempt had constant little dropouts every few seconds until I bumped the sync…

Read the full reply

Been fighting this for weeks on my little handheld project and thought I'd dump what worked since the docs say it can't be done. The C6 radio does support the isochronous channels LE Audio needs, Espressif just never shipped the host stack for it. That gap is the whole problem.



The trick is splitting the job across two chips if you have them. I ran the stock C6 controller as-is and wrote a small CIS layer on top of it, then let the main chip handle the audio host side over HCI. If you're stuck with a single C6, it's still doable but the timing gets tighter, so start with the two-chip setup. Get a regular BLE connection to your earbuds first and confirm it before touching anything audio related. Biggest gotchas: the codec config has to match exactly what the earbuds advertise or you get silence with no error, and the reconnect logic needs to store the bond keys or you'll be re-pairing constantly. Also budget way more time for the sync timing than you think, that's where the dropouts came from for me. It's MIT licensed and up on GitHub, search esp32 le audio cis and you'll find it. If you get it running on other earbuds, post your results.


I got something similar running last month with a pair of cheap JBL earbuds and a C6 dev board on my desk, single chip setup. The audio works but I would echo the timing warning hard. My first attempt had constant little dropouts every few seconds until I bumped the sync interval up, then it settled down. I never got around to testing the two chip split because the single chip version was stable enough for my bench tests. The silent failure on codec mismatch burned me too, spent an afternoon assuming my radio config was broken when really the earbuds wanted a diferent frame duration than what I was sending. Once I logged what the buds actually advertised and matched it, sound came through on the first try. Reconnect handling I did differently, I just wrote the bond info to NVS right after pairing and that seems to hold across reboots so far. Curious what latency numbers other people are seeing, mine feels around 200ms which is fine for music but useless for anything interactive.

Tried the single chip build on a dev board with some old buds last week. Mine connected fine but I never got audio, so the codec mismatch thing might be my whole problem. Question though, when you log what the buds advertise, does that show up in a normal HCI trace or do you need to dig into the firmware side? Also wondering if the latency varies by codec frame duration, since mine feels sluggish even before sound worked, if that makes sense.

This lines up with what I've seen on my day job testing radio firmware. We ran a two chip split on an ESP32-C6 dev kit with a separate board doing the host side, and the HCI link over UART at 3 Mbps was the piece that needed the most babysitting. Flow control off and it'd silently drop command packets under load. Also the C6 controller build has to have the ISO features compiled in, the prebuilt binaries don't all include them, so check that before you blame your code.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required