The .snd file is a text file – Unix or Windows line endings are legal, blank lines are allowed after the header, and the character set should be UTF-8.

The header of the file should be

A
1000
ACF_SOUNDS

Unlike some other X-Plane text file formats, the .snd file requires paired BEGIN and END directives for major subsections. Having a BEGIN directive without its matched END directive is an error.

Dataref Matching Conditions

Dataref-based trigger conditions use a simple logic language, of the form

<dataref> <operator> <constant value>, e.g.

sim/flightmodel2/engine/N1_percent[0] >= 12.5

The condition evaluates to true or false based on the comparison constant (see the list below). The conditions are evaluated every frame with the current dataref value and may then trigger FMOD events.

Unlike normal datarefs, you can prefix the dataref with DELTA= or ABS_DELTA=. If you do this, the value in the condition is not the dataref itself, but its rate of change (per second). ABS_DELTA applies an absolute value.

For example, the condition

DELTA=sim/flightmodel2/engine/N1_percent[0] > 10

Would return true if N1 is growing at a rate of more than 10 per second. Using ABS_DELTA would cause the condition to also indicate true when N1 was falling by more than 10 per second.

DELTA and ABS_DELTA can be used to play sounds when a rate of change is detected in a dataref, even if the sim doesn’t provide a rate of change dataref directly. For example, the flaps, the flaps actual position is provided by X-Plane but their rate of movement is not. To correctly play a flap motor sound, DELTA is needed.

(Playing the sound based on the flap down command would be wrong: if the electrical system is broken, the flaps may not move even when the command is pressed. Thus the actual movement of the flaps should be the trigger for the sound, not the command.)

Constants Used In The File Format

Where datarefs can be compared, the valid comparison operators are:

  • < (less than)
  • <= (less than or equal)
  • == (equality)
  • != (not equals)
  • >= (greater than or equal)
  • > (greater than)

The valid part names for aircraft attachments are:

  • engine – the sound is attached to the engine – index refers to the engine number.
  • tire – the sound is attached to a tire – index refers to the tire gear number.
  • cockpit – the sound is roughly in front of the pilot.

General Directives

These directives should appear at the beginning of the file.

REQUIRES_BANK <bank name>
This causes X-Plane to load the bank specified by name from the FMOD folder. This is needed for any bank you wish to use for this ACF other than the master bank.

DISABLE_LEGACY_ALERT_SOUNDS
New to X-Plane 11.30, adding this to the SND file will prevent X-Plane from playing any legacy aircraft alert sounds.

Sound Attachment Directives

Each sound attachment block defines a single attached “sound” on the aircraft. You must use a matched pair of BEGIN_SOUND_ATTACHMENT and END_SOUND_ATTACHMENT. In this block you must have:

  • Exactly one of EVENT_NAME or SNAPSHOT_NAME to specify the FMOD object being played.
  • Exactly one of VEH_XYZ or VEH_PART to specify the FMOD object’s location in space.
  • At least one of the triggering methods (e.g. EVENT_xxx) so the FMOD object plays. This can be omitted, but then the FMOD event will never play.

Note: while all dataref triggers (start, end, cue) can be combined, only one command trigger can be used, and it cannot be combined with any dataref triggers.

BEGIN_SOUND_ATTACHMENT
This begins the definition of a new sound attachment. All sound attachment properties must be specified after this directive and before the matched END_SOUND_ATTACHMENT directive.

END_SOUND_ATTACHMENT
This defines the end of a given sound attachment. Each sound attachment must be “ended” before anything else in the file occurs, and before the file ends.

EVENT_NAME <fmod string name>
This defines an FMOD event (by string name) that this attachment plays.

SNAPSHOT_NAME <fmod string name>
This defines an FMOD snapshot (by string name) that this attachment plays. Snapshots change the mix while they are being “played” and stop taking effect when stopped.

VEH_XYZ <x> <y> <z>
This sets the location of your event to the location X,Y,Z in meters, relative to the default CG of the aircraft; X is right, Y is up, Z is aft.

VEH_PART <part_enum> <part_idx>
This attaches your sound to a specific part of the aircraft; where the aircraft can have multiple parts (e.g. engines) a zero-based index is used.

EVENT_ALLOWED_FOR_AI
If this directive exists, the sound is used when your aircraft is flown by the AI as well as the user; if it is omitted, the sound is for the user’s aircraft only. Do not attach internal cockpit sounds like switch clicks to the AI aircraft.

PARAM_DREF_IDX <dref_idx>
For sound parameters that use wild-cards for indices, e.g. sim/flightmodel2/engines/N1_percent[*] this specifies the index to be used for this attached sound. This lets you make a single event for all engines and then vary the index to get correct match-up to the engine params of a particular engine in a multi-engine aircraft.

