Closed 0x0fe closed 9 months ago
i solved the mystery of audio playback issue, apparently it was necessary to call the setpinout and functions for set_mclk_pin_select even though they were already hardcoded in the library. Now the audio is back.
audio.setPinout(BCK, WS, DAT);
audio.i2s_mclk_pin_select(MCK);
Strange things can happen there. If you put audio.loop() in a separate task, it is advisable to use message queues for communication. This increases reliability. https://github.com/schreibfaul1/ESP32-audioI2S/blob/master/examples/separate_audiotask/separate_audiotask.ino
I have similar problem and his solution does not work for me, however i have found some values that does not produce sample rate too high error. MCU still restarts
imo, this library should expose m_i2s_config
in some way
I am currently trying
m_i2s_num = i2sPort; // i2s port number
m_i2s_config.sample_rate = 44100; //48000;//16000;
m_i2s_config.bits_per_sample = I2S_BITS_PER_SAMPLE_16BIT;
m_i2s_config.channel_format = I2S_CHANNEL_FMT_RIGHT_LEFT;
m_i2s_config.intr_alloc_flags = ESP_INTR_FLAG_LEVEL1; // high interrupt priority
m_i2s_config.dma_buf_count = 8; // max buffers
m_i2s_config.dma_buf_len = 1024; // max value
m_i2s_config.use_apll = APLL_DISABLE; // must be disabled in V2.0.1-RC1
m_i2s_config.tx_desc_auto_clear = true; // new in V1.0.1
m_i2s_config.mclk_multiple = I2S_MCLK_MULTIPLE_DEFAULT; // new in V1.0.1
m_i2s_config.fixed_mclk = 0;//I2S_PIN_NO_CHANGE; //48000*256;//
@schreibfaul1 yes that is what i ended up doing, having a separate tasks and communicating with it via message queue. I noticed that the MP3 EOF callabck has to call direct function though, otherwise it locks up, but it makes sense since this callback is actually called from the thread itself.
@pwilkowski You can do what i mention, it is stable. Just be careful to call functions directly when the caller is the audio thread, in all other cases use mesasge queues.
Regarding the issues with Setup in PIO, i assume the setup function is not called as early as in arduino implementation and for this reason the WDT can easily get triggered. My solution for now is to initilize most things in their own thread, with basic signaling to avoid run conditions. There is still problems with PIO but msot are solved when using a spearate thread and messagequeues.
I'm not sure if I understood the question correctly. For example, if EOF performs an action on a device that is already occupied by another task, collisions will occur and strange errors will occur. To avoid this, a task must wait until the device is free. Semaphores are usually used for this.
SemaphoreHandle_t mutex_dev;
void setup(){
...
mutex_dev = xSemaphoreCreateMutex();
}
void do_something(){
xSemaphoreTake(mutex_dev, portMAX_DELAY);
// .....
xSemaphoreGive(mutex_dev);
}
void audio_eof_mp3(const char *info){
do_something();
}
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.
I had to move a firmware from arduino to PIO in order to have a decently easy way to modify the IDF configuration, in particular for allowing memory allocation on PSRAM (SPIRAM) for mbedTLS, wifi and BT stack, and also to improve the wifi throughput. However to my surprise, what was perfectly working on arduino (2.0.8) proved to not work at all on PIO, i made a test firmware to demonstate the problem.
PIO configuration
The test firmware is quite straightforward : One thread start an audio streaming/decoding to I2S of an mp3 file (HTTPS) Another thread starts a download of another (or the same) file, and save it to SD card which is in SDIO 1-bit mode. This continues in loop, each time a downlaod is finished it starts a new one, each time a stream is finished it starts a new one, both are rolling a set of 3 urls.
The board is fitted with ESP32D0WDR2 which is identical to the "legacy" ESP32D except it has 2MB of internal PSRAM. It has an audio codec rather than a simple DAC (for various reasons) however i believe the problem can be reproduced with any DAC, it has nothing to do with the specific codec i use. In the code below i commented the calls specific to my codec, so that it can be tested with any DAC.
The issues :
The first issue is : when i declare the Audio audio object normally (on top of the main.cpp) the esp will just crash at early boot, complaning about the sample rate, incorrect pins and problem with MCLK. Strangely enough it will mke the sd_mmc to systematically crash as well (probably related to DMA). I am not sure what causes this because in Arduino the exact same firmware and library are used, and there is no problem at all with the initialisation of the library. I believe this has to do with how PIO has implemented the early calls, and also hwo it manages the setup() function, which is clearly differnt from how it is managed in arduino (hence the need to disable watchdog on core 1, which is not the case for arduino). I suspect maybe these object are initialized before the I2S driver or the PSRAM is ready for example. Anyway to go ahread i tried to hardcode the pins number, samplerate and set a fixed MCLK configuration directly in Audio::Audio, which seems to work since i got no error reported after this change.
Then comes the other issue, when i modify this, i got no error at init, and everything seems to work correctly (stream, download) however, there is no audio, at all.
When i run the exact same code with the exact same library and arduino core (2.0.8) directly from the Arduino IDE, the output is exactly the same however the audio works perfectly fine.
Here is the snippet, it can be run directly, the MP3 files are from a free to use source, just set the wifi credentials and flash. I believe the GPIOs used for I2S are irrelevant to the problem, except the MCLK which is fixed (currently set to pin 3, hence why the Serial object is initialized in TX only).
here is the sdkconfig, in case