Add ma_device_get_period_size_in_frames().

miniaudio.h

@@ -9777,6 +9777,31 @@ If you are a normal consumer of miniaudio, do not ever call this function. It sh
 MA_API ma_result ma_device_update_descriptor(ma_device* pDevice, ma_device_type deviceType, const ma_device_descriptor* pPublicDescriptor, const ma_device_descriptor* pInternalDescriptor);
 
 
+/*
+Gets the period size of the device in frames.
+
+The returned value will be the frame count that will be passed into the data callback, except for
+when the `noFixedSizedCallback` config option is set to true during device initialization. In this
+case the returned value will be the period size that backend has reported, which might be
+unreliable.
+
+
+Parameters
+----------
+pDevice (in)
+    A pointer to the device whose period size is being retrieved.
+
+
+Return Value
+------------
+The period size of the device.
+
+If you configured the device with `noFixedSizedCallback = MA_TRUE` the returned value should be
+treated as a hint.
+*/
+MA_API ma_uint32 ma_device_get_period_size_in_frames(ma_device* pDevice);
+
+
 /*
 Sets the master volume factor for the device.
 
@@ -50549,6 +50574,23 @@ MA_API void ma_device_get_internal_channel_map(const ma_device* pDevice, ma_devi
     }
 }
 
+MA_API ma_uint32 ma_device_get_period_size_in_frames(ma_device* pDevice)
+{
+    if (ma_device_get_type(pDevice) == ma_device_type_playback) {
+        if (pDevice->playback.intermediaryBufferCap > 0) {
+            return pDevice->playback.intermediaryBufferCap;         /* Using a fixed sized processing callback. */
+        } else {
+            return pDevice->playback.internalPeriodSizeInFrames;    /* Not using a fixed sized processing callback. Need to estimate the processing size based on the backend. */
+        }
+    } else {
+        if (pDevice->capture.intermediaryBufferCap > 0) {
+            return pDevice->capture.intermediaryBufferCap;
+        } else {
+            return pDevice->capture.internalPeriodSizeInFrames;
+        }
+    }
+}
+
 MA_API ma_result ma_device_set_master_volume(ma_device* pDevice, float volume)
 {
     if (pDevice == NULL) {
@@ -85478,21 +85520,6 @@ static void ma_engine_data_callback_internal(ma_device* pDevice, void* pFramesOu
 
     ma_engine_read_pcm_frames(pEngine, pFramesOut, frameCount, NULL);
 }
-
-static ma_uint32 ma_device__get_processing_size_in_frames(ma_device* pDevice)
-{
-    /*
-    The processing size is the period size. The device can have a fixed sized processing size, or
-    it can be decided by the backend in which case it can be variable.
-    */
-    if (pDevice->playback.intermediaryBufferCap > 0) {
-        /* Using a fixed sized processing callback. */
-        return pDevice->playback.intermediaryBufferCap;
-    } else {
-        /* Not using a fixed sized processing callback. Need to estimate the processing size based on the backend. */
-        return pDevice->playback.internalPeriodSizeInFrames;
-    }
-}
 #endif
 
 MA_API ma_result ma_engine_init(const ma_engine_config* pConfig, ma_engine* pEngine)
@@ -85595,7 +85622,7 @@ MA_API ma_result ma_engine_init(const ma_engine_config* pConfig, ma_engine* pEng
             possible that the node graph will split it's processing into multiple passes which can introduce
             glitching.
             */
-            engineConfig.periodSizeInFrames = ma_device__get_processing_size_in_frames(pEngine->pDevice);
+            engineConfig.periodSizeInFrames = ma_device_get_period_size_in_frames(pEngine->pDevice);
         }
     }
     #endif