Missing sound samples and recordings are a bit too long

[EDsteve]

@OOHehir @LIFsCode There are two issues with sound recordings. Hope this is an easy one to fix :)

1. Recordings too long (Not a big issue though)

A 60 second recording does record 60 seconds plus a few ms (See yellow arrows in point two). This results in these inconsistent time stamps.

Should look like this	That's how it is now
18:27:53	18:27:53
18:28:53	18:28:53
18:29:53	18:29:54
18:30:53	18:30:55
18:31:53	18:31:55
18:32:53	18:32:56

2. Missing sound samples

With this commit (d2dd26c8f8e37bfb0c3e9861ef266469df3d2101) i get missing sound samples between each recorded sound file. This didn't happen with this commit (cf51c0378c7afd5d93d96bc6fc62fe502a3b9fc0).

I recorded an interval of peeps for > 2 minutes and opened the first and second minute next to each other in a sprectrogram viewer to see if the sound has missing samples. In the spectrogram you can see the difference between these two commits when you look at the beeping interval. (4 beeps and a pause).

[EDsteve]

The spectrogram shows the problem. But if you want to see the sound files yourself: not_set1706443569745_2024-01-28_12_06_10.zip

[LIFsCode]

@EDsteve just to make sure I understand it correctly:

missing samples means you are missing a whole block of sound data, not some sporadic spread missing samples, as we have seen with the 44kHz recording and apll use with power management the later would result in distorted spectrum. From what I see in the screenshots it looks more like a block of data missing but the spectrum is clean. Can you specify the length of data which is missing?

Do you see any buffer overruns in the log?

[OOHehir]

@EDsteve

1. Currently the the wav file length is checked after each buffer is written to the SD card, thats the reason the files aren't exactly 60 sec. Its possible of course to write out files exactly the desired length, but it does introduce some added complexity. This would be things like checking the file length as the buffer is written out, checking if the buffer isn't completely written out & if not, recording the position of the buffer yet to be written out. Not overly complex but would need some more code. If you require it let me know & I'll work on it

2. I'm fairly certain the commit you refer to didn't change the way the sounds is captured from the I2S peripheral or written to the SD card. It only changed the way the I2S object was created in memory of the ESP32. I assume the wav_writer was in continuous recording mode? If the reason is not the issue @LIFsCode mentioned above I suspect it could more to do with either:

   • The commit that reduces the I2S DMA buffer sizes or
   • A possible bottleneck with the SD card. Either way, possible solutions would be to increase the I2S DMA buffer size again (not ideal as memory issues will probably reappear) or to start the new recording immediately after one finishes (its currently started in main.cpp). This is probably best accomplished by moving the functions

     createFilename()
     start_sound_recording()

     into WAVFileWriter.cpp but I don't believe it would be too big an issue.

[EDsteve]

@LIFsCode @OOHehir

1. It doesn't matter if it's exactly one minute or not as long the time stamps show the right time. So let's leave it as it is. No more complexity for now :)

2. You are right Fabi. It seems to be connected to a wav buffer overrun. I have just done more tests. And evry time there is a wav buffer overrun in the log. There is also the missing sound block. The missing sound block is around 390ms long.

   This problem is not happening all the time. But i would say 90% of the time.

   Here is the log: Missing_blocks.txt

OFFTOPIC: In this log file i got also an error with the time synch. Which i have never seen before. Is that a firmware issue or an app issue? I (44932) BtCmds: updating time with {"seconds":1706509716, "ms" :setConfig E (45047) BtCmds: Parsing time config failed with InvalidInput! Might this be connected to the issue? [ 22254][E][BluetoothSerial.cpp:342] esp_spp_cb(): RX Full! Discarding 23 bytes

[EDsteve]

The wav buffer overrun seem to be happening only when a new files is written. Which is bad if the file size is 1 minute. But the rangers will use 1h sound files. So if that issue is too complex to solve and/or you have more important improvements to do. It's not a too big deal if 390ms are missing every hour - for now. :)

[OOHehir]

@EDsteve I concentrate on solving the wav buffer overrun first, then come back to the file length.

[EDsteve]

@OOHehir I think the reboot issues should be solved first before we deal with the file length, which adds complexity :)

[OOHehir]

@EDsteve @LIFsCode I've made some changes which should improve the wav buffer overrun issue. An outstanding issue to resolve is to continously check the SD card free space as each file is created. There's a few functions in main.cpp that could be moved into SDCardSDIO.cpp which should allow this to be achieved in a cleaner method.