Skip to content

Play Sound 2D / Play Sound at Location / Spawn Sound Attached

At a glance

Lives in: Blueprint API / Audio - Target: Gameplay Statics - Returns: Play Sound nodes return no sound reference; Spawn Sound Attached returns an Audio Component reference that may be None - Replicates? no, these calls only play on the machine that runs the graph - Main choice: UI sound, world-position sound, or sound that follows a component - Official docs: Play Sound 2D, Play Sound at Location, and Spawn Sound Attached

These nodes start sound playback. The big beginner question is not "how do I play audio?" It is which kind of sound lifetime am I creating?

The one-minute version

  • Play Sound 2D plays a non-positional sound such as a button click, pause-menu sound, or local warning beep.
  • Play Sound at Location plays a sound at a world position. It does not follow an actor after it starts.
  • Spawn Sound Attached creates an Audio Component, starts playback, and attaches that component to another scene component so the sound follows it.
  • The Play nodes are fire-and-forget. After you call them, Blueprint does not get an audio component back, so you cannot stop or fade that instance later.
  • For looping ambience, engine hum, charging sounds, or anything you might stop later, use a Spawn Sound... node and store the returned Audio Component.
  • These audio calls are not replicated. If a server graph calls one, that does not automatically make every client hear it.

The choice you usually need

Goal Use Why
Button click, menu open, local UI feedback Play Sound 2D No world position, no distance falloff, usually only for the local player.
Explosion at a point, coin pickup at its location Play Sound at Location The sound starts at one world location and can use attenuation.
Engine loop, torch crackle, weapon charge attached to a socket Spawn Sound Attached The sound follows a component and gives you an audio component to stop/fade.

If the sound is a short one-shot and you never need to touch it again, a Play node is fine. If the sound has a lifetime your Blueprint cares about, spawn an audio component.

What they actually do

All three nodes ask the audio system to start a Sound Base asset. The difference is the playback object and transform relationship they create.

pseudocode of the engine behavior - not engine source

PlaySound2D(Sound):
    if the world and sound are usable:
        create an internal non-spatial sound instance
        start it
    return nothing to Blueprint

PlaySoundAtLocation(Sound, Location, Rotation):
    if the world and sound are usable:
        create an internal sound instance at that world transform
        start it
    return nothing to Blueprint

SpawnSoundAttached(Sound, AttachComponent, SocketOrBoneName):
    if the world, sound, and attach component are usable:
        create an AudioComponent
        attach it to AttachComponent
        start it
        return the AudioComponent
    return None if the component cannot be created

The Play calls still create internal audio playback state, but they do not hand that object back to your Blueprint. That is the whole reason a loop made with Play Sound 2D feels "unstoppable": your graph no longer has a reference to that individual sound instance.

The pins that matter

Sound

The sound asset to play. If this is empty, no useful playback can happen. Use Is Valid style thinking for sound variables that are optional or assigned from data.

Volume Multiplier and Pitch Multiplier

These are linear multipliers for this playback call. 1.0 means "use the asset's normal value." 0.5 is quieter or lower; 2.0 is louder or higher. They do not permanently edit the sound asset.

For long-term mix control, use sound classes, sound mixes, submixes, or audio settings. These pins are per-playback tweaks.

Start Time

Start playback partway through the sound. This is useful for variation or resuming a known offset. It is not a delay. To delay playback, use a timer, timeline event, animation notify timing, or another scheduling path.

Attenuation Settings

On world sounds, attenuation controls how the sound behaves with distance and spatialization. A common beginner trap is assuming Play Sound at Location automatically makes distance falloff sound right for every asset. The location gives the audio system a position; attenuation settings decide how that position affects what the listener hears.

Concurrency Settings and Owning Actor

Concurrency limits how many matching sounds can play at once. Owning Actor does not attach, move, or own the sound in the lifetime sense. It is used for concurrency grouping, such as "limit this actor to one footstep sound from this concurrency group."

This is another place where Unreal's word "owner" is easy to misread. It is not the same as attachment, possession, or object lifetime. See Ownership and lifetime.

Attach to Component and Attach Point Name

Spawn Sound Attached needs a scene component to follow, such as a character mesh, weapon mesh, vehicle root, or a socket-bearing component. The optional attach point is a socket or bone name on that component.

If the attach component is None, the returned audio component can be None. If the socket name is wrong, the sound may attach to the component without the offset you expected, depending on the component and attachment setup.

Location Type

For attached sounds, this decides whether the Location/Rotation pins are treated as a relative offset from the attach point or as a world transform that gets converted into an attached offset.

For most first projects:

  • use a socket and Snap to Target/relative style setup when the sound should sit exactly on a hand, muzzle, engine, or torch;
  • use relative offsets when you want a tuned offset from the component;
  • use world-position behavior only when you know why you are preserving the current world placement during attachment.

Stop when Attached to Destroyed

If true, the sound stops when the attached actor/component path is destroyed. That is usually right for engine hum, weapon charge, or attached ambience. If false, you are saying the sound may keep going even after the thing it was following is gone.

