Sounds on the Server Side (Behavior Pack)

A common point of confusion for new creators is looking for a sounds folder inside a Behavior Pack. Bedrock's architecture strictly separates data from presentation. The server (Behavior Pack) never loads .ogg or .fsb audio files, nor does it read sound_definitions.json. Instead, the server deals solely in sound event identifiers—plain text strings like mob.zombie.say or custom_pack.magic_cast.

When a server-side system decides a sound should occur, it broadcasts a network packet containing that string identifier, a world position or entity target, a volume multiplier, and a pitch multiplier. Connected clients receive this packet and look up the string in their active Resource Packs. Primarily, the bridge happens in two Resource Pack files: RP/sounds/sound_definitions.json, which groups raw audio files under a string ID, and RP/sounds.json, which hooks those IDs into automatic engine events like footsteps, hurt noises, and block breaking.

Because the server only sends strings, a Behavior Pack can trigger custom sounds even if it has no direct dependency on the Resource Pack in its manifest, provided the player has the matching Resource Pack applied in the world or globally. Conversely, if the server sends a string the client does not recognize, the client simply fails silently and plays nothing.

Many server-side entity and item components have built-in properties for triggering sound events when specific gameplay conditions are met. When you configure these properties, you are telling the server which sound event ID to broadcast when the component activates.

Wait and ambient behaviors, interaction components, and projectile shooters all support sound properties. Note that in server-side entity JSON, the game frequently expects the short semantic name (such as convert_to_drowned or celebrate) mapped inside RP/sounds.json, though certain components and slash commands read the direct sound definition string from RP/sounds/sound_definitions.json. If a sound property in an entity behavior fails to play your custom ID directly, check whether the component expects a generic sound event name mapped in the entity's section of RP/sounds.json.

Below is a server-side entity fragment showing how minecraft:ambient_sound_interval and minecraft:interact fire sound events directly from the Behavior Pack.

{
  "format_version": "1.20.40",
  "minecraft:entity": {
    "description": {
      "identifier": "my_pack:merchant_guard",
      "is_spawnable": true,
      "is_summonable": true
    },
    "components": {
      "minecraft:ambient_sound_interval": {
        "value": 8.0,
        "range": 4.0,
        "event_name": "ambient"
      },
      "minecraft:interact": {
        "interactions": [
          {
            "on_interact": {
              "filters": {
                "test": "is_family",
                "subject": "other",
                "value": "player"
              }
            },
            "play_sounds": "mob.villager.yes",
            "swing": true
          }
        ]
      }
    }
  }
}

When you need to play a sound from an .mcfunction file, an entity event using run_command, or a command block, you use the /playsound command. Unlike entity components that sometimes rely on semantic names from RP/sounds.json, /playsound always looks up the exact key defined in RP/sounds/sound_definitions.json.

The command allows you to target specific players, set the 3D origin in the world, adjust the volume and pitch, and define a minimum volume for players who are outside the normal hearing radius. Be aware of how the volume parameter behaves for 3D positional sounds: values between 0.0 and 1.0 attenuate the volume as normal, while values above 1.0 do not make the audio louder at the center—instead, they increase the distance at which the sound can be heard.

This function example plays a custom alert sound at an entity's location for all nearby players, with a slight pitch variation.

playsound my_pack.horn_blast @a[r=32] ~ ~ ~ 1.5 0.9 0.1
particle minecraft:villager_angry ~ ~2 ~

For complex add-ons using the @minecraft/server Script API, triggering audio directly from TypeScript or JavaScript is much cleaner and faster than queuing /playsound commands. Both the Dimension and Player classes provide a playSound method that runs entirely on the server and dispatches the audio packet to the appropriate clients.

Use Dimension.playSound when a sound occurs at a physical location in the world and should be heard by anyone nearby—such as a custom machine finishing a craft or a boss slamming the ground. Use Player.playSound when the audio should only be heard by one specific person, which is ideal for custom UI clicks, quest completion jingles, or personal warning chimes.

Both methods take the sound definition ID as their first argument and an optional SoundOptions object where you can specify pitch, volume, and location.

import { world, system } from "@minecraft/server";

world.afterEvents.itemUse.subscribe((event) => {
  const player = event.source;
  const item = event.itemStack;

  if (item.typeId === "my_pack:Ruby_wand") {
    // Play a 3D positional sound for everyone in the dimension
    player.dimension.playSound("my_pack.wand_cast", player.location, {
      pitch: 1.2,
      volume: 1.0
    });

    // Play a private confirmation chime only for the caster
    system.runTimeout(() => {
      if (player.isValid()) {
        player.playSound("random.orb", {
          pitch: 1.5,
          volume: 0.5
        });
      }
    }, 20);
  }
});

A frequent design question is whether to trigger an entity's sound from a Behavior Pack animation controller or a Resource Pack animation controller. Both support sound effects, capability-wise, in different ways: Resource Pack animations have a dedicated sound_effects timeline key, whereas Behavior Pack animations can only fire /playsound commands on state entry, exit, or keyframes.

As a rule of thumb, keep visual and movement-synced audio—such as footsteps, wing flaps, and sword swooshes—inside the Resource Pack. This avoids unnecessary network traffic and ensures the audio aligns frame-for-frame with the model's movement. Reserve server-side sound triggers in the Behavior Pack for moments tied strictly to authoritative gameplay state, such as an attack dealing damage, a timer expiring, or a script event firing where the client would not otherwise know the event happened.

Applies to all modern Bedrock versions (1.16.0+ for JSON components and commands; 1.20.0+ for stable @minecraft/server playSound APIs). No experimental toggles are required.

Read out of the game itself, so the ids match the version you are building for.