Thijs Koerselman

I'm working on an object which copies a chunk of data from a buffer~. The object is used inside poly~ and the copy action happens on each new voice trigger.

Depending on the voice parameters it copies small to medium sized chunks, the biggest ones being a few seconds. I currently copy the samples straight from the perform routine.

I noticed that with smaller i/o sizes (128) and larger sample chunks (>1 sec stereo) I get zipper noise in Ableton Live. I'm guessing this is the result of CPU spikes from the copy routine taking too many cycles. So I'm looking for a way to optimize and prevent this.

The data read from the buffer won't ever change or resize while its being copied afaict. Would it help if I don't call buffer_perform_begin() and buffer_perform_end(), so that I won't block access to the buffer for the other voices? Or is buffer_perform_* only preventing data changes and not read operation?

Would it help if I copied the audio in a separate worker thread? I'm guessing this will only work when not blocking the buffer access for other threads. Then I will have to handle the delay that occurs from copying inside my algorithm, since the voice can't start playing immediately, but that is still a lot more feasible than zipper noise of course.

Maybe there are other ways...Hope someone can shed some light on this.

The data read from the buffer won't ever change or resize while its being copied afaict. Would it help if I don't call buffer_perform_begin() and buffer_perform_end(), so that I won't block access to the buffer for the other voices? Or is buffer_perform_* only preventing data changes and not read operation? 

Maybe there are other ways...Hope someone can shed some light on this.


advise-on-how-to-readcopy-buffer-data-from-voices

After optimizing some things like for-loops to memcpy and function calls to lookup tables, I managed to get rid of the zipper noise, so for now I'm ok but it's not the real solution. Smaller vector sizes and bigger chunks will bring the glitches back no doubt.

I think a worker thread would be the only solution, copying the data in small chunks.

How do you profile/detect cpu spikes in dsp code (on OSX) ? Standard metering tools (and Ableton CPU meter) don't show these things.

After optimizing some things like for-loops to memcpy and function calls to lookup tables, I managed to get rid of the zipper noise, so for now I'm ok but it's not the real solution. Smaller vector sizes and bigger chunks will bring the glitches back no doubt. 

How do you profile/detect cpu spikes in dsp code (on OSX) ? Standard metering tools (and Ableton CPU meter) don't show these things.


Yes, unfortunately I think what we got on our hands is a dead shark. Thanks, Apple.

Yes, unfortunately I think what we got on our hands is a dead shark.  Thanks, Apple.


I remember using Shark before once in the past. Too bad its gone. Hopefully they have something similar again for 10.9 / xcode5... I think I have a clear idea now on how to deal with the data copy. I could do it in small chunks *and* playback immediately by starting the copy with the data which is played back first.

I remember using Shark before once in the past. Too bad its gone. Hopefully they have something similar again for 10.9 / xcode5... I think I have a clear idea now on how to deal with the data copy. I could do it in small chunks *and*  playback immediately by starting the copy with the data which is played back first.


Advise on how to read/copy buffer data from voices