Как получить наиболее точные данные о частоте звука, которые можно получить в режиме реального времени в режиме реального времени на Android?

Question

Итак, я пытаюсь создать приложение для Android, которое действует как аудиоанализ в реальном времени как предшественник проекта, который будет включать в себя обнаружение и фильтрацию определенных звуков.

Итак, я думаю, что у меня есть основы дискретных преобразований Фурье, однако я не уверен, какие лучшие параметры должны быть для анализа частоты в реальном времени.

У меня создалось впечатление, что в идеальных ситуациях (неограниченная вычислительная мощность) я бы взял все образцы из потока/100 PCM-потока 44100, который я получаю из класса AudioRecord, и поместил их через окно с окном 44100 элементов fifo "(добавлено до 2 ** 16 с 0 и, возможно, суживающей функцией?), запуская БПФ в окне каждый раз, когда вводится новый образец. Это будет (я думаю), дайте мне спектр для 0 - ~ 22 кГц, обновленный 44100 раз в секунду.

Кажется, что это не произойдет на смартфоне. Дело в том, что я не уверен, какие параметры вычислений я должен уменьшить, чтобы сделать его доступным для моего Galaxy Nexus, сохраняя при этом как можно больше качества. В конце концов я хотел бы использовать внешний микрофон с лучшей чувствительностью.

Я полагаю, что это приведет к перемещению окна более одного образца между выполнением БПФ, но я понятия не имею, в какой момент это становится более пагубным для точности/алиасинга/независимо от того, как делать БПФ на меньшем окне, или если есть третий вариант, который я пропускаю.

С изначально реализованным KissFFT, который я использую из libgdx, я, похоже, могу делать где-то между 30-42 44100 элементами FFT на 44100 выборок и все еще иметь его отзывчивый (что означает, что буфер заполняется из потока выполнение AudioRecord.read() не заполняется быстрее, чем поток, выполняющий fft, может его слить).

Так что мои вопросы:

1. Может производительность настоящее время я получаю просто лучшее, что я буду получать? Или похоже, что я должен быть чем-то глупым, потому что возможны гораздо более быстрые скорости?
2. Является ли мой подход к этому, по крайней мере, принципиально правильным, или я лаем полностью на неправильное дерево?

Я был бы рад показать любой из моих кодов, если бы это помогло ответить на мои вопросы, но их много, поэтому я решил, что сделаю это выборочно, а не публикую все.

Answer 1

если есть третий вариант, я с видом

Да: делать и в то же время, уменьшение размера FFT, а также больший размер шага. В комментарии вы указали, что хотите обнаружить «фырканье/жевание с ртом». Итак, то, что вы хотите сделать, похоже на типичную задачу распознавания речи. Там вы обычно извлекаете вектор-функцию с шагом 10 мс (что означает Fs = 44,1 кГц каждые 441 образец), а окно сигнала для преобразования примерно удваивает размер шага, поэтому 20 мс, что дает 2 х X БПФ размер 1024 выборок (убедитесь, что вы выбрали размер FFT, который равен 2, потому что он быстрее).

Любое увеличение размера окна или уменьшение размера шага увеличивает данные, но в основном добавляет избыточность.

Дополнительные советы:

• @SztupY правильно указал, что вам нужно «окно» ваш сигнал до FFT, как правило, с Хэмминга-wondow. (Но это не «фильтрация», а просто умножение каждого значения выборки на соответствующее значение окна без накопления результата).

• Необработанный выход FFT вряд ли подходит для распознавания «всхлипывания/жевания с ртом», классический распознаватель состоит из HMM или ANN, которые обрабатывают последовательности MFCC и их дельт.

Может производительность настоящее время я получаю просто лучшее, что я буду получать? Или похоже, что я должен быть чем-то глупым, потому что возможны гораздо более быстрые скорости?

Это близко к лучшему, но вы тратите впустую всю мощность процессора, чтобы оценить избыточные данные, не оставляя при этом мощность процессора для распознавателя.

Является ли мой подход к этому, по крайней мере, принципиально правильным, или я лаем полностью на неправильное дерево?

После рассмотрения моего ответа вы можете пересмотреть свой подход.