For example, one of the responses proposed pre-loading a large fully-rendered audio segment onto a DMA buffer to remove the CPU from the latency-sensitive pipeline entirely.
For example, one of the responses proposed pre-loading a large fully-rendered audio segment onto a DMA buffer to remove the CPU from the latency-sensitive pipeline entirely.
Even if this did matter, it's still bullshit. Memcpy isn't going to add latency and jitter over some "optimized" copy routine. And C++ new certainly isn't going to be better than malloc, when it's almost certainly calling through to malloc.
(Sorry)
Audio is full orders of magnitude less data and this is on hardware that's 20 years newer. With any reasonable buffer size this is a slam dunk, unless perhaps you're really concerned about latency.(In which case automatically streaming multiple megabytes of audio data across DMA isn't going to help you either.)
They are more like techniques for creating April Fools jokes...
>For example, one of the responses proposed pre-loading a large fully-rendered audio segment onto a DMA buffer to remove the CPU from the latency-sensitive pipeline entirely.
You missed the fact that that response was taking the piss of the initial post...