Background music that isn't set to Streaming stays resident in memory

Streaming load type reads an audio clip from disk in chunks during playback, keeping only a small buffer in memory. For a three-minute music track that’s the difference between a few hundred kilobytes and tens of megabytes resident, for a sound that plays exactly once at a time.

What the scan looks at

Clips of 30 seconds or more whose Load Type is not Streaming, on the active build target. WebGL is excluded: the platform’s audio backend doesn’t support streaming the way the others do, so the advice wouldn’t be actionable there.

Why it costs you

Music and ambience are usually the longest assets in a project and the ones playing least often — one or two voices at a time. Loading them fully (whether decoded via Decompress On Load or compressed via Compressed In Memory) reserves memory for the whole duration of the scene, when a rolling buffer would do.

How to fix it by hand

Select the clip, set Load Type to Streaming, reimport. Two things to know:

• Streaming voices are not free. Each one costs a file handle and a decode thread’s worth of work. Unity’s guidance is to keep the number of simultaneously streaming clips small — music plus a couple of ambience beds, not fifty overlapping one-shots.
• First-play latency is higher, since playback waits on the first buffer. That’s fine for music with a fade-in, and wrong for a sound that must land on a frame.

For clips in the middle — a few seconds to half a minute — Compressed In Memory is usually the right answer instead: see PERF.AUD001.

What PerfLint does about it

The finding lists long clips with their durations and current load type. Pro can set them to Streaming from the row. It’s Info rather than Warning because a small number of long clips loaded in full is a legitimate choice — the point is to make sure it was a choice.