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. |
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.
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;
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
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)
Here are instructions on how to design your application so that it receives the marker notifications:
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.AkPlayingID AK::SoundEngine::PostEvent( 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 );
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*. )
AK_Marker
notifications, you should return when any other event type is received.in_pCallbackInfo
into the appropriate information structure type. For AK_Marker notification, it is AkMarkerCallbackInfo.// Callback information structure corresponding to AK_Marker. struct AkMarkerCallbackInfo : public AkEventCallbackInfo { 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 };
strLabel
string member if you plan to reference it later, as the pointer can be invalidated after the callback returns.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.
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.
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.
Des questions ? Des problèmes ? Besoin de plus d'informations ? Contactez-nous, nous pouvons vous aider !
Visitez notre page d'AideEnregistrez votre projet et nous vous aiderons à démarrer sans aucune obligation !
Partir du bon pied avec Wwise