This is by design.
If you don't plan enough memory for streaming, you will have starvation. It was a conscious design choice to favor having low priority sounds starve "a lot" and high priority sounds starve "not too much" rather than having all sounds starve equally in round robin . Here's why.
Wwise's stream manager optimizes the automatic streaming system for audio, and source starvation sounds bad. It is better to play correctly a few high priority sounds and keep the rest silent than to have all sounds creating starvation artifacts (stuttering/distortion).
In a fairly balanced system, source starvation may occur sporadically, and will affect only low priority sounds. This is better than having a high priority (highly noticeable) sound starving because there is too much I/O traffic.
Here's the I/O scheduler's algorithm:
- Find the stream that has the shortest estimated deadline.
- If many streams have a deadline of 0 ms (starving),
-- Choose the one that has highest priority.
-- If many of these streams share the same highest priority,
--- Choose the one that has been serviced since the longest time (round robin).
In cases where I/O is so overloaded that almost every sound is starving, then high priority sounds will still be able to play, and low priority sounds will be silent. Again, this is better than hearing artifacts all over the place due to starvation.
If this situation happens, it means that your system is poorly balanced: you are asking too much I/O bandwidth than what you can afford. You should limit the I/O throughput required by limiting the number of streams playing simultaneously.
The preferred way of doing this is to limit the number of streamed sounds playing at the same time. In Wwise, adjust the "playback limit" of the advanced settings in the appropriate place, generally over the bus(ses) under which the streamed files are located. This way, streaming limitation is controlled by the design, and will therefore sound better...
If you absolutely want/need a solution in code, you can always implement it in the Low-Level IO:
- Implement a brute force file count limit: in AK::IAkFileLocationResolver::Open(), return AK_Fail when the limit is reached. This will kill streams with no consideration of their importance. Note that this will cause "Cannot find file" error notifications in the Wwise profiler.
- Implement a loose file count limit that kills streams using their priority, in AK::IAkLowLevelIOHook::Read(). Return AK_Fail from Read() when the limit is reached and the priority that was passed is the smallest among requests that currently live in the Low-Level IO. Note that the priority heuristic is passed to Read(), and not Open(), because it may change over time for the same file handle. Note that this will cause "I/O error" notifications in the Wwise profiler.
