well, there's not much to be learned from issue 109 but I was thinking maybe this might be a good occasion to fix / add some of the stuff that's missing from play_sd_wav / sd_raw . most of it is easily implemented but I'd hesitate to do a pull-request without some prior discussion.
off the top of my head that would include :
seek(const char *filename filename, uint32_t pos)
pause()
resume(uint32_t pos)
positionBytes()
lengthBytes()
re: latency, open/close would be one way, I guess, but as a generic solution i don't know. at least, it probably would break most existing user programs which expect play( ) to also open the file.
my idea would be to maybe leave play ( ) more or less alone, just have it check for the filename, somewhat like so (untested) :
Code:
bool AudioPlaySdWav :: play(const char *filename)
{
AudioStartUsingSPI();
__disable_irq();
if (wavfile) {
if (!strcmp(wavfile.name(), filename)) // = same file
{
// does this need to release the audio blocks?
wavfile.seek(0x0);
__enable_irq();
}
else // = file is different
{
stop();
wavfile = SD.open(filename);
__enable_irq();
if (!wavfile) {
AudioStopUsingSPI();
return false;
}
}
}
else
{
stop();
wavfile = SD.open(filename);
__enable_irq();
if (!wavfile) {
AudioStopUsingSPI();
return false;
}
}
buffer_length = 0;
buffer_offset = 0;
state_play = STATE_STOP;
data_length = 20;
header_offset = 0;
state = STATE_PARSE1;
return true;
}
this would need adjustments to consume(), too, ie so it doesn't close the file when the end is reached but merely goes into STATE_STOP or some other state which could be added (STATE_PAUSE).
in that case, an additional function called resume(uint32_t pos) (or similar), which wouldn't need to be passed the filename might be a good idea; at least on the level of the API it would be more semantically transparent: ie a wavfile can only be resumed if it's already been playing. (I guess the same could be argued for open first, only then play)
