Java для обработки звука: практично ли это?
https://stackoverflow.com/questions/407624
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Является ли Java подходящей альтернативой C/C++ для обработки звука в реальном времени?
Я рассматриваю приложение с примерно 100 (максимум) дорожками звука с линиями задержки (30 с @ 48 кГц), фильтрацией (512-точечная FIR?) и другими операциями типа DSP, происходящими на каждой дорожке одновременно.
Операции будут преобразованы и выполнены с плавающей запятой.
Система, вероятно, будет четырехъядерной с тактовой частотой 3 ГГц и 4 ГБ оперативной памяти под управлением Ubuntu.
Я видел статьи о том, что Java стала намного быстрее, чем раньше, приблизилась к C/C++ и теперь также имеет расширения реального времени.Это реальность?Требуется ли жесткое программирование и настройка для достижения производительности C на уровне 50–100%, о которой некоторые говорят?
Я действительно ищу понимание, возможно ли это, и предупреждение о любых ошибках.
Решение
В аудиоприложении часто имеются лишь очень небольшие части кода, на которые тратится большая часть времени.
В Java вы всегда можете использовать JNI (Java Native интерфейс) и переместить свой тяжелый вычислительный код в C-модуль (или сборку с использованием SSE, если вам действительно нужны мощности).Поэтому я бы посоветовал использовать Java и заставить ваш код работать.Если окажется, что вы не достигли своей цели по производительности, используйте JNI.
В любом случае 90% кода, скорее всего, будет представлять собой связующий код и приложения.Но имейте в виду, что таким образом вы потеряете некоторые кроссплатформенные функции.Если вы сможете жить с этим, JNI всегда оставит вам возможность повысить производительность собственного кода.
Другие советы
Java подходит для многих аудиоприложений.В отличие от некоторых других авторов, мне доставляет удовольствие работать со звуком Java.Сравните API и ресурсы, доступные вам, с ужасающим, едва документированным ублюдком CoreAudio, и вы поверите.Звук Java страдает от некоторых проблем с задержкой, хотя для многих приложений это не имеет значения, а также из-за отсутствия кодеков.Есть также множество людей, которые никогда не утруждали себя написанием хороших механизмов воспроизведения звука (подсказка: никогда не закрывайте SourceDataLine, вместо этого записывайте в нее нули) и впоследствии обвиняют Java в своих проблемах.С точки зрения API, Java-аудио очень прост и удобен в использовании, а на сайте имеется множество руководств. jsresources.org.
Конечно, почему бы и нет?
Ключевые вопросы (независимо от языка, это из теории массового обслуживания):
- какова максимальная пропускная способность, с которой вам нужно справиться (вы указали 100 x 48 кГц, это моно или стерео, сколько бит эквивалентно на этой частоте?)
- могут ли ваши Java-программы в среднем соответствовать этому показателю?
- какова максимально допустимая задержка?
Если ваша программа может поддерживать среднюю пропускную способность и у вас достаточно места для задержки, тогда вы сможете использовать очереди для ввода и вывода, и единственными частями программы, которые имеют решающее значение для синхронизации, являются части, которые поместите данные во входную очередь, извлеките их из выходной очереди и отправьте на ЦАП/динамик/что угодно.
Линии задержки имеют низкую вычислительную нагрузку, нужно лишь достаточно памяти (+ ПСП)...на самом деле вам, вероятно, следует просто использовать для этого очереди ввода/вывода, т.е.начните помещать данные во входную очередь немедленно и начните извлекать данные из выходной очереди через 30 секунд.Если его там нет, ваша программа работает слишком медленно...).
FIR более дорогие, и это, вероятно, будет узким местом (и тем, что вы захотите оптимизировать), если только вы не задумали какую-то другую уродливую и неприятную операцию.
Я думаю, что задержка будет вашей главной проблемой - поддерживать задержку уже в C/C++ в современных ОС довольно сложно, и Java, безусловно, усугубляет проблему (сборщик мусора).Общий дизайн обработки звука в «реальном времени» заключается в том, чтобы ваши потоки обработки работали по расписанию в реальном времени (SCHED_FIFO в ядрах Linux, эквивалентно в других ОС), и эти потоки никогда не должны блокироваться.Это означает, что никаких системных вызовов, никакого malloc, никакого ввода-вывода, конечно, и т. д.Даже подкачка страниц является проблемой (перенос страницы с диска в память может легко занять несколько мс), поэтому вам следует заблокировать некоторые страницы, чтобы быть уверенными, что они никогда не будут выгружены.
Возможно, вы сможете сделать эти вещи на Java, но Java усложняет, а не упрощает.Я бы рассмотрел смешанный дизайн, где ядро будет на C, а остальное (графический интерфейс и т. д.) будет на Java, если хотите.
В вашем вопросе я не увидел одного: нужно ли вам воспроизводить эти обработанные семплы или вы делаете с ними что-то еще (например, кодируете их в файл).Меня больше беспокоит состояние звукового движка Java, чем то, насколько быстро JVM может обрабатывать сэмплы.
Я довольно усердно работал над javax.sound.sampled несколько лет назад и остался совершенно не впечатлен — он не идет ни в какое сравнение с эквивалентными фреймворками, такими как OpenAL или Core Audio для Mac/iPhone (обе из которых я использовал на одинаковом уровне интенсивность).javax.sound.sampled требует, чтобы вы помещали сэмплы в непрозрачный буфер неизвестной продолжительности, что делает синхронизацию практически невозможной.Он также плохо документирован (очень трудно найти примеры потоковой передачи звука неопределенной длины через строку в отличие от тривиальных примеров клипов в памяти), имеет нереализованные методы (DataLine.getLevel()...нереализация которого даже не задокументирована), и в довершение всего, я считаю, что Sun уволила последнего инженера JavaSound много лет назад.
Если я имел Чтобы использовать движок Java для микширования и вывода звука, я бы, вероятно, попробовал использовать привязки JOAL к OpenAL в качестве первого выбора, поскольку я, по крайней мере, знал, что этот движок в настоящее время поддерживается и способен работать с очень малой задержкой.Хотя я подозреваю, что в конечном итоге Нильс прав, и в конечном итоге вы будете использовать JNI для вызова собственного звукового API.
Да, Java отлично подходит для аудиоприложений.Вы можете использовать Java и получать доступ к аудиослоям через Asio и иметь действительно низкую задержку (задержка 64 семпла, что практически ничего) на платформе Windows.Это означает, что у вас будет синхронизация губ на видео/фильме.На Mac задержка больше, так как нет Asio, который мог бы «сократить» комбинацию OS X и «Java поверх», но все равно нормально.Linux тоже, но я более невежественен.Посетите сайт soundpimp.com, чтобы увидеть практический (и первый в мире) пример идеальной гармонии Java и Asio.Также см. приложение NRK Radio&tv для Android, содержащее декодер sw mp3 (из Java).Вы можете выполнять большинство операций со звуком с помощью Java, а затем использовать собственный слой, если требуется дополнительное время.
Проверьте библиотеку под названием Jsyn.
Почему бы не потратить день и написать простое Java-приложение, которое выполняет минимальную обработку и проверяет достаточную производительность.
От http://www.jsresources.org/faq_ Performance.html#java_slow
Давайте соберем немного неземной мудрости:
Земля плоская.
и, чтобы не забыть:Ява медленная.
Как доказывают несколько приложений (см. Раздел ссылок), Java достаточно для создания аудио редакторов, систем записи с мультитрак и программного обеспечения для обработки MIDI.Попробуйте!
