• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

the new ESP32-C5 and P4 support 16 channel 32 bit TDM in full duplex

Hi, I will share the results on Gihub in a way or another. For the moment, it is back of the envelope tests to better understand the chip, software environment, software stack and performance.

And don't hesitate if you have questions I could have an answer to.
 
The Proof of Concept is now working for 8 channels 16 bits and 96k. Good ! It took some time because the ESP component is not design to achieve that bandwidth. You need to go the micro frames each 125 us. And the missing "Channel Config" in the descriptor was working up to 48k but not at 96k (Windows was starting/stopping/starting/ stopping... the device).

The MAX98357 I use for tests is limited to 96k. So next test is to move to 32bits instead of 16 bits. Then I will be at the limit for that CODEC.

The good news is that the load on the CPU is very low, even at 8ch 16bits 96k. I was afraid to have CPU load issues, but this is not the case. Possibly 15 CPU load on one of the 2 cores and 0 on the other ;-).

Channel 0 corresponds to TinyUSB writing the data to the application buffer
Channel 1 is the TinyUSB data reception each 125us
Channel 2 is the esp_i2s_write() it is blocked in "wait" most of the time

So next test with 32 bits, but there are several sections hard coded to 16 bits in the esp_device_uac() code.

This is not "clean" code. But seems to me that once proved to work OK on the POC, It shouldn't be a dramatic effort to have a robust code doing the 8 channels / fixed number of bits / different sampling frequencies. A bit more complex to allow the switch between 16 and 32 bits.
 

Attachments

  • Capture 8ch 16-bits 96k .jpg
    Capture 8ch 16-bits 96k .jpg
    181.2 KB · Views: 98
I am very interested in your progress for my project !

You mention that the CPU load is very low for processing of 8 channels (15 % (?) on 1 core out of 2). Do you believe the C5 which is single Core would be able to manage similar load?
I would have some additional load from the WiFI transmission as well but I still have the possibility to break down into sub-streams (2*4 channels).

As well, if you are interested in more capable Class D amps, I have listed a few here: i2s Class D Amps
 
Hello Glider95,
It depends I imagine on what you expect the system to do. If you wand the audio to come from USB or Wifi, and the architecture of the system. I don't know the Esp32-C5 but what is needed on my side is a i2s peripheral that can manage TDM 32bits 8channels , and an audio PLL (APLL) which can reach very high frequencies (240MHz for P4). IS it the case for the C5 ? The major point for the P4 is the High Speed USB Phy which is absolutly needed for this type of expected bandwitdh for an USB to i2s bridge

By the way, Waveshare propose modules that integrate a P4 and a C6 for around 10€.
 
House revonation => little progress on the ESP32-P4 tests.... but, still:
  • Based on feedback on the espressif forum, the improve the components. So easier now to rely on n-1 TinyUSB stack, configure bit depth and sampling freq. I have the feeling that less adaptations will be needed to build the usb to i2s bridge,
  • I just discovered this: https://developer.espressif.com/blog/2026/06/aes67-audio-over-ip-on-the-esp32-p4/ This looks really promising for active speakers :-) (even if not finalized and 48k),
  • the ESP32-S31 will have wireless network connectivity and high speed USB Phy. Another challenger for the purpose.
The ESP32 is not perfect audio platform, but the software ecosystem for audio is of interest.

JMF
 
jmf11 said:
I just discovered this: https://developer.espressif.com/blog/2026/06/aes67-audio-over-ip-on-the-esp32-p4/ This looks really promising for active speakers :-) (even if not finalized and 48k),
Click to expand...
That is extremely interesting, thanks! Because that hardware/code uses a PLL for master I2S clock, finely tuned to continually adjust to the incoming stream of samples. Unlike the vast majority of audio interfaces with fixed clock which require ASRC between the incoming and outgoing streams, adding latency and complexity.
 
Slow progress on the project... No much free time at the moment, when this type of activity asks for dedication and focus (at least for me).

Esp has fixed some issues, released new versions of the software components and a new version of the development environment.

I ported the code and cleaned a bit the proof of concept. It currently works with Stereo 32bits 96k and 8 channels 16 bits and 48k with the new versions. I use the APLL clock.

I try to get 8 channels and 32 bits to work, but still not there. Windows seems du recognize the device with correct characteristics. In the parameters, I can test the device and it seems to play the sound, but the alt setting is not actionned.

This type of use case with many channels and 32 bits, TDM spécific mode hits several limits here and there in espressif code. Sort of Uncharted territory for the esp_codec_dev and usb_device_uac components.

Espressif is releasing Esp32-S31 Wroom modules with similar CPU and Usb HS PHY. This would be perfect for this use case.
 
  • Like
Reactions: MCH
Yeah, the new esp32-s31 and e22 come also with audio Bluetooth.
 
8 channels 32bits and 48k is working (proof of concept). Increasing the Sampling Frequency to 96k raises some errors in the clock configuration, like if max freq was exceeded. But from that I read in the reference, it shouldn't be the case. I try to investigate the case on the espressif forum.
 
  • Like