EVENT_START_COND <dref> <op> <value>
This causes the event to start playing when the listed dataref changes in relationship to the specified value.

EVENT_END_COND <dref> <op> <value>
This causes the event to stop playing when the condition becomes true.

EVENT_ALWAYS
This causes the event to always be played. Playing events costs CPU even if the event is not making sound, so only use this if you really need the event to always be playing. An example of an always-playing event might be a mix-automation event that is constantly adjusting your mix in response to datarefs.

For sounds that really stop (e.g. engine noise), use event conditions to completely stop the event (or allow it to end playing with cues) once appropriate.

CUE_TRIGGER_COND <dref> <op> <value>
This sets the conditions on which the “cue” is sent to FMOD for the given event, based on a dataref equation.

EVENT_CMND_DOWN <cmnd>
This causes the event to play when a command is pressed down. Since you can use only one command trigger per event, this is meant for a self-terminating sound like a switch clicking on the down press.

EVENT_CMND_UP <cmnd>
This causes the event to play when a command is released. Since you can use only one command trigger per event, this is meant for a self-terminating sound like a switch clicking when released.

EVENT_CMND_HOLD_STOP <cmnd>
This causes the event to be started when the command is pressed down, and stopped when the command is released. E.g. the event plays for the duration the command is pressed.

EVENT_CMND_HOLD_CUE <cmnd>
This causes the event to be started when the command is pressed down, and cued when the command is released; the intention is that the sound event can loop during the duration of the command and then cue an ending part when the command is released, followed by stopping itself.

EVENT_AUTO_END_FROM_START_COND
New to X-Plane 11.30. Added to a sound EVENT, this will cause the sound to stop whenever ANY of the Dataref start conditions are no longer true.

Sound Space Definitions

X-Plane supports up to 64 3-d “sound spaces” defined in and near your aircraft. The intention is to mark internal regions of your aircraft so that X-Plane can provide datarefs showing camera location for mixing purposes.

Each sound space contains one or more volume primitives; the sound space is the union of the space covered by those volumes. Both disjoint and overlapping volumes are allowed. Where a soft blend-depth is used, it is based on the mathematical boundary of the union of the bounding volume.

BEGIN_SOUND_SPACE
This begins definition of a sound space. Sound spaces must be terminated with END_SOUND_SPACE before another one can be started or an event can be added, and sound spaces cannot be nested in sound attachments.

END_SOUND_SPACE
This terminates an existing sound space.

SOUND_INDEX <index>
This is a required directive (once inside each sound space) and defines the sound space’s index (0-63) in X-Plane; this is used to “publish” penetration ratios for that sound space.

BLEND_DEPTH <distance meters>
This defines a soft transition region starting at the mathematical edge of the volume and moving inward; the inside ratio dataref goes from 0 at the mathematical edge of the volume to 1.0 at “distance meters” inside.

SPHERE <center x> <center y> <center z> <radius>
This adds a sphere to the sound space, defined by location and radius in meters, referenced relative to the CG of the aircraft.

AABB <minx> <miny> <minz> <maxx> <maxy> <maxz>
This adds an axis-aligned bounding box (in aircraft coordinates, that is +X = right, +Y = up, +Z = aft) in meters around the CG of the aircraft.

6 comments on “Sound (.snd) File Format Specification

  1. Why are the sound spaces referenced to the Center of Gravity. This makes no sense to me, as the Center of Gravity is simply an arbitrary number assigned in Planemaker relative to the aircraft datum point, to which the whole aircraft was originally modeled around. If the sound spaces were referenced to the datum point, the coordinates for the sound spaces for the VEH_XYZ, SPHERE and AABB directives can be picked right off the model; much simpler. When referenced to the CG, the coordinates have to be adjusted by the moment arm of the CG. Sound space coordinates are a function of the aircraft weight & balance ?!? What am I missing?

    1. Hi Gerry,

      The sound spaces are referenced to to the DEFAULT center of gravity – that is, the place you put the CG _before_ it moves forward/aft due to loading.

      So it does have to be offset from the datum, and I do agree – this is annoying. This happened because the file is not edited in Plane-Maker – it is typically worked on “live” in X-plane; when we have visual editing of the file this will be pretty transparent.

      But the CG offset does NOT affect sound – putting a big guy in the front seat and moving the CG forward has NO affect on sound placement.

      (Internally in x-plane all reference to the aircraft is in terms of default CG at flight time.)

Leave a Reply

Your email address will not be published. Required fields are marked *

Please do not report bugs in the blog comments.
Only bugs reported via the X-Plane Bug Reporter are tracked.