Why does au.Debug.Sounds.Sort show a squared priority value for spatialized AudioComponents?

Development Audio
, ,
1

Environment

  • Unreal Engine 5 (currently 5.6, Windows)
  • Audio Mixer enabled
  • Mostly MetaSound-based sources using spatialization + attenuation assets

What I’m seeing

After setting an

AudioComponent’s

Priority and running the

au.Debug.Sounds.Sort console command, the on-screen debug list displays a squared version of that priority for spatialized sounds. Examples (rounded): a priority of P appears as roughly P² in the debug output (e.g.,

1.5 → ~2.25,

2.0 → ~4.0). Non-spatialized sounds do not seem to show this behavior (or it’s not obvious).

How I’m setting it (simplified)

// Spatialized + attenuation
AudioComponent->bAllowSpatialization = true;
AudioComponent->AttenuationSettings  = AttenuationAsset; // or Sound Attenuation asset
AudioComponent->Priority             = ContextPriority;  // tuned per 1P/3P context

Questions

  1. Is the squared transform in

au.Debug.Sounds.Sort Priority1. intentional for spatialized sounds?
2. Is this squared transform display-only for debugging/sorting emphasis, or is it actually applied in runtime concurrency/virtualization decisions as well? If it does affect runtime behavior, what’s the reasoning/design rationale behind it?

Extra context

We’re balancing first-person vs third-person (ally/enemy) mixes via different attenuation/sound classes and context-specific priority values. The squared value in the debug view makes it unclear whether our authored priority or the transformed value is what truly drives culling/virtualization.

​

Note: This question was written in English via translation so I could ask it here. Apologies for any awkward phrasing, and thanks for your understanding.

Thank you for reading!

2

So in order for that priority override to work, you have to also set the bool.

Property on audio component:

	/** Whether or not to override the priority of the given sound with the value provided. */
 	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Sound, meta = (InlineEditConditionToggle, DisplayAfter = "HighPassFilterFrequency"))
 	uint8 bOverridePriority:1;

In the audio component play function it checks the bool before overriding it. Here’s the code in the Audio Comoponen

	// The priority used for the active sound is the audio component's priority scaled with the sound's priority
 
	if (bOverridePriority)
 	{
 		NewActiveSound.Priority = Priority;
 	}
 	else
 	{
 		NewActiveSound.Priority = SoundToPlay->Priority;
 	}

So this AC priority just overrides the underlying USoundBase priority.

This priority can be scaled (by attenuation settings) or other things, but ultimately it gets handed off to FWaveInstance, which then is scaled, by default, with the “logical” volume of the sound, if the sound has a logical volume greater than 0.0. This allows for a more natural default sort in the final polyphony sort (see FAudioDevice::GetSortedActiveWaveInstances).

Here’s the code that retrieves priority on the wave instance:

float FWaveInstance::GetVolumeWeightedPriority() const
{
	// If priority has been set via bAlwaysPlay, it will have a priority larger than MAX_SOUND_PRIORITY. If that's the case, we should ignore volume weighting.
	if (Priority > MAX_SOUND_PRIORITY)
	{
		return Priority;
	}
 
	// This will result in zero-volume sounds still able to be sorted due to priority but give non-zero volumes higher priority than 0 volumes
	float ActualVolume = GetVolumeWithDistanceAndOcclusionAttenuation();
	if (ActualVolume > 0.0f)
	{
		// Only check for bypass if the actual volume is greater than 0.0
		if (WaveData && WaveData->bBypassVolumeScaleForPriority)
		{
			return Priority;
		}
		else
		{
			return ActualVolume * Priority;
		}
	}
	else if (IsStopping())
	{
		// Stopping sounds will be sorted above 0-volume sounds
		return ActualVolume * Priority - MAX_SOUND_PRIORITY - 1.0f;
	}
	else
	{
		return Priority - 2.0f * MAX_SOUND_PRIORITY - 1.0f;
	}
}

There is nothing squaring priority that I can see though there could be multiplies on it depending on the logical volume of the sound, etc.

I recommend trying out Audio Insights to look at sound data. We’re in the process of moving to that vs on-screen debug cvars.