when I wrote the driver I used a bluepill running at 3.3 V, so the same logic level as the dfplayer. Hence, the issue could not possibly be caused by a mismatch in the logic level.
The audio glitches I experienced sounded suspiciously like a soft real time system missing deadlines and sending bogus data to the DAC. The driver counters this to some degree by rate limiting the commands send via UART (the
xtimer_msleep(DFPLAYER_SEND_DELAY_MS)), which spreads the audio glitches over time. With that mitigation the issue is barely noticeable. You could set
0 and use the
dfplayer shell command to reproduce the issue. (Also most of the dfplayer “datasheets” stated that requests send to the dfplayer should be rate limited. But then again I never found a technical document as incomplete, incoherent, and outright wrong as these “datasheets”.)
Also note that the dfplayer can be obtained from various dubious sources with wildly different behavior. (Some of them may be fake clones, but how to tell?) I have one version which can handle requests at any rate but is extremely affected by audio glitches at high rate, and another version which is almost immune to audio glitches but drops most requests when sent without rate limitation. (I can only guess, but both may be symptoms of a soft real time system being under too high load. One version may be prioritizing command handling over audio playback (causing the glitches) and the other prioritizing audio playback over request handling.)
If you got hardware that does not show any sign of audio glitches, feel free to open a PR to update the documentation to indicate that only some versions are affected by it. I still think that it should be documented, as for high quality audio playback one either has to spend effort in sourcing only glitch-free hardware or working around the issue by avoiding needless UART communication during playback.