>in a lock-free way. This ensures zero-copy operation. until you want to start processing the data but keep the original around. i was always attached to the zero-copy model, but it just doesn't seem to pan out in real life.
> Plus we added a >wrap space so that a section of the beginning of the buffer is >replicated after the official upper bound so that the audio thread >can read a bit past of it and still gets the correct audio data (as >it was linear), this speeds up the audio interpolation since for the >audio thread it's like reading from a linear segment, no nasty if() >checks etc, it's all done (from time to time, so no pratical CPU >overhead) when the disk thread writes the data to the ringbuffer. i still don't understand this. you can easily construct a worst case scenario where the reader needs to read just a tiny amount from the "end" of the buffer and the rest from the front. in this, it seems to me that your "wrap" space actually has to be the same size as the buffer itself - i.e. you're actually writing two copies of the data. when you use varispeed in ardour, its very easy to make this situation occur. i handled it a different way, one that is less demanding on memory usage that a double-sized ringbuffer because reads are limited to the process() blocksize. --p
