From a6e52f9e48f51be1047e07b3869b55a67cdd5265 Mon Sep 17 00:00:00 2001
From: "Ryan C. Gordon" <[EMAIL REDACTED]>
Date: Tue, 12 Sep 2023 14:27:21 -0400
Subject: [PATCH] Sync SDL3 wiki -> header
---
include/SDL3/SDL_audio.h | 47 ++++++++++++++++++++--------------------
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/include/SDL3/SDL_audio.h b/include/SDL3/SDL_audio.h
index d2692aba2a17..6e6fbdb978e8 100644
--- a/include/SDL3/SDL_audio.h
+++ b/include/SDL3/SDL_audio.h
@@ -1143,36 +1143,35 @@ typedef void (SDLCALL *SDL_AudioPostmixCallback)(void *userdata, const SDL_Audio
* This is useful for accessing the final mix, perhaps for writing a
* visualizer or applying a final effect to the audio data before playback.
*
- * The buffer is the final mix of all bound audio streams on an opened
- * device; this callback will fire regularly for any device that is both
- * opened and unpaused. If there is no new data to mix, either because no
- * streams are bound to the device or all the streams are empty, this
- * callback will still fire with the entire buffer set to silence.
- *
- * This callback is allowed to make changes to the data; the contents of
- * the buffer after this call is what is ultimately passed along to the
- * hardware.
- *
- * The callback is always provided the data in float format (values from
- * -1.0f to 1.0f), but the number of channels or sample rate may be
- * different than the format the app requested when opening the device; SDL
- * might have had to manage a conversion behind the scenes, or the playback
- * might have jumped to new physical hardware when a system default changed,
- * etc. These details may change between calls. Accordingly, the size of the
- * buffer might change between calls as well.
+ * The buffer is the final mix of all bound audio streams on an opened device;
+ * this callback will fire regularly for any device that is both opened and
+ * unpaused. If there is no new data to mix, either because no streams are
+ * bound to the device or all the streams are empty, this callback will still
+ * fire with the entire buffer set to silence.
+ *
+ * This callback is allowed to make changes to the data; the contents of the
+ * buffer after this call is what is ultimately passed along to the hardware.
+ *
+ * The callback is always provided the data in float format (values from -1.0f
+ * to 1.0f), but the number of channels or sample rate may be different than
+ * the format the app requested when opening the device; SDL might have had to
+ * manage a conversion behind the scenes, or the playback might have jumped to
+ * new physical hardware when a system default changed, etc. These details may
+ * change between calls. Accordingly, the size of the buffer might change
+ * between calls as well.
*
* This callback can run at any time, and from any thread; if you need to
* serialize access to your app's data, you should provide and use a mutex or
* other synchronization device.
*
- * All of this to say: there are specific needs this callback can fulfill,
- * but it is not the simplest interface. Apps should generally provide audio
- * in their preferred format through an SDL_AudioStream and let SDL handle
- * the difference.
+ * All of this to say: there are specific needs this callback can fulfill, but
+ * it is not the simplest interface. Apps should generally provide audio in
+ * their preferred format through an SDL_AudioStream and let SDL handle the
+ * difference.
*
- * This function is extremely time-sensitive; the callback should do the
- * least amount of work possible and return as quickly as it can. The longer
- * the callback runs, the higher the risk of audio dropouts or other problems.
+ * This function is extremely time-sensitive; the callback should do the least
+ * amount of work possible and return as quickly as it can. The longer the
+ * callback runs, the higher the risk of audio dropouts or other problems.
*
* This function will block until the audio device is in between iterations,
* so any existing callback that might be running will finish before this