WAV file plays with pronounced click at end unless the WAV DATA is an exact multiple of 512 bytes (IDFGH-8416)

[william-ferguson-au]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v4.4.2-312-g08fa67fe92

Operating System used.

Windows

How did you build your project?

Command line with CMake

If you are using Windows, please specify command line type.

CMD

Development Kit.

ESP32-WROOM-32

Power Supply used.

USB

What is the expected behavior?

I expected it to output both WAV files to the speaker without introducing a click at the end of the second WAV.

What is the actual behavior?

Instead it plays the first WAV file cleanly, and then plays the second WAV with a pronounced lick at the end.
Note that the 2nd WAV file is a copy of the first WAV file with a chunk of sound cut out of the middle using Audacity so that the start and end of the WAV are unchanged, only the length of the data chunk is changed.

Steps to reproduce.

1. Build https://github.com/william-ferguson-au/esp32-wav-failure

2. Flash to a board that is connected to a speaker
   // Speakers I2S
   #define SPEAKER_BIT_CLOCK GPIO_NUM_27 // The bit clock connection, goes to pin 27 of ESP32
   #define SPEAKER_WORD_SELECT GPIO_NUM_26 // Word select, also known as word select or left right clock
   #define SPEAKER_DATA_OUT GPIO_NUM_25 // Data out from the ESP32, connect to DIN on 38357A

3. The are 2 WAVs deployed in the SPIFFS partition.
   1st WAV FILE_ON_YOUR_MARKS (wav DATA size 69120B = 67.5KB)
   2nd WAV FILE_ON_YOUR_MARKS_NO_MIDDLE (wav DATA size 55932B = 54.62109KB)

4. Note that it loops playing the 2 WAVs. The first WAV is played correctly. The 2nd has a pronounced click at the end (you can ignore the click in the middle as this is an artifact of clipping the middle out of the WAV).

Debug Logs.

Nothing of any real interest.

More Information.

The ONLY way that the first WAV can be played correctly is via the play_wav_file3() function.
All other functions 1-9 introduce some kind of audio glitch.

The 2nd WAV cannot be played without audio glitch in any function.

I suspect that the first WAV only plays correctly because the WAV DATA Size is an exact multiple of 512B

Note also that BOTH WAVs play correctly in Audacity as well as every other audio player I have tried.

[L-KAYA]

HI @william-ferguson-au , I've tested your code, it seems that the clicks come from the unexpected data at the end, I monitored the signal by a logic analyzer, there are some pulses at the tail:

It seems the bug of tx_desc_auto_clear which doesn't totally clear the legacy data, it will be fixed soon.
Thank you for your reporting!

[william-ferguson-au]

Can you explain the image you shared and how you generated it?

I don't believe there are pulses at the end of the data section of the WAV that causes the issue as it is identical to the tail of the WAV that works.

However, there are 2 RIFF sections after the data section.

See this image from RIFF Viewer

What do you mean the bug of tx_desc_auto_clear? Can you provide a link.

[L-KAYA]

The pulses at the end are the legacy data in the DMA buffer that not fully cleared, due to the buffers are linked as a ring, they will be sent cyclically, that is where the pulses come from. Theoretically, the DMA buffer should be cleared when it finished sending data if tx_desc_auto_clear is set. The bug is, it only clear the buffer that overflowed (it should clear no matter overflow or not, i2s.c:L469), now it is fixed on master(but not sync to github yet), and preparing to backport to v5.0 and v4.4.

Currently, you can call i2s_zero_dma_buffer after finishing sending you audio instead of writing a silent buffer.

Another tip is, setting i2s_driver_config_t::dma_buf_len to 1024 doesn't mean the DMA buffer is 1024 bytes, it is limited to 4092 bytes, please refer to the Application Notes to see the relationship between dma_buf_len and the real DMA buffer size. Actually dma_buf_len is a bad name that mislead you, it should called dma_frame_num, it has been deprecated since v5.0. Briefly, if you need to allocate 1024 bytes for one DMA buffer, dma_buf_len should be set to 256

[william-ferguson-au]

OK, I think I understand some of that.

How can I get notified when the tx_desc_auto_clear fix (be7c656) get backported to 4.4 ??

I did try using i2s_zero_dma_buffer() but it wasn't working, possibly because of this other bug which is why I was writing SILENCE to the buffer.

[william-ferguson-au]

@L-KAYA why is DMA buffer 4092 bytes and not 4096 bytes (ie 4K)?

[L-KAYA]

the length field in the descriptor is 12 bit which stands for 0~4095, but the DMA requires 4-byte align, so here comes the maximum size 4092