Add ma_device_get_period_size_in_frames().

This commit is contained in:
David Reid
2026-02-22 06:31:48 +10:00
parent 7700880b56
commit 4c81dbd81f
+43 -16
View File
@@ -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