Recording may have a performance issue

[LIFsCode]

reported here --> ~1:40 - 1:50

2 things are suspicious:

1. Between finishing wav file and creating the next filename is too much time
   • (92542) WAV: Finishing wav file size: 1920044
   • (97167): main: filename /sdcard/eoc/ELOCprod24964_1970-01-01_00_01_30.wav
2. the 2nd file is printing the wrote samples message at a much faster rate

This could indicate, that there is a buffer overrun in the I2SMEMSSampler, due to the delay of creating the 2nd filename.

• [x] Check execution time from finishing wav file to creating 2nd wav file. (could be caused by strftime)
• [ ] Check how to handle I2S sampler overruns (must at least be detected and reported
• [ ] Check if this is related to the reported "timestamp drift", i.e. timestamp difference between files on file system are ~few seconds bigger as defined in seconds per File

[LIFsCode]

Reason was the missing initial timestamp, which caused the esp32 to run form 1970 on... du to a "feature" in the arduino ESP32Time library, gettings the timestamp will wait for 5000 milliseconds.

This extremely long wait will cause a buffer overrun in the I2S sampling engine, which leads to the observed behavior.

This is mainly fixed in 8cb379452d39ef79980ea1e904ed8368217c2e11:

Fix recording buffer overrun when creating the 2nd file

• Init the time (based on build date) if time is not correctly set, the getLocalTime() will stuck for 5 ms due to invalid timestamp

• Since after boot we don't have any proper time available chose build date which is the last guaranteed valid time we know.

NOTE: this does not fix correct handling of buffer overruns