Java для Обработки аудиоданных - это Практичный?

Несомненно, почему нет?

ключевые вопросы (независимый от языка, это от теории массового обслуживания):

• , какова максимальная пропускная способность, которую необходимо обработать (Вы указали 100 x 48 кГц, который моно или стерео, сколько битов, эквивалентных на той частоте?)
• Ваши стандартные программы Java могут не отставать от этого уровня в среднем?
• , какова максимальная допустимая задержка?

, Если Ваша программа может не отставать от пропускной способности в среднем, и у Вас есть достаточно комнаты для задержки, затем необходимо смочь использовать очереди для вводов и выводов, и единственные части программы, которые очень важны для синхронизации, являются частями, которые помещают данные во входную очередь и вынимают ее из очереди вывода и отправляют ее в DAC/speaker/whatever.

строки Задержки имеют низкую вычислительную загрузку, Вам просто нужно достаточно памяти (+ пропускная способность памяти)... на самом деле необходимо, вероятно, просто использовать очереди ввода/вывода для нее, т.е. начать помещать данные во входную очередь сразу и начать вынимать данные из несколько 30-е очереди вывода спустя. Если это не там, Ваша программа является слишком медленной...).

ЕЛИ являются более дорогими, это, вероятно, будет узким местом (& что Вы хотели бы оптимизировать), если Вы не имеете некоторую другую ужасную противную операцию в виду.

Я думаю, что задержка будет вашей основной проблемой - довольно сложно поддерживать задержку уже в C / C ++ на современных ОС, и java, безусловно, усугубляет проблему (сборщик мусора). Общая схема обработки звука «в реальном времени» состоит в том, чтобы ваши потоки обработки выполнялись в режиме реального времени по расписанию (SCHED_FIFO в ядрах Linux, эквивалент в других ОС), и эти потоки никогда не должны блокироваться. Это означает отсутствие системных вызовов, malloc, конечно же, ввода-вывода и т. Д. Даже разбиение на страницы является проблемой (перенос страницы с диска в память может легко занять несколько мс), поэтому вам следует заблокировать некоторые страницы, чтобы убедиться, что они никогда не будут выгружены.

Возможно, вы сможете делать это на Java, но java делает его более сложным, а не простым. Я бы рассмотрел смешанный дизайн, где ядро ​​было бы на C, а остальное (графический интерфейс и т. Д.) Было бы на java, если хотите.

В вашем вопросе я не заметил одной вещи: нужно ли вам воспроизводить эти обработанные сэмплы или вы делаете с ними что-то еще (например, кодируете их в файл) . Я бы больше беспокоился о состоянии звукового движка Java, чем о том, насколько быстро JVM может обрабатывать образцы.

Я довольно сильно надавил на javax.sound.sampled несколько лет назад и остался совершенно не впечатленным - это не так ». t сравнивать с эквивалентными фреймворками, такими как OpenAL или Core Audio для Mac / iPhone (оба из которых я использовал с одинаковым уровнем интенсивности). javax.sound.sampled требует, чтобы вы поместили ваши сэмплы в непрозрачный буфер неизвестной продолжительности, что делает синхронизацию практически невозможной. Это' s также плохо документирован (очень трудно найти примеры потоковой передачи аудио неопределенной длины по строке в отличие от тривиальных примеров клипов в памяти), имеет нереализованные методы (DataLine.getLevel () ... чья нереализация не является ' t даже задокументирован), и в довершение всего, я считаю, что Sun уволила последнего инженера JavaSound много лет назад.

Если бы у меня было , чтобы использовать движок Java для микширования и вывода звука, я бы, вероятно, попробуйте использовать привязки JOAL к OpenAL в качестве первого выбора, так как я, по крайней мере, знал, что движок в настоящее время поддерживается и способен работать с очень малой задержкой. Хотя я подозреваю, что в конечном итоге Нильс прав, и вы в конечном итоге будете использовать JNI для вызова собственного звукового API.

t даже задокументирован), и в довершение всего, я считаю, что Sun уволила последнего инженера JavaSound много лет назад.

Если бы у меня было , чтобы использовать движок Java для микширования и вывода звука, я бы, вероятно, попробуйте использовать привязки JOAL к OpenAL в качестве первого выбора, так как я, по крайней мере, знал, что движок в настоящее время поддерживается и способен работать с очень малой задержкой. Хотя я подозреваю, что в конечном итоге Нильс прав, и вы в конечном итоге будете использовать JNI для вызова собственного звукового API.

t даже задокументирован), и в довершение всего, я считаю, что Sun уволила последнего инженера JavaSound много лет назад.

Если бы у меня было , чтобы использовать движок Java для микширования и вывода звука, я бы, вероятно, попробуйте использовать привязки JOAL к OpenAL в качестве первого выбора, так как я, по крайней мере, знал, что движок в настоящее время поддерживается и способен работать с очень малой задержкой. Хотя я подозреваю, что в конечном итоге Нильс прав, и вы в конечном итоге будете использовать JNI для вызова собственного звукового API.

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

Ознакомьтесь с библиотекой под названием Jsyn .

http://www.softsynth.com/jsyn/

Java прекрасно подходит для многих аудио приложений. В отличие от некоторых других авторов, я считаю, что работать с аудио на Java - одно удовольствие. Сравните API и ресурсы, доступные вам, с ужасным, едва документированным mindf*k, которым является CoreAudio, и вы поверите. Java-аудио страдает от некоторых проблем с задержкой, хотя для многих приложений это не имеет значения, и от недостатка кодеков. Есть также множество людей, которые никогда не тратили время на написание хороших механизмов воспроизведения аудио (подсказка, никогда не закрывайте SourceDataLine, вместо этого записывайте в нее нули), и впоследствии винят Java в своих проблемах. С точки зрения API, Java audio очень прост, очень прост в использовании, и на jsresources.org есть много и много руководств.