Hello,
Known Hardware Bugs
Device Bugs Not Handled by the Driver
On some versions of the DFPlayer, any UART communication with the device during playback results in audible and unpleasant glitches. The only solution is to not communicate with the device during playback, as the DFPlayer seems to pause playback for some milliseconds after receiving a command.
https://doc.riot-os.org/group__drivers__dfplayer.html#details
4、Application Circuit
4.1 Serial Communication Connect
Module’s serial port is 3.3V TTL level, so the default interface level is 3.3V. If the MCU system is 5V. It is recommended connect a 1K resistor in series
Source: https://picaxe.com/docs/spe033.pdf
Hi,
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 DFPLAYER_SEND_DELAY_MS to 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.
Kind regards,
Marian