In testing, I saw that the decoded_samples value kept increasing when I
stopped and restarted playback, as I'd missed setting it back to zero
during the reset operation.
In my testing, there is no way to accurately know how far into a MP3 file
you're currently playing. You can use monotonic time, but that can have
drift versus the audio playback system, which may not be running at exactly
the expected sample rate.
To allow syncing animation with timestamps in a MP3 file, this presents a
new property, decoded_samples, that records the number of audio samples
sent out of the decoder. While this may not be a completely accurate time,
due to mixer delays, it's much better position that the monotonic clock
difference.
Implementation is keeping track of this value in the mp3file structure and
adding to it whenever data is sent out of the decoder. The property
implementation was a copy/paste from current properties in the audiomp3
files.
Before this, the mp3 file would be read into the in-memory buffer
only when new samples were actually needed. This meant that the time
to read mp3 content always counted against the ~22ms audio buffer length.
Now, when there's at least 1 full disk block of free space in the input
buffer, we can request that the buffer be filled _after_ returning from
audiomp3_mp3file_get_buffer and actually filling the DMA pointers. In
this way, the time taken for reading MP3 data from flash/SD is less
likely to cause an underrun of audio DMA.
The existing calls to fill the inbuf remain, but in most cases during
streaming these become no-ops because the buffer will be over half full.
Ben Combee
Jeff Epler
Jeff Epler
Dan Halbert
microDev