A small piece at the beginning of an MP3 track is not played back in a certain constellation

[anp59]

When playing a playlist, I have noticed that in some cases the first, perhaps 100, milliseconds of an mp3 track are not played (audible). connecttoFS(...) for the next track is called after the EOF notification of the previous track (call of the function audio_eof_mp3). My initial investigations have shown that this case occurs after playback of certain mp3 files that contain embedded images. As an experiment, the images were removed with Mp3tag - with the same result, as Mp3tag only overwrites the data with zeros. Removing all ID3 metadata (export with audacity), the described behavior does not occur. It is also noticeable that the change to the next track takes a little longer in this case. I can provide the MP3 files used and the source code via cloud for testing purposes. Best regards Andreas

[anp59]

One more, perhaps important addendum: If the title is canceled before the end with stopSong() and the next title is called up immediately afterwards, the error does not occur.

[schreibfaul1]

It is difficult for me to reproduce the error. The 0.1s could indicate the I2S DMA. I have this file Pulse_1.mp3.zip called up after the EOF.

void audio_eof_mp3(const char *info){  //end of file
    Serial.print("eof_mp3     ");Serial.println(info);
    static uint8_t i = 0;
    i++;
    if(i == 1) audio.connecttoFS(SD_MMC, "/Pulse_1.mp3");
    if(i == 2) audio.connecttoFS(SD_MMC, "/Pulse_1.mp3");
}

That seems to be okay.

[anp59]

Hi, I have found out that it may have something to do with the length of the songs. I have attached my test program (PlatformIO). A zip file with the playlist data has a size of 3 MB. I can send it by mail. The titles of the playlist are shortened. I have also inserted a pause before the start of a new song. The file Pulse_1.mp3 was edited for the test: 500ms pause inserted at the beginning and the length of the last tone halved.
Two exclamation marks in the playlist indicate the error. I get the same result on an ESP32 S3.

Greetings Andreas ESP32-audioI2S_issue.zip

[schreibfaul1]

I think I know what you mean now. I have built a measuring device for this purpose. When two files are played one after the other, there is this strange effect. If I put a pause between the files, the effect is gone.

[schreibfaul1]

Now it looks better. The decoder sets the sample rate for each new audio file, but I had stopped I2S. I think this is no longer necessary.

[anp59]

Hi, First of all, thank you very much for the quick investigation of the problem. I have tried the new version with my test data. Unfortunately the result is the same as before. Did you run the tests with longer songs?

I have just seen that the change applies to IDF version 5. For me it is still ESP_IDF_VERSION_MAJOR 4 (framework-arduinoespressif32 @ 3.20014.231204 (2.0.14)). Maybe this is the reason. I'll try again with IDF version 5 / Arduino 3.0

[anp59]

Hi, I have also tested the problem with Arduino 3.0.0 rc. Unfortunately with the same result. Attached is the platformio project together with the two mp3 test files. It is noticeable that the beginning of a song only seems to be cut off if the previous song has a minimum length. :confused: ESP32-audioI2S-3.0.zip

[schreibfaul1]

I have unpacked your sample programme and it runs straight away. The dog barks every time and there are always 5 pulses. In the test environment I have an ESP32 with PCM5101A as DAC. I have tested with and without PSRAM. But something must make the difference. I just don't know what it is.

[anp59]

I had carried out the test with PCM5102A and PSRAM, both with ESP32 and ESP32-S3. Always the same error pattern when the next song is played automatically after eof of the previous song. If the next song is started by keyboard input while the previous song is playing, the error does not occur.
I'll test again without PSRAM.

[schreibfaul1]

I have tested with and without keyboard input. The problem is that I can't reproduce the error so far. Can you please run a "FullClean" in VS Code so that the library is fetched again and then test again.

[anp59]

I am hot on the heels of the error. I'll get back to you ... :monocle_face:

[anp59]

I have found the error! It is the active speaker box. :roll_eyes: It is a JBL Charge 3 speaker, connected via jack (Bluetooth off). My assumption that it had something to do with the output of the PCM5102 board (not galvanically decoupled by coupling capacitors) was not confirmed. So it must have something to do with the audio processing of the JBL box (ADC? Software?). With headphones and other (analog) active speakers, everything works again as it should. By the way: I also tested a solution with Phil Schatzmann's audio-tools. The faulty behavior also occurred here. With the other speaker box, everything is ok here too. Ashes on my head.

Thanks again for your tests. Without another opinion, I would never have found the error. Best Regards Andreas

P.S. I have now also heard the behavior described in the https://github.com/schreibfaul1/ESP32-audioI2S/issues/705#issuecomment-2016358116 above. It still occurs.

Incidentally, the problem only occurs when using the analog input of the JBL Charge3. It works correctly in BT mode with a corresponding BT transmitter.

[schreibfaul1]

Great! I'm glad it's working for you now. #705 is difficult, I don't know what's causing it. Before IDF V5.1 there was i2s_zero_dma_buffer(i2s_num) to clear the DMA buffer, I haven't found anything I could use instead.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.