Table of Contents

Wwise SDK 2018.1.11
Integrating Markers

Introduction

Markers are identifiers that are inserted in a WAV file and used to tag a position in the waveform. These markers are usually created in a WAV editor application, such as SoundForge®, Adobe® Audition®, or CueTool.

An application can use these markers to be notified when a certain position is reached during playback. For example, you could use this information to synchronize content drawing with the audio being played, or to know which file is being played by a random container so that the correct subtitles can be displayed in your game.

Note: Using Wwise marker notifications is usually the most efficient way to integrate a lip-sync or subtitle solution.

Working with the.wav File Format

Chunks are data storage units used to store cue points, or data about cue points. Cue points are points of interest flagged in .wav format files.

Cue Chunks

The cue chunk format is used to store marker positions that indicate points of interest in a .wav file.

Offset Bytes Description Value
0x00 4 Chunk ID "cue " (0x63756520)
0x04 4 Chunk Data Size Depends on the number of cue points
0x08 4 Num Cue Points Number of cue points in list
0x0c Cue Points
#define CueID 'cue ' /* chunk ID for cue chunk */
typedef struct {
ID chunkID;
long chunkSize;
long dwCuePoints;
CuePoint points[];
} CueChunk;
typedef struct {
long dwIdentifier;
long dwPosition;
ID fccChunk;
long dwChunkStart;
long dwBlockStart;
long dwSampleOffset;
} CuePoint;

List Chunks

A list chunk is a container inside the .wav file which contains subchunks. The associated data list chunk (adtl) format is used to store labels, notes, and text associated to a cue point.

Offset Bytes Description Value
0x00 4 Chunk ID "list" (0x6C696E74)
0x04 4 Chunk Data Size Depends on contained sub-chunks
0x08 4 Type ID "adtl" (0x6164746C)
0x0c SubChunks start here

Label Sub-Chunks

The label sub-chunk format is used to store a string associated with a cue point. It should be inside the associated data list chunk.

Offset Bytes Description Value
0x00 4 Chunk ID "labl" (0x6C61626C)
0x04 4 Chunk Data Size Depends on size of text
0x08 4 Cue Point ID Refers to cue chunk dwIdentifier
0x0c Label (variable-size text)

How to Use Marker Notifications

Here are instructions on how to design your application so that it receives the marker notifications:

  • When posting a play event, you should add the AK_Marker flag to in_uiFlags. If you also want to have the end of event notification, you should use AK_EndOfEvent | AK_Marker since the flags are bitwise exclusive.
AkUniqueID in_eventID, // Unique ID of the event
AkGameObjectID in_gameObjectID, // Associated game object ID
AkUInt32 in_uFlags = 0, // Bitmask: see AkCallbackType
AkCallbackFunc in_pfnCallback = NULL, // Callback function
void * in_pCookie = NULL // Callback cookie that will be sent to the callback function
// along with additional information
);
  • Your callback function must have the following form:
static void MarkersCallback(
AkCallbackType in_eType, // Type of callback reason, in this case AK_Marker on
// reception of a marker event.
AkCallbackInfo* in_pCallbackInfo // Pointer to callback information structure, in this case
// AkMarkerCallbackInfo*.
)
  • When your callback function is called, you first need to check what type of notification is passed. For example, if you only want to process AK_Marker notifications, you should return when any other event type is received.
  • Based on the type of notification, you can typecast in_pCallbackInfo into the appropriate information structure type. For AK_Marker notification, it is AkMarkerCallbackInfo.
// Callback information structure corresponding to AK_Marker.
{
AkUInt32 uIdentifier; // Cue point identifier
AkUInt32 uPosition; // Position in the cue point (unit: sample frames)
const char * strLabel; // Label of the marker, read from the file
};
  • Make sure you copy the contents of the strLabel string member if you plan to reference it later, as the pointer can be invalidated after the callback returns.
See also
Quick Start Sample Integration - Events

Notification Latency

Currently, notification is sent when the buffer is passed down to the hardware. This means that there is a certain constant delay between when the notification is sent and the marker is encountered. This gives your application enough time to gather the information on the marker and process it before the sound associated with that marker is really played.

Note that this delay is platform-dependent.

Callback Thread

The callbacks for markers, as well as for the end of event notification, are done from the sound engine's main thread. This means that your application should gather all the information it needs from the notification and return immediately. If any processing needs to be done, it should be performed in a separate thread once the relevant information has been copied from the notification.

If the application holds the thread for too long, the sound engine might fall into an underrun state and the output might stop playing.

Note
The label string from the callback function should be copied because the referenced data will be released by the sound engine after the callback function returns.

Wwise Capture Log and Markers

The Wwise Profiler can display marker notifications from the sound engine. In order to do so, you must ensure that the Markers Notification Data option in the Profiler Settings dialog is enabled. When a marker is reached and a notification has been requested, a new line will appear in the Capture Log. Note that these notifications can be filtered out if needed by clearing the Markers Notification Data check box in the Capture Log Filter dialog.

See also
Integration Details - Events