That sounds like a really useful addition. I've not soldered up my audio connectors yet, but could probably find a way to test it. Guess you'd only write the header once recordSdWav::stop() was called, or maybe every second? Not often, anyway...
In other news, my Dynamic Audio Objects managed to break your AudioPlayWav, and I think I found a simplification you can make as a result. Consider this fragment in ::update():
Code:
if (++_AudioPlayWavInstance >= _AudioPlayWavInstances)
_AudioPlayWavInstance = 0;
if ( state != STATE_PLAY ) return;
if ([COLOR="#FF0000"]_AudioPlayWavInstance == my_instance[/COLOR] && buffer_rd == 0 )
This is fine if ::update() is executed for each instance of an AudioPlayWav in
exactly the same order that they were created, which is true for the static Audio library. However, my DAO attempts to optimise the update order to (a) minimise the number of audio_block_t items in use, and (b) ensure objects created later but connected early in the signal flow don't cause weird latency effects. This means that objects don't execute in creation order, and thus the check
_AudioPlayWavInstance == my_instance fails.
It seems to me (and I've tested this) that actually it's an unnecessary check: because you have already pre-filled the buffer[] by an amount dependent on the instance number, you've already guaranteed* that every instance has to re-fill at a different time. Also, because _AudioPlayWavInstance is incremented N times for an Audio engine cycle, where N is the number of instances of an AudioPlayWav, each instance will always see the same number; if it could be incremented once per Audio engine cycle** then each instance would see a match once every N cycles.
*actually, I don't think you have, because you could pre-load X/Nth of the buffer while paused (X=instance, N=total instances), then un-pause them in turn, with suitably-chosen delays, such that they all need to re-fill on the same cycle! But it's unlikely... And waiting for "your turn" would just result in a drop-out.
**Thinking about incrementing _AudioPlayWavInstance once per Audio engine update, that's hard to do: I think we'd have to add an update_count value to the AudioStream object, which gets incremented before the update chain is run; record a static copy in the class; and then increment _AudioPlayWavInstance and update the copy if the static copy didn't match.
Lots to think about...
Cheers
Jonathan