Make AudioPlaySdWav object honour the value of AUDIO_BLOCK_SAMPLES

[h4yn0nnym0u5e]

Loads either one SD card sector / 512 bytes, or two blocks' worth (to allow for stereo playback) if AUDIO_BLOCK_SAMPLES is set to >128. Minor change to play_sd_raw.cpp to remove magic number.

Very simple update, no (intentional!) change in behaviour with standard library settings.

[dwexel]

This is pretty much what I came to github to find, except I wanted to remove the magic number in play_sd_wav.h
It should reference AUDIO_BLOCK_SAMPLES instead of being a hard-coded 512 bytes
I don't know anything about SD card sectors.

[h4yn0nnym0u5e]

This is pretty much what I came to github to find, except I wanted to remove the magic number in play_sd_wav.h It should reference AUDIO_BLOCK_SAMPLES instead of being a hard-coded 512 bytes I don't know anything about SD card sectors.

But it's necessary to understand SD card sectors and the AUDIO_BLOCK_SAMPLES value and the contents of .WAV files to make a meaningful change here. I agree that the use of a magic number is inherently poor, but simply reading AUDIO_BLOCK_SAMPLES * 2 to get enough for one stereo update() (or two mono ones) is very inefficient for small block sizes (often used by those who want less than the 2.9ms latency given by the stock values). Hence the slightly more complex calculation in this PR.

If you've successfully used this in your code, please report back - I'd like to know it works for you, even if at nearly 3 years old the prospect of it getting pulled in seems remote. Do note that you're unlikely get more than a couple of files playing back at once, as the design of this object is pretty poor, accessing the SD card inside an interrupt.

[dwexel]

If you were to redesign this object from the ground up, what would that look like?
If that's something you want to do, I'm interested in trying to help.

[h4yn0nnym0u5e]

Very much like this PR. Yes, it uses more memory, and needs a bit of extra setup, but it seems to work well. Precautions are needed around other SD access, because SdFat calls yield() internally, which can result in crashes if there's a pending EventResponder response which itself reads or writes the SD.

See also the discussion thread here.