Когда WASAPI GetNextPacketSize возвращает 0

Question

sample code of WASAPI capture on MSDN, петля до возвращения GetNextPacketSize 0. Я просто хочу понять, когда это произойдет:

1. Будет ли это произойдет, если там тишина зарегистрирована на микрофоне? (В этом случае он будет вращаться бесконечно, если я продолжаю шуметь на микрофоне?)
2. Это зависит от некоторой фундаментальной концепции захвата звука, которую я пропускаю (я совершенно новичок в аудио API :)).

Answer 1

API помогает определить размер буфера данных, который должен быть захвачен, чтобы API-клиент не нуждался в угадывании или распределении избыточного буфера и т. Д. API будет возвращать ноль, когда нет данных для захвата (не один кадр). Это может произойти в текущем сеансе аудиозахвата, когда/если вы вызываете API слишком рано, и вызывающий абонент, как ожидается, попробует еще раз позже, так как новые данные все равно могут быть сгенерированы.

В некоторых условиях нулевой возврат может указывать на конец потока. В частности, если вы снимаете с устройства loopback и нет активных сеансов воспроизведения, которые могут генерировать данные для доставки loopback, API захвата может продолжать предоставлять данные до тех пор, пока не появится новый сеанс воспроизведения.

Цикл кода примера проверяет нулевой размер пакета в сочетании с вызовом Sleep. Таким образом, цикл ожидает, что по меньшей мере некоторые данные будут генерироваться во время сна, а в обычных условиях непрерывной генерации аудиоданных нет нулевой длины, возвращаемой при каждом первом вызове во внешнем цикле. Внутренний цикл пытается считать как можно большее количество непустых буферов до тех пор, пока нуль не покажет, что все данные, которые были готовы к доставке, уже были возвращены клиенту.

Наружный цикл продолжает работать до тех пор, пока раковина не пройдет событие конца захвата через переменную bDone. Здесь есть уловка, что какая-то внутренняя петля может катиться, не врываясь во внешний цикл - в соответствии с образцом кода - и захват некорректно остановлен. Образец предполагает, что приемник обрабатывает данные достаточно быстро, так что внутренний цикл может обрабатывать все доступные в данный момент данные и выходить из него, чтобы достичь вызова Sleep. То есть, вызовы WASAPI не являются блокирующими и в предположении, что эти циклы работают довольно быстро, идея состоит в том, что аудиоданные обрабатываются быстрее, чем они захвачены, и цикл тратит большую часть времени потока на вызов Sleep. Возможно, это не лучший пример кода для начинающих. Вы можете улучшить это, проверив bDone во внутреннем цикле, чтобы сделать его более надежным.