Auto Destroy

If true, the returned Audio Component cleans itself up when playback ends or is stopped. For one-shot spawned sounds, that is convenient.

If false, the component can be reused or reactivated, but now you own the reference and cleanup. Do not turn Auto Destroy off just because it sounds "safer"; it can leave components around if you never manage them.

The looping-sound pattern

The pattern everyone eventually needs:

Start engine / ambience / charge
-> Spawn Sound Attached
-> promote Return Value to EngineLoopAudio

Stop engine / ambience / charge
-> Is Valid (EngineLoopAudio)
-> Fade Out or Stop
-> clear EngineLoopAudio if you are done with it

Use Fade Out when a hard stop sounds bad. Use Stop when the sound should end immediately, such as cancelling a short charging sound.

The C++ twin, for the curious (our own example code):

void AHoverBike::StartEngineLoop()
{
    if (!EngineLoop || !Mesh)
    {
        return;
    }

    EngineAudio = UGameplayStatics::SpawnSoundAttached(
        EngineLoop,
        Mesh,
        TEXT("EngineSocket"),
        FVector::ZeroVector,
        FRotator::ZeroRotator,
        EAttachLocation::SnapToTarget,
        true);
}

void AHoverBike::StopEngineLoop()
{
    if (IsValid(EngineAudio))
    {
        EngineAudio->FadeOut(0.25f, 0.0f);
        EngineAudio = nullptr;
    }
}

Multiplayer: why nobody else hears it

Epic marks these gameplay audio helpers as not replicated. That means the call plays on this machine only:

Client runs Play Sound 2D
-> that client hears it
-> server and other clients do not

Server runs Play Sound at Location
-> listen server host may hear it
-> remote clients do not automatically hear it

For multiplayer, decide who needs to hear the sound:

Sound Common multiplayer shape
Local UI click, hit marker, low-health warning Run only on the owning client.
Explosion everyone nearby should hear Server validates gameplay event, then clients learn about it through replicated actor state, a multicast event, or another project-specific cue path.
Weapon fire from a replicated projectile Server spawns/replicates the gameplay actor; clients play cosmetic audio when the replicated event/state appears.
Loop attached to a replicated actor Replicate the state that means "engine is on," then each relevant client starts/stops its local audio component.

Do not replicate the audio component reference as your first idea. Replicate the gameplay state or event that makes clients decide to play audio locally.

When nothing plays

  1. Sound is empty. The node has nothing to play.
  2. The graph did not run. Input mode, mapping context, overlap filters, or authority branches may stop execution before the audio node.
  3. You played it on the wrong machine. A server-only event is not the same as a client hearing audio.
  4. The sound is too quiet or out of range. Check volume, sound class, attenuation, and listener position.
  5. The sound started at a bad Start Time. Starting near the end of a short asset can make it appear not to play.
  6. Concurrency stopped or limited it. The new sound may be rejected or an old one may be stopped, depending on concurrency settings.
  7. The attach component is missing. Spawn Sound Attached can return None; guard and print the component reference while debugging.

Use Print String and the Output Log to prove the graph runs, then print the sound and attach-component references before blaming the audio system.

Lookalikes - which one do I want?

Node Returns Use when
Play Sound 2D Nothing One-shot local UI or non-positional sound.
Play Sound at Location Nothing One-shot world sound at a fixed point.
Spawn Sound 2D Audio Component Non-positional sound you may stop, fade, or keep across level travel when configured.
Spawn Sound at Location Audio Component World sound at a position that you may stop/fade, but that does not need to follow a component.
Spawn Sound Attached Audio Component Sound should follow a scene component/socket and may need lifetime control.
Audio Component placed in an actor A component you already own Persistent actor sounds such as machinery, ambience, or reusable sound emitters.
Anim Notify / Sound Notify Usually no Blueprint reference Footsteps, attack swings, and animation-timed one-shots.

Going deeper

  • Ownership and lifetime - why audio "owning actor" is not attachment or possession.
  • Attach Actor To Component - the transform/socket mental model that attached sounds also use.
  • Open Level - why world travel can stop or orphan old-world audio plans.
  • Spawn Actor from Class - spawning a replicated gameplay actor whose state can drive local client audio.
  • Official docs: Play Sound 2D, PlaySoundAtLocation, Spawn Sound Attached, SpawnSound2D, and Audio Engine Overview.
  • Engine source (requires engine access - we do not reproduce it here): UGameplayStatics::PlaySound2D, UGameplayStatics::PlaySoundAtLocation, UGameplayStatics::SpawnSound2D, UGameplayStatics::SpawnSoundAtLocation, and UGameplayStatics::SpawnSoundAttached are declared in Engine/Source/Runtime/Engine/Classes/Kismet/GameplayStatics.h and implemented in Engine/Source/Runtime/Engine/Private/GameplayStatics.cpp; lower-level active sound creation continues through the audio device code in Engine/Source/Runtime/Engine/Private/AudioDevice.cpp.