Transitions Unreliable

Hey Joseph, thanks for taking your time to look into it. True that seems logical. The reason I assumed it might be related to the channels was, that the issue isn’t ocurring on pc with 128 real and 512 virtual channels, but becomes reproducable again after lowering the channels to 32/128 .

The asset is not set to streaming as far as I can tell and doesn’t have custom platform encoding settings. It’s also rendered to 48khz which is the native frequency for the project.

Filtering our assets, I can verfy that not a single file is set to streaming.

I have also tried separating the one track into shorter files, because I thought that re-instancing the entirety of the file for each of the many transitions in the event might be the culprit, but that didn’t help either.

I will try to reproduce the issue on a windows build with different audio channel settings to verify I can really reproduce the problem that way and will upload profiler settings for both scenarios. If you think that might help, I can also trimm the audio track into shorter slices again to verfiy that’s not the solution to the problem.

If there is any other info that might be valuable for you, please let me know. Many thanks.

I tried to reproduce the issue on windows with a fmod settings set to 32 real and 128 virtual channels and was not able to do so, which I guess supports your deduction, that it’s not related to channels at all.

One thing I noticed though, was that my real channel count during the test is peaking at 41, which seems odd.

Profiler Session: herdling_windows_32r_128v_noReproduction.fspackage

Looking at the profiler session, the event Music/MusicMountainPlainsScore is producing no voices/channels at all during the gap you mention - not even virtualized voices. This suggests that this issue isn’t related to the real channel count, and must therefore have some other cause.

Is it possible that the issue is caused, not by starvation of real channels, but virtual ones? Profiling with up 512 virtual channels, I can see that the game actually overcaps the 128 virtual channels which are availablee on ps5, peaking at around 180. Is there a world where the voice created through a transition timeline is always first virtualized before a real channel is allocated and for some reason not ptioritized more highly than other virtual voices with lower priority setting?

Uploaded profiling sessions at 128 real and 512 virtual voices on windows: herdling_128_512_noRproduction.fspackage

Aha! That’s likely the problem.

It is very rare for maxchannels to be set so low that the game actually hits its virtual voice limit. After all, the benefit of virtual voices is that they only consume a token amount of resources, so there’s usually no downside to setting maxchannels to an arbitrarily-high number the game will never realistically hit, be it 512, 1028, 2048, or even the maximum possible 4095.

PS5 is no exception to this, as it supports as many virtual channels as any other platform.

It sounds like your game’s simultaneously-playing channel count is generally below 200 but often above 100, so I recommend setting maxchannels to 512 instead of 128.

Yes and no. This is a world where newly created channels are being culled regardless of whether they’re virtual or real - but that culling is stealing rather than virtualization, and neither priority nor transition timelines factor into it.

maxchannels is the maximum number of channels that your game supports, counting both real and virtual channels, not just virtual channels. (Our documentation on this is misleadingly phrased; I’ll add a task to our feature and improvement tracker to clarify it.) As I mentioned above, games aren’t ever supposed to exceed maxchannels, so there’s no system of priorities that allows you to specify which channels should and shouldn’t be stolen when it happens. Instead, whenever maxchannels would be exceeded, the most recently-created channel is stolen.

This means that if your game is regularly exceeding maxchannels, it will tend to steal the voices of instruments that have only just been triggered, which have only just looped, or which have only just selected a new playlist entry to play; in each case, it results in those instruments suddenly cutting out or apparently failing to play their content. This is most likely to be noticeable with instruments that play in the foreground (i.e.: can be distinctly heard) and are triggered frequently and predictably, including (but not limited to) music.