Вы используете AudioRecord
правильно.Похоже, проблема в том, что на микрофоне какая-то AGC;как вы заметили, значения, считанные из буфера, постепенно увеличиваются в течение первых нескольких мс.Вероятно, это аппаратная AGC, возможно, добавленная производителем, чтобы предотвратить резкую «трещину» в начале каждой новой записи.
В качестве отступления: у меня есть старый RAZR с AGC, который настолько агрессивен,если вы щелкнете пальцами рядом с микрофоном, он замолчит на целую секунду, а затем медленно исчезнет.
Одним из решений этой проблемы является просто оставить запись AudioRecord
на длительный срок.основа.Затем, когда вы решите, что вам нужно захватить свои 500 кадров, они уже будут «подогреты», и значения должны быть в натуральную величину.
РЕДАКТИРОВАТЬ
Я только что провёл модульное тестирование, и кажется, что AudioRecord
не перезаписывает данные во внутреннем буфере, если вы пренебрегаете чтением достаточно быстро.Или, по крайней мере, не совсем понятно, что происходит с этими данными.Итак, необходимо более сложное решение.
В этом случае, похоже, вы должны будете убедиться, что буфер никогда не переполняется.Это означает, что вы звоните read()
достаточно быстро.В зависимости от вашей архитектуры, вам может быть проще выделить поток для этой цели.
Если вы просто используете буфер 500 кадров при каждом чтении, то когда придет время, вы можете просто получить копиюэтого буфера, который будет достаточно близок к «самой последней возможной» поточной передаче данных с микрофона.Это предполагает, что вы читали достаточно быстро, так что ваше следующее чтение заблокировалось бы.
Я говорю «достаточно близко», потому что аудиоданные помещаются в буфер кусками размером getMinBufferSize()/2
, если я правильно помню, иэто также предел разрешения OnRecordPositionUpdateListener
.Итак, вы будете где-то близко к концу, но трудно точно сказать, насколько близко.