The question is rather vague as to the use scenarios it envisages, but to give a slightly more elaborate answer than "just can't do it, mate" from the accepted answer, there's always a trade-off between latency and bandwidth. Whether one matter or the other depends on the application. If you want real-time processing during a live performance is one end of it. If you want DAW-like post-processing for a recording, that's at the other end.
Here's an illustrative table from a recent paper (Renney, Gaster & Mitchell "There and Back Again: The Practicality of GPU Accelerated Digital Audio ", NIME 2020), showing this tradeoff when using GPUs for audio synthesis.
Physical model synthesizer bidirectional
real-time test.
You get squeezed by latency and jitter from one end (at high buffer sizes) and by lack of bandwidth from the other end (at low buffer sizes).
Using pinned memory for transfers makes a massive latency difference with some discrete GPUs, esp. from the AMD family, as shown in the graph below:
Pinned memory makes almost no difference at all with on-die GPUs, and they already are also kings in the latency department, but generally a lower performance when it comes to internal bandwidth and processing power.
There's also the issue of API-induced overhead, that basically
counts as latency for application purposes. As the paper found
OpenCL is somewhat worse than CUDA in that regard (on Nvidia cards).
As for your actual question of what's out there... not that much. TLDR: among the well-know platforms there's experimental CUDA support in Csound 6, only distributed as source. (And that's not C#, if I need to say it.)
ROLI was envisaging SOUL as the would-be CUDA-like API (and actually language) for running audio tasks on DSPs much like you have accelerated graphics on the GPU. Alas ROLI went bankrupt recently and SOUL is in a deep freeze right now. So that may be a hint that there's probably not that much of market for this kind of PC-based hardware audio acceleration, so the lack of good tooling and libraries goes hand in hand with that.
There's the older Faust for similar synthesis tasks (as SOUL was aiming for), and there are some DSPs that support Faust like SHARC. But that's mostly a different world than GPUs. Faust doesn't do GPUs and its developers aren't too interested in adding support. They do have more recent work on Faust for FPGAs. Generally, they seem to prefer targeting stand-alone embedded platforms on which you can make hands-on instruments, rather than PC-connected stuff. Here's a fairly recent (2020) overview of what they do support in that regard. GPUs are in the very last section of that paper with this:
Graphics Processing Units (GPUs) have been increasingly used
in recent years for real-time audio processing applications, taking
advantage of their high degree of parallelization to run DSP algorithms that can be easily divided into multiple processing units
such as modal reverbs [19], etc.
We believe that FAUST has a role to play in that context by facilitating the programming of this type of platform. We did some
experiment in 2010 by developing OpenCL and CUDA backends.
At that time, results were not really convincing. Now that GPUs
are becoming much more powerful, and with a better understanding of the class of DSP algorithms that can take benefit of their
massive data parallelism capabilities, we plan to work again on
this subject in the future.
The 2019 LAC paper they cite in that context is by two Stanford CCRMA researchers. Worth looking at for an actual application (digital waveguide), as well as a mini-survey, which itself is about a page long so I won't be quoting all of it here, but generally it's been useful for specialized applications like physical models of instruments or massive speaker arrays:
Trebien et. al.[7] use modal synthesis to produce realistic sounds for realtime collisions between objects of different materials. Not ing that IIR filters do not traditionally perform well on GPUs, due to dependence on prior state not mapping well to the parallel nature of GPUs, they introduce a transform to change this into a linear convolution operator and to unlock time-axis parallelism. [...]
Belloch covers GPU-accelerated massively parallel filtering in [9], and Belloch et. al.[10] leverage GPU acceleration to implement Wave Field synthesis on a 96-speaker array, with
nearly ten thousand fractional-delay room filters with thousands of
taps. The maximum number of simulated sound sources is computed for different realtime buffer sizes and space partitions; with a
256-sample buffer (5.8ms at 44.1kHz), between 18 and 198 real-time
sources could be placed in the field.
Bilbao and Webb[11] present a GPU-accelerated model of timpani, synthesizing sound at 44.1kHz in a 3D computational space
within and outside the drum. The GPU approach uses a matrix-free
implementation to obtain a 30x+ speedup over a MATLAB CPU-,
sparse-matrix-based prototype, and a greater-than-7.5x speedup over
single-threaded C code baseline. The largest (and most computationally-expensive) drum update equation is optimized to 2.04 milliseconds per sample, where the bottleneck is a linear system update for the drum membrane.
For more traditional synthesis techniques, they cite a pretty old paper that synthesized millions of sinusoids on the GPU in realtime, but they note that insofar people haven't found much of an application for that many grains.
As far as I can tell all these research apps have been written directly for GPU compute APIs like CUDA, not in any intermediate libraries for audio alas. So it's mostly a "do it from scratch" approach. The Stanford paper makes if fairly clear why that happened: you often need to resort e.g. to the CUDA Analysis tools to profile memory accesses.
Memory accesses should go to the fastest RAM possible, and we need to pay attention to memory alignment. While CPU code does benefit from
similar optimizations, GPU algorithms rapidly fall in performance
when parameters stray from the ideal range.
One other note around generalizing this code for end users: during development we consulted the capabilities of our particular graphics card several times, to see how many registers we have or to see the various ways we can slice shared memory. While these parameters
may be queried from the card at runtime and for the most part newer
and more powerful GPUs contain a superset of old resources, this
is not a guarantee, and for example if we tried to run our compiled
waveguide binary on a GTX 480 from several generations back, it
would fail to run because we request too much shared memory.
