Single producer, multi-consumer audio processing about concurrentqueue HOT 1 CLOSED

Hmm, I'm not sure it's a good idea to dispatch so few tasks across threads. Roughly how long does it take to process a single voice task? There's a non-negligible cost to schlepping data around between threads, and the latency can vary significantly. Any multithreaded code will always be less efficient than the equivalent single-threaded code (the only advantage is that it can execute across multiple cores in parallel, bringing down the wall clock time even if the CPU time is technically higher).

I don't know much about audio processing, but I don't follow your analysis of what the crackles mean. I would have assumed that it meant the audio data wasn't being generated fast enough to keep up with the demands of the hardware. What buffer could be overrun?

It's probably a better idea to do the audio processing outside of the audio callback where possible, in order to have the data ready to go when the driver asks for it. I know this can be tricky because it can add unwanted latency to your pipeline.

from concurrentqueue.