adafruit / adafruit/Adafruit_VS1053_Library
Millis() function is extremely inaccurate when playing audio on Feather M0
- Dominant language
- C++
- Stars
- 152
- Forks
- 116
- PR merge metrics
- No merged PRs in 30d
Description
- Arduino board: Feather M0 basic proto + Adafruit Music Maker Feather Wing
- Arduino IDE version: 1.8.5
- Problem: The millis function is very inaccurate when playing an audio file. I have a sketch which uses the millis function to blink a led once every 3 seconds, the led is on for only 300 mS. When the library is playing music the 300 mS time goes to 429 mS (that’s almost 150 %). The file is 320 kb/s MPEG Audio Layer ½, dual channel mono, 44100 Hz, 32 bits.
The millis function is also used on my program to keep track of time using Unix time (not only to blink leds), so it´s desirable to keep timings as accurate as possible.
I know this file is high bitrate, but we´re developing a prototype for a third party. It should be able to handle high bitrate files, because the final user might not be able to tell if an MP3 file is 128 or 320 kbps.
The problem seems to be related to how the code handles the DREQ interrupt, as this function takes several milliseconds to execute while the data is transferred from the SD card and then to the VS1053. In the mean time the Systick might not be handled correctly.
Possible solutions that I thought:
* Raise the priority of the interrupt used for millis() so it can nest in the DREQ interrupt (not sure about the side effects of this and if it is even possible because of how NVIC is initialized, involves messing with the Arduino core).
* Not use interrupts at all and handle all the data buffer feeding on the main loop.
Has anybody else experienced this problem, is there a workaround for this?
Thank you in advance.
Contributor guide
No contributing guide indexed for this repository
Research direction
Reproduce the reported timing drift on the Feather M0 with the Music Maker Feather Wing while playing the specified high-bitrate audio and blinking the LED. Start by tracing DREQ interrupt handling alongside millis() and SysTick; done means the timing behavior is understood and a verified fix or workaround keeps the reported intervals accurate during playback.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- audio-video-rtc, embedded-iot
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100