Audio DSP Load value

Hey all,

Anyone know exactly what this value relates to in the stats window? I'm messing around with OnAudioFilterRead and seeing some high values.

I'm presuming it's % of max available cpu time spent feeding the audio subsystem, but the value appears to fluctuate under steady work, and changes wildly depending on the gameObject selected in the scene hierarchy?!

Is it another value to take with a pinch of salt like the fps?

 

I have a quote from Coursera course from Unity:
"Another piece of information available in the game info panel is the DSP load which is a measure of how much audio performance your app is using."

 

It's likely because you're running (and measuring) this in the Editor

 

Thanks for the posts - not much wiser though :-/
Not found anything to measure this with in the (non-editor) profiling stuff - just basic cpu time so far.

 

I would only do very simple things in OnAudioFilterRead. C# is not fast enough and the speed fluctuates too much (e.g. garbage collection) for reliable audio processing.

Back to your problem though, I've seen weird behavior as well with the DSP number, especially on Mac. The size of the Game window can make it increase the DSP percent by up to 2x. I just keep DSP as low as possible (under 15%) so it's not a problem.

 

I've tried a few things in OnAudioFilterRead... I suppose the audio filter time is shared from the main cpu pool so any game-side load would affect the dsp load value.

Using native code instead of C# only reduced dsp load by about 10% (again though, an Editor measurement, so somewhat muddied).
The OnAudioFilterRead callback is not on the main Unity game thread and I don't allocate any memory in my processing (unless the callback process does!).

Of course, the audio system is shrouded in secrecy and lack of in-depth docs so who knows what's happening?

 

Unless it has been fixed in recent releases, which I doubt since my bug report is still open, using OnAudioFilterRead allocate memory every frame causing the garbage collection to fire often.
It was introduced around Unity 5 as a workaround to fix a crash and the audio devs told me to fix it it would require a total rewrite so it will stay like this.
https://issuetracker.unity3d.com/is...very-frame-instead-of-reusing-the-same-buffer

If you haven't noticed audio development is the lowest priority among all for Unity.

 

no, it doesn't in general
according to bugreport it does on iOS

 

I filed that bug report, so I am quite sure of what it does happen.
In iOS it's just easier to notice because you can use XCode profiler to see the GC finalizer thread, since it's not reported by Unity profiler probably because it's in another thread and I think the profiler only show data for the main thread.

 

You can see GC runs in the profiler so it would be pretty easy to setup a repro with otherwise empty scene showing GC collector running for some unknown reasons

If you noticed it on iOS that does not mean it's present on all platforms, so it would be very advisable to update the bugreport with findings on other platforms and not make the submission iOS specific

Me personally I've never noticed anything allocated with OAFR filter running - mostly Editors runs though - and I bet someone would by now

 

Hmm good points - I've not seen GC problems on PC in editor but as mentioned that may be the main game thread only.
Wonder if the newly supported Mono/.NET 4.6 has the improved GC stuff in it..?

 

GC is still more or less the same, but 4.6 runtime is 'better'
( better means should be performing better, has broader compatibility with the rest of the .NET world and is generally advisable to be used instead of 3.5 where possible )