Az AMD pontosan egy hónapja mutatta be ténylegesen a szabványos platformra épített TrueAudio Next API-t, ami tulajdonképpen minden olyan GPU-n képes lehet futni, ami rendelkezik legalább OpenCL 1.1-es meghajtóval, illetve az x86-os processzorokhoz is van egy úgynevezett fallback mód. A rendszerről az Impulsonic már meg is mutatta, hogy mennyit gyorsíthat a hangfeldolgozáson, és a Phonon technológiára épülő szoftvercsomag C API verziójával ezt bárki beépítheti a videojáték-motorjába. A terjedés az Impulsonic szempontjából kellemesnek mondható, mivel a Unity és az Unreal Engine rendelkezik Phonon integrációval, ahogy az Audiokinetic Wwise és a Firelight fmod kínál rá támogatást.
Az egyetlen kérdés igazából az maradt, hogy egy VR-hoz fejlesztett játék hangmotorjával miképp történik majd a konkrét feldolgozás. Erre az AMD az alábbi ábrát mutatta be a napokban, ami tulajdonképpen teljesen jelzi egy tipikus VR program által kifejtett terhelést. A megszokott grafikai számítások alacsony prioritással futnak be, és ezek nem kritikus feladatok, vagyis a futtatásuk akármikor megtörténhet az adott időegységen belül. Ezt egészítik ki közepesen magas prioritással rendelkező compute feladatok, amelyek igazából opcionálisak, de az aszinkron compute lehetőségei miatt megéri élni a bevetésükkel. Szintén közepesen magas prioritással rendelkezik az konvolúció minták frissítése. Ez már a TrueAudio Next API-hoz, ezen belül is a Radeon Rays csomaghoz tartozik, és tulajdonképpen ez biztosítja a fizikailag korrekt hangélményt. Végül a VR esetében magas prioritású feladat a timewarp és az aszinkron timewarp.
A hangfeldolgozáshoz kapcsolódik még a hangpufferek kezelése, ami a konvolúció minták frissítéséhez kötődik. Ez a feladat kritikus fontosságú, mivel tényleg rendkívül kevés időegység áll rendelkezésre a számítások elvégzésére. Itt szerencsére nincs őrületesen sok számítás, vagyis 500-600 GFLOPS-nyi teljesítmény még a legdurvább esetekben is bőven elég lesz. Sokkal fontosabb az azonnali válaszadás. Itt jön elő az, amiről már az legelső hírben is beszéltünk, hogy a fejlesztő a Polaris családba tartozó GPU-kat statikusan particionálhatja az erre kínált, meghajtóba épített funkció segítségével. Ilyenkor a leválasztott multiprocesszorok valós idejű válaszadásra lesznek képesek. Ebben rendkívül nagy segítség lesz a GCN4 architektúrába bemutatkozó utasítás-előbetöltés is.
A TrueAudio Next természetesen enélkül is képes működni, hiszen alapvetően a hangpufferek kezelése is pont olyan számítás, mint a többi, és az is látszik, hogy nem ez lenne az egyetlen magas prioritású feladat, hiszen eleve ilyen a timewarp és az aszinkron timewarp. Az AMD szerint a problémát a tervezhetőség jelenti. Ez a trükkös része a dolognak, ugyanis a megfelelő, fizikailag korrekt hangélményhez ismerni kell a virtuális világ kialakítását. Vagyis az ezzel kapcsolatos munka akkor kezdődhet meg igazán, amikor a játéktér nagyjából összeállt, és az egyáltalán nem, vagy csak nagyon keveset fog változni. A hangszámítás azonban elveszi az erőforrást a grafikai számítás elől, vagyis rendkívül részletes előretervezés szükséges ahhoz, hogy a fejlesztés végére fizikailag korrekt hangélmény és a kívánt grafika is úgy összeálljon, hogy közben megvan a kívánt futtatási sebesség is.
Utóbbi annyira nehéz, és sokszor nem is fog sikerülni, ezért kínálja fel az új hardverekre az AMD a meghajtóból meghívható statikus particionálást, mivel így a hangok és a grafika fejlesztésével foglalkozó részleg is fix erőforrást kap, vagyis a fejlesztés legvégén nem fogja az a meglepetés érni az érintetteket, hogy nincs meg a kívánt sebesség.
Természetesen a virtuális valóságon kívül is van élet, és itt is működik a TrueAudio Next, de ez azért nem kap ennyire nagy figyelmet, mert a hagyományos képmegjelenítéssel nincsenek annyira kötött követelmények, mint egy VR-hoz tervezett játéknál. Természetesen itt is bevethető a statikus particionálás a Polaris családba tartozó Radeonokra, de nem annyira fontos, mivel sokkal elfogadhatóbb, ha a játékmenet során a sebesség egy adott minimum alá esik. Nyilván nem szerencsés, de konkrétan nem lesz tőle rosszul a felhasználó, miközben a VR-on belül az ilyen esetek tényleges rosszullétet válthatnak ki. Emiatt egy nem VR-hoz tervezett játéknál a hangpufferek kezelése megfontolandó szimplán magas prioritású feladatként, de ezt a döntés az adott fejlesztés ismeretében kell egyénileg meghozni.
