@3dilettante you are a national treasure to this board. The amount of information you know is just unreal.
Thank you for the kind words.
I suppose much of it is doing my best to remember what is said by subject experts and participants in many places, especially here over the years.
I hope to do those lessons they've taught me justice.
I think the audio solution will be different than last gen. PS4 and Xbox One had hardware to do things like convolution reverb etc to alleviate the CPU. I'm expecting PS5 to ship with something similar to Steam Audio and fully accelerated by the GPU.
https://valvesoftware.github.io/steam-audio/
Sony had an audio engineer discuss the various processors in the PS4 in the context of using them in an audio engine, and he noted that at the time the most he'd accept for GPU audio was the longest-latency reverb effects. In the absence of prioritization and with spiky graphics loads, there was too much risk to count on anything more timely.
The DSP block that was roughly analogous to the original True Audio had a more specific use case for Sony, primarily for decode work and secure services for the platform. The limited performance and operations supported meant there was generally not enough for other uses, and there was apparently some additive latency due to the way programmers needed to go through a secure API. Better latency than the GPU, but still not good enough for music-type games and too limited for an ideal audio pipeline.
That left the Jaguar cores, which seemed decent enough.
There was a video presentation that went with the following slides:
https://www.slideshare.net/DevCentralAMD/mm-4085-laurentbetbeder
In the talk itself, he actually gave some examples of worst-case timings not in the slides themselves. I think it was something like ~30ms for launching an audio wavefront when the GPU was under load. The ACP could get below 10ms, but for the most sensitive games (dance/rhythm games were something like his example) he wanted latency in the single digit ms or sub-ms. Fast response helped with perceived latency, and very fast latency combated accumulated latency--which could make using more than one device type a problem if you were hopping queues.
Unfortunately, I've not seen quantitative numbers for launch latencies since, so what True Audio, then True Audio Next, and the high-priority queues offer today is something of a mystery to me.
One other non-performance limitation that known GPU hardware wouldn't solve was their wide hardware would require batching objects to better utilize them, which ran counter to the ideal programmable audio engine where the developer could put together effects as one wished without needing to learn the low-level batch behavior of the hardware and lose flexibility.
