With 6 or more players in the same area — walking through bushes, opening doors, moving around each other — audio breaks down completely. Sounds cut out mid-playback and retrigger constantly, across every category: footsteps, foliage, doors, weapons. It affects everyone in the group at once.

This is at its worst with big groups moving through forests and bushes. The more players in the group, the worse it gets — it scales directly with how many people are inside each other's audio range. A squad running through a treeline together is the reliable way to trigger it.

The cause is exhaustion of the concurrent played-samples limit (**maxSamplesPlayed**, default 96). The limit itself is reasonable — the problem is that almost nothing in the game declares soundObjectsLimit, so a small number of soundsets consume the entire budget and everything else gets dropped arbitrarily.

Measured in DayZDiag with the Sounds Debug overlay: standing completely still in a broadleaf forest, no players or infected nearby, already plays 21 concurrent samples. That is 22% of the budget with zero gameplay activity.

Of those 21 samples:

- 13x WindTreeLargeLeaves_SoundSet

- 2x WindTreeMediumLeaves_SoundSet

- 3x Forest_Birds_Day_SoundSet

- 3x 2D ambient beds (WindForestLight, MeadowDay, ForestDay)

WindTreeLargeLeaves_SoundSet is loop=1, spatial=1, and spawns one permanent looping instance per nearby tree (observed at 9-23m). It declares no soundObjectsLimit. In denser forest the count is higher.

This is why forests are the worst case: the ambient tree emitters have already consumed a fifth of the budget before anyone moves. Add a group of players on top, each generating uncapped footsteps, foliage brushing, clothing rustle and breathing, and the 96 ceiling is hit almost immediately.

ANALYSIS

Across DZ\sounds\hpp\config.cpp (~15,310 soundsets) only 216 declare soundObjectsLimit, and they are almost entirely weapon shot/tail/reload sets plus baseShells_SoundSet. The following are completely uncapped:

- Player footsteps (**baseFootsteps_SoundSet**) — 399 soundsets

- Bush/foliage (**bush_*_SoundSet**) — 5 soundsets

- Character gear/actions (**baseCharacter_SoundSet**) — 2,533 soundsets

- Infected footsteps (**baseFootstepsZmb_SoundSet**) — 577 soundsets

- Infected voices (**Zmb_VoiceFX_Base_SoundSet**) — 373 soundsets

- Animals/birds (**baseAnimal_SoundSet**) — 1,193 soundsets

- Vehicles (**baseVehicles_SoundSet**) — 59 soundsets

- Wind/rain per-tree emitters — 44 soundsets

Notably, WindTreeCreak3D_SoundSet and WindTreeCreakHeavy3D_SoundSet do carry soundObjectsLimit=1. So the per-emitter stacking problem is clearly recognised for tree creaks, but the far more numerous leaf-rustle variants never got the same treatment. That reads as an oversight rather than a design decision.

Two further gaps:

- SMG_Tail_Interior_Base_SoundSet, SMG_Tail_Silencer_Interior_Base_SoundSet and Heavy_Explosion_Tail_Base_SoundSet declare no limit, while every sibling tail base uses 2.

- Bullet impacts cannot be bounded at all. CfgAmmo defines them as raw sample arrays soundMetal1[] = {"...", 0.6, 1, 80}), not soundsets, so soundObjectsLimit does not apply.

IMPACT

This makes group gameplay unbearable. Squad play, base raids and populated towns become an audio mess where you cannot reliably hear footsteps, doors or an approaching player — the exact cues DayZ's gameplay depends on. It is trivially reproducible with an ordinary group size and is present on stable.

SERVER OWNERS CANNOT WORK AROUND THIS

soundObjectsLimit caps concurrent instances per soundset. It bounds many emitters sharing one soundset (tree rustle), but cannot bound a diverse population: 20 infected spread across roughly 20 distinct voice soundsets sit at 1 instance each, so a cap on the base class never engages. Infected footsteps (577 sets, split by gait x surface x footwear) have the same problem, and unlike vocalisations there is no probability setting to reduce them either.

We attempted a config-only mitigation and were only able to bound the ambient tree emitters. The player-proximity case remains unfixable from a mod.

MULTIPLAYER (the player-facing bug)

1. Get 6 or more players into one area, within roughly 20m of each other.

2. Have them walk and run through bushes, open doors, move around each other, reload weapons, move items, fire weapons.

3. Audio begins cutting out and retriggering for everyone present.

SOLO, MEASURABLE (the underlying cause)

1. Launch DayZDiag_x64.exe and open the Sounds Debug overlay.

2. Stand still in a broadleaf forest, with no players and no infected nearby, in clear weather.

3. Read the "Playing:" counter and the source list.

4. Observed: 21 samples playing, 13 of them WindTreeLargeLeaves_SoundSet, while completely stationary and alone.

Ambient and high-frequency character sounds should be bounded so they cannot starve the concurrent sample budget, in the same way weapon soundsets already are.

In a game like DayZ, audio is not cosmetic — it is a core gameplay mechanic. Hearing footsteps, a door, a reload or someone brushing past a bush is often the only warning a player gets. Audio dropping out under normal group play is a fundamental failure of a system the game's survival and PvP loops depend on, and it should not be reachable through ordinary gameplay.

Specifically, soundObjectsLimit should be declared on:

- the WindTree\* and RainTree\* per-emitter families

- baseFootsteps_SoundSet

- bush_\_SoundSet

A cap on tree rustle is inaudible. Four trees versus thirteen is the same wash of noise, and it immediately returns around 9 slots to the budget.

With those bounded, audio should remain stable with a normal group of players in one area — no cutouts, no retriggering, and no loss of the positional cues players rely on to survive.