Wwise SDK 2018.1.11
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.
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.
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.
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
in_uiFlags. If you also want to have the end of event notification, you should use
AK_Markersince the flags are bitwise exclusive.
- Your callback function must have the following form:
- 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_Markernotifications, you should return when any other event type is received.
- Based on the type of notification, you can typecast
in_pCallbackInfointo the appropriate information structure type. For AK_Marker notification, it is AkMarkerCallbackInfo.
- Make sure you copy the contents of the
strLabelstring 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 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.
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