The runtime performance of playing audio with Timeline is not only affected by the number of AudioClips running at the same time, but seemingly all audioclips in Timeline.
In the provided test project, only four audio tracks play at the same time, this should perform very fast, but it costs more than 400ms on an AMD 3900X.
Please refer to the provided video for a demonstration of the problem. In the video, I showcase a synthetic test case on a rather fast machine. The performance is significantly worse on Console platforms.
Actual
PostLateUpdate.UpdateAudio is way too expensive (400ms)
Update.DirectorUpdate is way too expensive (1.5ms)
PostLateUpdate.DirectorLateUpdate is way too expensive (1.3ms)
Expected
There is almost no performance cost at all (nearly 0ms) because only four tracks and audio clips run at the same time. The performance should be affected by how many clips run simultaneously, not by how many clips exist in the entire timeline.
Wonder if this is involving all the major AudioResource refactoring.
There is six known audio related issues in the recent release notes. When Audio Random Containers (ARC) was introduced they made audio clips and ARC inherit from a new base class AudioResource (could be wrong on the exact name of the class) to allow both to be put in audio source inspector fields.
They have been doing a lot of major refactoring and updates to the audio system. Looks like something went wrong somewhere. One known bug is a memory leak related to ARC prefabs. Wonder if the link is actually in the base class of Audio Resource making both ARC and Audio Clips leak memory.
The bug report status has been “in review” for a month now and I’m wondering if that’s correct. I would have expected it to be confirmed by now.
