Please escalate to engineering : Severe frame-time spikes tied to audio load in dense combat

This is a copy of an email i sent to support, however they basically told me to f off and make a thread, so here i am. sorry for the bad formatting as it was originally a mail.



Hello, after doing some extensive research these past few days concerning performance issues and specifically audio related ones, i am begging you to escalate this detailed bug/performance report to the proper team, this is an extremely important issue and most likely the biggest performance hindering one you could fix. This would make your entire community happy.

Environment

Path of Exile 1

Windows

Reproducible in high-density combat scenarios

Issue scales down when lowering sound channels, largely disappears if sound is fully disabled

Summary
In dense combat, FPS drops and frame-time spikes line up very closely with the number of audio events being triggered. This doesn’t look GPU-bound — it behaves like the audio pipeline is the bottleneck.

Reducing sound channels helps a bit, but doesn’t fix it. Disabling sound almost completely removes the issue, which strongly suggests the problem sits inside audio processing itself rather than general rendering or simulation.

Expected Result
Audio should scale under heavy load without causing major frame-time instability. Muted or low-priority sounds shouldn’t consume meaningful CPU or mixer resources. Dense encounters shouldn’t tank FPS just because of sound activity.



Actual Result
During heavy combat:

FPS drops hard
Frame pacing becomes inconsistent
Performance degrades in proportion to the number of simultaneous sound events
Lowering channel count helps, but causes noticeable sound cutoffs
Disabling sound almost fully restores performance


Steps to Reproduce

Enable full audio
Set sound channels to default or high
Enter a dense encounter (lots of mobs, projectiles, deaths, overlapping effects)
Observe FPS/frame-time during peak activity
Then:
5. Lower sound channels → compare
6. Disable sound → compare again



Observed Behavior

Performance loss tracks closely with audio event density
Issue spikes during bursts, not constant load
Feels like contention between audio updates and the main loop
Lower channel count doesn’t fully solve it → suggests overhead beyond just active voices (likely event creation / scheduling / sync costs)
Technical Suspicions

Audio update (e.g. system update call) may be running on or blocking the main thread
Event submission could be hitting locks or a synchronized queue under load
Too many voices are promoted to “real” instead of being virtualized early
Muted/low-priority categories may still generate events and hit the mixer
DSP (reverb, ambient layers, bus processing) might be doing unnecessary work
Current category system might be too coarse to disable expensive audio without nuking everything
Impact
This is very noticeable in endgame content. It affects responsiveness and makes combat harder to read.

Current workarounds aren’t great:

Disabling sound fixes performance but removes useful feedback
Lowering channels reduces load but randomly drops important cues
Possible Fix Directions

1. Decouple audio from main thread
Move update/scheduling off the main thread or at least reduce sync points with render/simulation.

2. Actually disable muted categories
Muted shouldn’t mean “processed at volume 0.”
They shouldn’t spawn events or touch the mixer at all.

3. More granular audio controls
Split out categories like combat SFX, ambient, UI, filter sounds, reverb, etc.
Let players disable only the expensive parts.

4. Better voice management

Lower real-voice limits
Virtualize earlier (distance / priority)
Avoid DSP work for inaudible sounds
5. Profile worst-case scenarios properly
Test in real dense encounters:

Compare main thread vs audio thread time
Look for lock contention / queue buildup
Track voice churn and event spam
Why this should be looked at
The effect is strong enough to turn normal gameplay into a slideshow . The fact that performance changes dramatically when sound is reduced or disabled points pretty clearly to an engine-side issue, not user settings.

This looks like an audio scheduling / contention problem worth investigating properly.

Best Regards.