Closed danclarke closed 2 years ago
Small update - I got it working with some very small amends to the library, the task can be created transparently within the library itself. I'll continue testing and create a PR if I'm happy with how it works.
@danclarke I was about to dive into this problem. Do you have any working code? I would love to help test/debug.
@brandondixon I do, I've put a fork up here: https://github.com/danclarke/Adafruit_VS1053_Library
In my specific application I was getting some odd behaviour, but it could be power related. I've tried with some much more advanced workarounds and changes, and they seem to get progressively worse than the simple code I've uploaded. Sadly I haven't had the time to fully investigate.
Why do you want to use interrupts when you have to feed the buffer in the main loop anyway?
Something like
void loop() {
if (musicPlayer.playingMusic) {
musicPlayer.feedBuffer();
}
}
will do fine without any interrupts.
The main Problem is that the ESP8266 and ESP32 do not support this function: https://www.arduino.cc/en/Reference/SPIusingInterrupt This makes SPI communication and interrupts a hassle.
I'm stuck using an ESP32 :(
There's nothing wrong using an ESP32, IMHO it's just easier not to use this library with interrupts on it, but with manual buffer feeding as shown in my previous post
@TheNitek It's so that you can play audio in the background while performing other tasks without having to worry about keeping the buffer fed manually.
Interestingly I created a task where the sole purpose is to call the feed method, and I still get the same audio corruption in the same place. I'm thinking it's due to how I'm using the audio files specifically so more investigation required. On the plus side, it behaved in an identical manner to my interrupt workaround.
Well I found the source of the audio corruption, seems my SD card was slowly getting more and more corrupted. Also I found wav files I was using to play very slightly less reliably than mp3. I don't think it's due to insufficient feeding of the buffer, but I don't know enought to say for certain. It was a slight lack of dynamic range rather than static.
Anyway if the workaround for the interrupt / SPI access works OK for others, I'll submit a PR.
It works for me using the devkit1 board. I would love to see this in the official library!
Works for me on the Huzzah Esp32 feather. Thanks!
Hello, I'm adding my modification link for who might run into same issue like me https://github.com/eziya/ESP32_ADAFRUIT_VS1053
Is this going to be addressed? The stock sample code fails for me on a stock HUZZAH32 without the forked library.
The base issue here is in the ESP32 BSP. See here: https://github.com/espressif/arduino-esp32/issues/7211
The lack of ability to disable interrupts, combined with the DREQ pin behavior of the VS1053, ends up causing grief when trying to use interrupt based playback. The DREQ pin toggles for other reasons and fires the ISR when not expected. This eventually leads to a WDT reset or other behavior.
The approach in the @eziya fork is to essentially not use interrupts and rely on feeding the buffer in the sketch's loop().
Yes @eziya fork works fine, but the main loop freezes at feedBuffer()
.
So in my example button inputs are not working until the song is done playing (using startPlayingFile
).
Also the sounds seems to pop from time to time :(
Anyone suggestions?
Try updating to the 2.0.5 release of the ESP32 BSP: https://github.com/espressif/arduino-esp32/releases
The addition of support for noInterrupt()
and interrupt()
fixed interrupt based playback on ESP32 in our testing using this library and the feather_player
example.
@caternuson it seems im unable to get a stable output from the HUZZAH32 + VS1053 feather, nor the HUZZAH + VS1053 feather. It jitters and pops.
Both instances give me jitter sounds. File is a WAV 44100Hz at 16bit PCM.
Even with the feather_player
example
Is that happening if the WAV file is played back with both playFullFile()
and startPlayingFile()
? Or is it just with startPlayingFile()
?
It seems to be both do the same. You almost say it the module or something but I’ve 3 audio feathers all with the same issue 😅
If it is also happening with playFullFile()
, then it is unrelated to interrupt playback. Please open a new issue.
Closing this one for now since interrupt playback with startPlayingFile()
is working in local testing with on ESP32.
The interrupt-based playback does not work on ESP32, calling the SD library from within an interrupt handler seems to cause an almost immediate crash. The exception stack trace is as follows:
I've done a quick test where the interrupt handler sets a flag, letting the main loop know to populate the buffer and that works fine. I'm pretty sure I can set up a solution using a separate task to just feed the buffer as and when with maybe a larger memory buffer to cater for the extra latency. Of course this will be super ESP32 specific and couldn't be integrated back into the library.