4 ms·

How practical is a "split reverb" with the low-latency parts computed on CPU and the high-latency parts computed on GPU (like how partitioned convolution is alr

How practical is a "split reverb" with the low-latency parts computed on CPU and the high-latency parts computed on GPU (like how partitioned convolution is already performed)? Or is reverb/convolution not processor-intensive enough to reduce CPU workloads significantly?

duped 4y ago
I don't think there's a meaningful difference between high and low latency segments of reverb algorithms except for some exotic hybrid models that use a mix of convolution for early reflections and FDNs for the longer tail, but the synchronization would absolutely suck to write and test
- nyanpasu64 4y ago
  Naive convolution takes time proportional to the number of input samples multiplied by the length of the reverb impulse response (kernel), which becomes rather impractical for seconds-long reverb tails with >100k samples, convolved by ~50k samples per second. The usual solution is overlap-{add/discard} block convolution, where computational power decreases as the amount of input data processed at once increases (to a degree). But if you want short latency, you must process input data in small chunks, which increases CPU load. I think the trick of block convolution is to convolve the beginning of the reverb kernel in small chunks, and the later portions in large chunks (buffering small chunks of input into large chunks, convolving large chunks once available, and playing the result back in small chunks), and adding the two reverb tails (though I haven't fully studied or tried implementing it myself, and IIRC it's patented anyway).
namibj 4y ago
Well, in principle, you can operate with single-digit-microseconds latency via CUDA at least, it just involves breaking free of the normal kernel grid approach and using dedicated pre-spawned threads that run as persistent hardware threads on the GPU cores. It's just that Windows resets the GPU driver if anything "hangs" for more than 5-10 seconds (like a persistent audio processing thread), and GPUs aren't always good at running multiple applications at the same time concurrently, so it may prevent graphics from happening while that audio thread is running (easily solved by not using that GPU to run any displays). Edit: if anything, you can probably run harder real time code on a normal Nvidia GPU than on an Intel/AMD CPU, all of recent generation(s). Reason being that GPUs don't run management work on the application cores and have manually managed local scratchpad memory with bounded latency, but x86 CPUs have a system management mode for firmware/"BIOS" hooks that can interrupt the kernel at any time.

duped 4y ago

I don't think there's a meaningful difference between high and low latency segments of reverb algorithms except for some exotic hybrid models that use a mix of convolution for early reflections and FDNs for the longer tail, but the synchronization would absolutely suck to write and test

nyanpasu64 4y ago
Naive convolution takes time proportional to the number of input samples multiplied by the length of the reverb impulse response (kernel), which becomes rather impractical for seconds-long reverb tails with >100k samples, convolved by ~50k samples per second. The usual solution is overlap-{add/discard} block convolution, where computational power decreases as the amount of input data processed at once increases (to a degree). But if you want short latency, you must process input data in small chunks, which increases CPU load. I think the trick of block convolution is to convolve the beginning of the reverb kernel in small chunks, and the later portions in large chunks (buffering small chunks of input into large chunks, convolving large chunks once available, and playing the result back in small chunks), and adding the two reverb tails (though I haven't fully studied or tried implementing it myself, and IIRC it's patented anyway).

namibj 4y ago

Well, in principle, you can operate with single-digit-microseconds latency via CUDA at least, it just involves breaking free of the normal kernel grid approach and using dedicated pre-spawned threads that run as persistent hardware threads on the GPU cores. It's just that Windows resets the GPU driver if anything "hangs" for more than 5-10 seconds (like a persistent audio processing thread), and GPUs aren't always good at running multiple applications at the same time concurrently, so it may prevent graphics from happening while that audio thread is running (easily solved by not using that GPU to run any displays). Edit: if anything, you can probably run harder real time code on a normal Nvidia GPU than on an Intel/AMD CPU, all of recent generation(s). Reason being that GPUs don't run management work on the application cores and have manually managed local scratchpad memory with bounded latency, but x86 CPUs have a system management mode for firmware/"BIOS" hooks that can interrupt the kernel at any time.