I think you're correct in its current form, that BufferRecorderNode doesn't have the ability to start or stop recording at a specific sample / time on the audio thread, since you fire it from the main thread and it begins the next time that the audio thread notices that recording should start / stop. However I don't think it would be difficult to add, take a look at how I did something similar for BufferPlayerNode::start( double when ) (the ability to schedule things with sample accuracy came after BufferRecorderNode was originally written).
The catch of course is that you must schedule for the recording to start in the future, so you should do the same for whatever it is that you want to record.
If I understood you correctly, let me point out that my concern is not about sample accurate start / stop but rather whether mWritePos is modified in a way that possibly makes it jump the first samples of the new recording.
to recap what I said, imagine these instructions to happen in sequence
-> audio thread reads mWritePos as 2000 // fine
-> audio thread writes samples from 2000 to 3024 // fine, just finish the job in this block of samples
-> GUI thread sets mWritePos to 0 // ok, that's what GUI's supposed to do
Hey, sorry for the delay on this, I'm just getting caught up on outstanding issues..
Thanks for the clarification, I understand the problem that you're bringing to light and think you've found an appropriate fix. Would you like to send a pull request with the proposed changes? Only thing I'd ask is that if you do, try to keep the comment brief (hopefully to one line), as I tend to think in audio processing implementation code it is better to see the math going on rather than lengthy explanations.