Reactions: MCH
Last edited:
fyi seems that the new and definitive (?) revision of the esp32-p4 boards was important enough that espressif even gave it a new name. From chip version 3.1 on they are called ESP32-P4X.
I am guessing it won't have any detrimental effect on the projects mentioned here but be aware if your boards are a few months old @jmf11
 
Last edited:
The technical reference manual has been updated and the max frequency on the APLL changed to 125MHz. I rechecked the clock scheme and the minimum dividers possible to use, and I understand that it is for Master mode a minimum 6 divider between the APLL and bclk: 20.8MHz.

This means 8 channels 32 bits 48k limit. But possibly 8 channels 24 bits in 24 bits slots 96k.

For slave mode, the min multiplier should be 2*8... So very limiting for multi channels applications.

The MAX98357 can only deal with TDM 8 channels 16/32 bits slots and up to 96k. So it won't be possible to explore much further with that chip. Have to move to ES9081...
 
  • Like
Reactions: MCH
I'm thinking to the next step. After my experiments, I feel that the Esp32-P4 is OK for audio applications, but not completely fine either:
Pros:
- price-performance ratio (2 cores at 360MHz, flash mem and ram...)
- internal USB HS Phy
- dedicated software components for USB and Audio (better than stm32 side),
- IDE working well in vs code, and overall good development experience (even for not experience one like me),
- availability of cheap boards and modules on Aliexpress,

Cons:
- I2S peripheral lag behind stm32 SAI,
- clock multipliers introduce limitations when targeting high sampling rates, or 8ch 32 bits.

The Esp32-S31 could be a challenger, but with the same i2s peripheral and an APLL limited to 96MHz (instead of 125MHz for the P4). So could be more limited in bit rate.


Alternative could be the stm32H5 or H7:
Pros:
- Best SAI: possibility to synchronize the different channels,
- seems better clock schemes,
- best support for Rust (I would like to learn embedded Rust),

Cons:
- No off the shelf USB to i2s components,
- Price,
- External USB HS ULPI if not using one of the few MCU with an internal one,
- no "modules" to solder on PCB like the ESP32 ones.

More expensive but looks like the safest option, at about x3 times the price of chip cost.


Challenger: CH32H417 (or CH32V315)
- a SAI to be explored to see how it competes with the stm32 one
- powerful MCU
- price,
- internal USB HS Phy

Cons:
- much smaller eco system,
- lower level API,
- smaller community,
- has to dig more in the reference manual to move forward,
- TinyUSB not available yet on that MCU

For pro or adventurous ? I will keep an eye on this option, but for the moment, looks better to resist to the appeal :-)
 
  • Like
Reactions: MCH
I have been on vacations for 2 weeks, with some time to think about this. I'm definitively not comfortable with going ahead with the ESP32-P4 for 8 channels, 24 or 32 bits and more than 48kHz sampling rates. The I2S peripheral seems the limiting factor with too high multiplying factors for the MCLK, which is 1) capped to lower freq than initial dataseet values 2) generates EMI 3) puts more constraints on PCB or connectors.

The CH32H417 is appealing but no support yet by TinyUSB. The little brother CH32V315 isn't recommended by TinyUSB for audio applications as could loose frames.

The stm32H7R3 has embedded HS Phy, exists in packages usable in DIY context, seems cost effective, even if it needs external flash. I think I will go that way.

I would like to "finalize" my usb multichannel quest, but I think that Weelab DSPi changes a bit the game. Having a powerful DSP tool working on super cheap and easy to integrate MCU, with multichannel out, with stereo USB in, ticks most of the boxes. With that architecture, no multichannel USB needed anymore. CamillaDSP or windows alternatives are no more the only ways.
 
  • Like
Reactions: MCH
jmf11 said:
I have been on vacations for 2 weeks, with some time to think about this. I'm definitively not comfortable with going ahead with the ESP32-P4 for 8 channels, 24 or 32 bits and more than 48kHz sampling rates. The I2S peripheral seems the limiting factor with too high multiplying factors for the MCLK, which is 1) capped to lower freq than initial dataseet values 2) generates EMI 3) puts more constraints on PCB or connectors.

The CH32H417 is appealing but no support yet by TinyUSB. The little brother CH32V315 isn't recommended by TinyUSB for audio applications as could loose frames.

The stm32H7R3 has embedded HS Phy, exists in packages usable in DIY context, seems cost effective, even if it needs external flash. I think I will go that way.

I would like to "finalize" my usb multichannel quest, but I think that Weelab DSPi changes a bit the game. Having a powerful DSP tool working on super cheap and easy to integrate MCU, with multichannel out, with stereo USB in, ticks most of the boxes. With that architecture, no multichannel USB needed anymore. CamillaDSP or windows alternatives are no more the only ways.
Click to expand...
Makes sense, thanks a lot for reporting your progress.
Note that @Weeb Labs was looking to do something with the stm32h7 series, don't know if he still plans to go ahead...
 
You must log in or register to reply here.
Back
Top Bottom