One of the few components that remain unveiled in Durango is the sound block. This article is intended to describe this important part inside the system.
Durango’s audio architecture seeks a balance between the successes and tradeoffs of previous generation platforms while anticipating the increasing technical needs of next-generation implementations. It provides hardware-accelerated pathways for the most common aspects of audio rendering—compression, mixing, filtering, and so on—on a large number of concurrent voices. The architecture also provides a shared resource model for software processing consumption, allowing each individual title to select what and how much custom signal manipulation to apply in CPU utilization.
This part refers to the rumored app support,
Audio and the Durango App Model
While in the foreground, an application has full access to the SHAPE hardware. When that application is pushed to the background—pinned, picture-in-picture, or other scenarios—it relinquishes hardware control. By default, its hardware state is suspended, and resumes when the title returns to the foreground. This also is true for Exclusive Resource Applications [ERAs] where the software graph is suspended.
A title may optionally choose to tear down its audio graph and reconstruct it upon resume. Some titles, particularly Shared Resource Applications [SRAs] that play background music such as streaming radio, may choose to have some aspects of audio continue to play even while paused. For these scenarios, titles should closely evaluate whether to attempt a seamless transition from hardware to software rendering, or to always play audio intended for background playback via a software-only pipeline. This has implications for compression formats and CPU costs. XMA-compressed assets, for example, require the use of SHAPE hardware, and thus will not be decodable for a background application.
The XAudio2 audio engine does provide software pathways for many functions if a title chooses to allocate CPU resources. Where practical, these functions mimic hardware capabilities, but some compute intensive processing is either unavailable or is differently implemented in software. Titles transitioning from hardware processing to software processing based on an app’s state may want to consider these differences when planning their audio pipelines.