В статье таких деталей нет, но я не против поделиться. Преобразованные данные по частотам это массив комплексных чисел - характеристика сигнала, тут надо вспомнить Теорему Котельникова, чтобы правильно индекс с частотой сопоставить, по сути i-ый элемент массива это характеристика сигнала на определенной частоте. Потом логически группируем (вот неплохая справочная литература https://www.cuidevices.com/blog/understanding-audio-frequency-range-in-audio-design) и считаем среднее значение модулей на отрезке выбранных частот - сумма модулей комплексных чисел по взятым частотам поделить на кол-во. Для анимации в приложении подцепляем значение низких к фону, а средних к изгибам волны, анимируя изменения этих величин.
Хороший вопрос, сначала казалось, что пик детектор хорошее решение, но стоит включить трек полный басов и средних с перепадами, становится понятно почему именно через FFT. В целом нагрузка по большей части заключается в копировании и преобразование байтов PCM, FFT не так сильно загружает процессор. Но думаю в случае решения на "железе", разница между пик детектором по цене/сложности и FFT будет значительной, лично мне прототип кажется весьма интересным, удачи вам с ним.
Очень интересный вопрос, срез в 100 мс берется из-за того, что это оптимальное значение по памяти/процессора к визуальным эффектам. Когда есть статический размер, можно и величины "анимировать" предсказуемо, и backpressure учесть. И на самом деле даже динамический срез не так подходит, как плавающее окно, чтобы не пропускать частоты на стыке "срезов", но тут создается дополнительная нагрузка по памяти и на процессор. Все-таки, так как это делается на мобильном устройстве, ресурсы тут ограничены, особенно батарейкой пользователя. Алгоритм FFT по сложности хоть O(Nlog(N)), но нагрузку создает также ещё копирование и преобразование байтов из AudioProcessor'а.
Спасибо за статью, но как я читал на google.developers.com, там поля ViewModel рекомендуют оборачивать в LiveData или в MutableLiveData и потом подписываться на них в Acitvity/Fragments. Интересно, когда они в релиз выпустят всю эту красоту…
В статье таких деталей нет, но я не против поделиться. Преобразованные данные по частотам это массив комплексных чисел - характеристика сигнала, тут надо вспомнить Теорему Котельникова, чтобы правильно индекс с частотой сопоставить, по сути i-ый элемент массива это характеристика сигнала на определенной частоте. Потом логически группируем (вот неплохая справочная литература https://www.cuidevices.com/blog/understanding-audio-frequency-range-in-audio-design) и считаем среднее значение модулей на отрезке выбранных частот - сумма модулей комплексных чисел по взятым частотам поделить на кол-во. Для анимации в приложении подцепляем значение низких к фону, а средних к изгибам волны, анимируя изменения этих величин.
Хороший вопрос, сначала казалось, что пик детектор хорошее решение, но стоит включить трек полный басов и средних с перепадами, становится понятно почему именно через FFT. В целом нагрузка по большей части заключается в копировании и преобразование байтов PCM, FFT не так сильно загружает процессор. Но думаю в случае решения на "железе", разница между пик детектором по цене/сложности и FFT будет значительной, лично мне прототип кажется весьма интересным, удачи вам с ним.
Очень интересный вопрос, срез в 100 мс берется из-за того, что это оптимальное значение по памяти/процессора к визуальным эффектам. Когда есть статический размер, можно и величины "анимировать" предсказуемо, и backpressure учесть. И на самом деле даже динамический срез не так подходит, как плавающее окно, чтобы не пропускать частоты на стыке "срезов", но тут создается дополнительная нагрузка по памяти и на процессор. Все-таки, так как это делается на мобильном устройстве, ресурсы тут ограничены, особенно батарейкой пользователя. Алгоритм FFT по сложности хоть O(Nlog(N)), но нагрузку создает также ещё копирование и преобразование байтов из AudioProcessor'а.
В ближайших планах такого нет. Мы всегда ждём во фронте таких же героев, какие есть в андроиде :) https://yandex.ru/jobs/vacancies/фронтенд-разработчик-в-музыку-1466