Play SDcard Wav Gaps

[Teenfor3]

Problems...using low speed or poor quality SD cards for playing WAV files using Teensy3.1 and the audio adaptor etc. appear frequently in this forum..??
The problem is still there and happens even with good quality SDcards. The recomended cure has always been to re-format and copy all files on together etc but this does not cure it and does not always work reliably....sometimes needs several re-formats....and probably good luck.???....
It shows up as gaps or glitches in the playing or double starts at opening files etc....

More recently there was a problem highlighted when there was a few milliseconds of distortion between files played in quick succession.
This was fixed in a recent fix.....and all appeared to be OK no gaps or distortion between files.

I am now finding a problem (maybe never noticed it before) where there is 3 to 4 milliseconds of gap between some of the files played immediately after one another and others play with no gaps and not always the same files. I re-formatted the SD card many times and copied various files and same thing happens.

My programming skills are limited but I edited some of the "play" and "stop" functions in the audio library and it seems to have helped it.

Just wondering what someone else thinks about this or what else could be tried.

I tried commenting out some of the lines to see what would happen.
I left it as shown below with the "stop()" and the "interrupts" commented out and this seems to work best. No gaps in the sound between files that are played immediately after one another while another is playing and not waiting to end of file.

The only problem I see now is very ocasionally it "appears to lock up" and fails to play a file (random file) until it gets the following next wav.play("filename").... may indicate SPI problem..????

========================

bool AudioPlaySdWav:lay(const char *filename)
{

//stop();
AudioStartUsingSPI();
//__disable_irq();
wavfile = SD.open(filename);
//__enable_irq();
if (!wavfile) return false;
buffer_length = 0;
buffer_offset = 0;
state_play = STATE_STOP;
data_length = 20;
header_offset = 0;
state = STATE_PARSE1;
return true;
}

void AudioPlaySdWav::stop(void)
{
__disable_irq();
if (state != STATE_STOP) {
audio_block_t *b1 = block_left;
block_left = NULL;
audio_block_t *b2 = block_right;
block_right = NULL;
state = STATE_STOP;
__enable_irq();
if (b1) release(b1);
if (b2) release(b2);
wavfile.close();
AudioStopUsingSPI();
} else {
__enable_irq();
}
}
=================================

 

[Teenfor3]

I have carried out further tests on this problem of 3 to 4 ms gaps of no sound between files and also the problem of "locking up" or failing to play next file. I initially thought this was happening randomly on random files but found it wasn't. I decided to play files fast (100 ms playtime) in a loop and time how long it took ( using Serial.println ) until it locked up and found that it took consistently about 105 to 117 seconds until it locked up and needed power cycled to reset it. I then decided to run a counter and count how many files opened and this was consistently 1287 files. So it must mean too many files opened without a file close......?????

This is why I thought it was random as lots of times I never opened that many files and so never found the problem. I decided to put in a wavfile.close() at the top of the "AudioPlaySdWav:lay(const char *filename)" function and this seems to have cured it, but still needed the other lines commented out to stop gaps between the files..... copied as shown below....... I also commented out a wavefile.close() at the bottom of the update function.


bool AudioPlaySdWav:lay(const char *filename)
{

wavfile.close(); //xxxxx added to close file only instead of using the whole "stop" function xxxx
//stop();
AudioStartUsingSPI();
//__disable_irq();
wavfile = SD.open(filename);
//__enable_irq();
if (!wavfile) return false;
buffer_length = 0;
buffer_offset = 0;
state_play = STATE_STOP;
data_length = 20;
header_offset = 0;
state = STATE_PARSE1;
return true;
}

===========================

This seems to have cured it as a "work around" for me, but I don't think it is a good "fix". There must be something about the "stop" function and/or the interrupts it does not like....?????