How long the deadline is depends on your buffer size and sample rate. To my ear, buffer sizes of >128 samples (at a sample rate of 44.1 KHz) have detectable latency (although the amount of latency will depend also on how many applications are in your signal chain). At 128 samples you have just under 3ms to do your processing.
Also note that for graphics, the output is the GPU itself. So you don't need to wait for the output to move back to the CPU, it's already where it needs to be.
https://www.cycfi.com/2019/04/gpu-dsp-latency/
> PCI-E 3.0 standard guarantees data transfer for 4 kb data with 1-2 μsec (3-10 round trip).
Copying CPU-GPU-CPU:
> size: 8192 bytes, time: 4.72 us,
This should not be a meaningful impact in any audio workflow.
And it's not like this is ABS firmware, where someone might die if you miss your deadline, and where hard real-time OSes are used. But you do get glitches in the audio stream, which in performance contexts is still pretty bad.
[0] https://developer.apple.com/documentation/audiotoolbox/workg... [1] https://wiki.archlinux.org/index.php/Professional_audio#Real...
Win and Mac have soft-realtime scheduling and the mentioned software does what it can without guarantees https://help.ableton.com/hc/en-us/articles/209072289-How-to-... I've been to a live gig before where the performance was paused a few times because artist's mac was misbehaving.
The time budget to refresh a video frame is 8ms on 120HZ if everything else came free. In practice closer to <4ms. So even looking at the close to worst conditions, that's about the delay of the sound traveling a meter - should be fine for a lot of real life applications.