Java для обработки звука это практично?

Ответ 1

Для аудиоприложения у вас часто есть только очень маленькие части кода, где большая часть времени тратится.

В Java вы всегда можете использовать JNI (Java Native interface) и переместить свой вычислительный тяжелый код в C-модуль (или сборку с использованием SSE, если вам действительно нужна мощность). Поэтому я бы сказал, что использую Java и работаю с вашим кодом. Если окажется, что вы не отвечаете своей цели эффективности, используйте JNI.

90% кода, скорее всего, будет являться кодовым кодом и материалом приложения. Но имейте в виду, что вы потеряете некоторые из функций кросс-платформенной. Если вы можете жить с этим JNI, вы всегда оставите дверь открытой для производительности собственного кода.

Ответ 2

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

Ответ 3

Конечно, почему бы и нет?

Критические вопросы (независимо от языка, это теория очередей):

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

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

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

РПИ стоят дороже, что, вероятно, станет узким местом (и то, что вы хотите оптимизировать), если у вас нет какой-либо другой уродливой неприятной операции.

Ответ 4

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

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

Ответ 5

Да, Java отлично подходит для аудио приложений. Вы можете использовать Java и получать доступ к звуковым слоям через Asio и иметь очень низкую задержку (задержка на выборки 64 пикселей, которая почти ничего не стоит) на платформе Windows. Это означает, что у вас будет синхронизация губ на видео/видео. Больше латентности на Mac, так как нет Asio для "быстрого доступа" к комбинации OS X и "Java сверху", но все равно ОК. Linux тоже, но я более неосведомлен. См. Soundpimp.com для практического (и первого в мире) примера Java и Asio, работающих в идеальной гармонии. Также см. Приложение NRK Radio & tv Android, содержащее sw mp3-декодер (от Java). Вы можете делать большинство аудиоматериалов с помощью Java, а затем использовать собственный слой, если это необходимо для дополнительного времени.

Ответ 6

Посмотрите библиотеку под названием Jsyn.

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

От http://www.jsresources.org/faq_performance.html#java_slow

Позвольте собрать некоторую духовную мудрость:

• Земля плоская.

• и не забывать: Java медленная.

Как доказывает несколько приложений (см. раздел ссылок), Java достаточно для создания аудиоредакторов, многодорожечных систем записи и MIDI программное обеспечение для обработки. Попробуйте!