能否修改IMFSourceReader的OnReadSample块大小？Windows低延迟录音咨询

问题背景 #

在Windows平台使用Flutter的record包录音，采用IMFSourceReader实现，当前配置为16bit PCM、48000Hz单声道，但OnReadSample回调的数据块固定为50ms时长，调整采样率后时长仍不变，希望将数据块缩短至10ms或提高回调频率，同时询问其他低延迟Windows录音API。

针对IMFSourceReader的优化方案 #

1. 启用低延迟模式并调整缓冲区队列 #

IMFSourceReader默认会用较大缓冲区保证稳定性，可通过设置属性强制启用低延迟：

// 启用低延迟模式
hr = m_pReader->SetProperty(MF_SOURCE_READER_ENABLE_LOW_LATENCY, TRUE);
if (FAILED(hr)) {
    // 处理错误逻辑
}

// 将缓冲区队列长度设为1，减少队列积压
hr = m_pReader->SetProperty(MF_SOURCE_READER_BUFFER_QUEUE_LENGTH, (UINT32)1);
if (FAILED(hr)) {
    // 处理错误逻辑
}

2. 验证媒体类型参数的实际生效情况 #

你已设置MF_MT_AUDIO_SAMPLES_PER_BLOCK为480（对应48000Hz下的10ms），但需确认设备是否支持该参数。可在设置媒体类型后，读取实际生效的类型参数：

IMFMediaType* pActualType = nullptr;
hr = m_pReader->GetCurrentMediaType(MF_SOURCE_READER_FIRST_AUDIO_STREAM, &pActualType);
if (SUCCEEDED(hr)) {
    UINT32 actualSamplesPerBlock = 0;
    hr = pActualType->GetUINT32(MF_MT_AUDIO_SAMPLES_PER_BLOCK, &actualSamplesPerBlock);
    // 检查actualSamplesPerBlock是否为480，若不是则说明设备不支持该值
    SafeRelease(&pActualType);
}

如果设备不支持480采样/块，需调整为设备支持的最小有效值，或切换到更灵活的API。

3. 确保媒体类型参数一致 #

确认MF_MT_AVG_BITRATE设置正确：48000Hz * 16bit * 1声道 = 768000bps，若配置的m_pConfig->bitRate不符，可能导致IMFSourceReader自动调整缓冲区。

低延迟替代API推荐 #

1. WASAPI（Windows Audio Session API） #

这是Windows原生低延迟音频的首选方案，支持独占模式，可直接控制缓冲区大小，轻松实现10ms甚至更低的延迟。核心步骤：

1. 使用IMMDeviceEnumerator获取音频捕获设备；
2. 通过IAudioClient::Initialize指定独占模式和10ms缓冲区时长；
3. 用IAudioCaptureClient循环读取音频数据并发送到Flutter。

关键代码片段：

// 初始化IAudioClient（示例）
hr = pAudioClient->Initialize(
    AUDCLNT_SHAREMODE_EXCLUSIVE,  // 独占模式，优先低延迟
    0,                            // 捕获麦克风用0，loopback捕获系统音频用AUDCLNT_STREAMFLAGS_LOOPBACK
    10000000,                     // 缓冲区时长：10ms = 10*10^6纳秒
    0,                            // 设备周期，0表示使用请求时长
    pFormat,                      // 16bit PCM 48000Hz单声道格式
    NULL                          // 默认音频会话
);

2. WaveIn API #

较传统的音频捕获API，对缓冲区大小的控制也比较直接，但延迟表现不如WASAPI，适合对延迟要求稍低的场景。

总结 #

1. 优先尝试给IMFSourceReader添加低延迟属性，验证媒体参数的实际生效情况；
2. 若IMFSourceReader无法满足需求，直接切换到WASAPI实现，它能提供更精准的低延迟控制。

内容的提问来源于stack exchange，提问作者Reew1nd