Как мы превратили промышленный контроллер в студийный синтезатор

Как мы превратили промышленный контроллер в студийный синтезатор

В «АйТи Фреш» мы регулярно занимаемся настройкой серверов и поддерживаем офисные сети, это наша рутина. Но иногда к нам приходят с такими проектами, что приходится выходить далеко за рамки привычных задач. Именно так вышло с нашим клиентом «Аудиокрафт» — это небольшая студия саунд-дизайна из Москвы, которой понадобился… натуральный рояль в коробке.

Клиент и задача: музыка для интерактивной инсталляции

«Аудиокрафт» — наши давние и хорошие клиенты. Мы обслуживаем их скромный офис, где трудятся 15 человек, создавая уникальные звуки для рекламы, мобильных игр и разных выставок. И вот однажды руководитель студии, Алексей, позвонил мне с совершенно невероятной просьбой. Оказалось, они готовят интерактивную звуковую инсталляцию для галереи современного искусства: задумка была такая — посетители взаимодействуют с датчиками, а система в реальном времени генерирует сложную фортепианную музыку, отталкиваясь от их действий.

Сердцем всей этой инсталляции должен был стать профессиональный программный синтезатор Pianoteq. В отличие от сэмплерных библиотек, которые просто проигрывают уже записанные звуки рояля, Pianoteq делает нечто особенное: он вычисляет звук «на лету», используя сложную физическую модель. Это дарит инструменту невероятную живость и отзывчивость, но, разумеется, требует серьезных вычислительных ресурсов. И что самое важное — нужна минимальная задержка между сигналом от датчика (который приходит как MIDI-сообщение) и моментом, когда появляется звук. Для того чтобы слушатель чувствовал себя комфортно, эта задержка не должна превышать 10-12 миллисекунд.

Сначала прототип собрали на довольно мощном ноутбуке, но для постоянной инсталляции, которая должна работать в режиме 24/7, такое решение, понятное дело, не подходило. Алексею был нужен этакий «черный ящик»: компактное, абсолютно надежное и при этом необслуживаемое устройство. Его можно было бы просто спрятать в нишу в стене, подключить к нему питание, MIDI-вход от датчиков и аудиовыход на колонки — и забыть о нем на долгие месяцы. Итак, задача была предельно ясна: нам предстояло создать именно такой «рояль в коробке».

Почему не подошел обычный компьютер?

Знаете, какая первая мысль приходит в голову в такой ситуации? Конечно, взять какой-нибудь компактный ПК, например Intel NUC, или собрать систему на базе Mini-ITX. Мы с клиентом всерьез рассмотрели этот вариант, но довольно быстро от него отказались. Причин было несколько:

  • Габариты и тепловыделение. Даже самый маленький системный блок — это все равно ящик с вентиляторами, которому нужно охлаждение. В условиях закрытой ниши это могло стать проблемой.
  • Надежность операционной системы. Стабильность десктопных Windows или macOS в режиме 24/7 без присмотра вызывает вопросы. Внезапные обновления, всплывающие окна, сбои драйверов — все это могло «подвесить» инсталляцию в самый неподходящий момент. Нужен был предсказуемый и управляемый софт.
  • Стоимость. Собирать кастомный бесшумный ПК в компактном корпусе — это не самое бюджетное решение.
  • Отсутствие экспертизы у клиента. «Аудиокрафт» — гении звука, но не системные администраторы. Им нужно было решение, которое не требует от них знаний Linux, скриптов или удаленного администрирования. Просто кнопка «Вкл».

Очень быстро стало понятно: нужен совершенно другой подход. И тогда мы предложили клиенту решение, которое было взято из мира промышленной автоматизации. На первый взгляд оно казалось довольно экзотичным, но идеально подходило под все наши требования.

Почему не подошел обычный компьютер?

Наша ставка: промышленный контроллер на Linux

Вместо привычного десктопного железа мы решили использовать промышленный логический контроллер, или ПЛК. Эти устройства специально созданы для работы в действительно суровых условиях: вы можете встретить их на заводах, в котельных или в системах «умного дома». Они рассчитаны на круглосуточную работу годами, у них нет ни вентиляторов, ни движущихся частей, а монтируются они на стандартную DIN-рейку в обычном электрощите.

Наш выбор пал на отечественный контроллер Wiren Board 8. По производительности его 4-ядерный ARM-процессор Allwinner T507 и 4 ГБ ОЗУ вполне сопоставимы с Raspberry Pi 3 B+, но вот по исполнению, поверьте, это устройство совсем другого класса:

  • Прочный промышленный корпус.
  • Надежное хранилище eMMC на 64 ГБ.
  • Широкий диапазон питающих напряжений.
  • Гарантированная работа в режиме 24/7.

На борту у контроллера стоит стандартный Debian 11 Bullseye. Это давало нам потрясающую гибкость и доступ к огромному репозиторию пакетов. План выглядел, конечно, дерзко, но при этом был вполне логичен: заставить десктопную программу для создания музыки работать в серверном окружении на ARM-процессоре промышленного контроллера.

Первый запуск: «А где здесь монитор?»

Мы скачали с сайта производителя ARM64-версию Pianoteq и аккуратно распаковали ее на контроллер. Первая же попытка запуска в консоли, как и ожидалось, предсказуемо провалилась. Программа просто «падала» с ошибкой `segmentation fault`.

Проблема заключалась в том, что Pianoteq — это, по сути, приложение с графическим интерфейсом, написанное с использованием фреймворка JUCE. Даже когда мы пытались запустить его в режиме `--headless` (то есть без GUI), бинарный файл при старте все равно пытался подгрузить в память графические библиотеки, к которым он был прилинкован еще на этапе сборки — это X11, OpenGL и другие. А в серверной сборке Debian на Wiren Board их, конечно же, просто не было.

Тогда мы начали методичный процесс: выявляли и устанавливали зависимости. После нескольких итераций, шаг за шагом, мы наконец собрали наш «джентльменский набор», который был абсолютно необходим для запуска приложения:

sudo apt update
sudo apt install -y \
 libgl1 libx11-6 libxext6 libxrender1 libxcursor1 libxrandr2 \
 libxinerama1 libxi6 libfreetype6 libfontconfig1 \
 libxcb-keysyms1 libxcb-icccm4 libxcb-randr0 libxcb-render-util0 \
 libxcb-image0 libxcb-shape0 libxcb-xkb1 libxcb-xinerama0 \
 libxkbcommon-x11-0 xauth alsa-utils

Команда ldd /path/to/binary — отличный помощник в таких ситуациях. Она показывает все динамические библиотеки, которые требуются исполняемому файлу, и отмечает те, которые не найдены в системе.

После того как мы установили весь этот набор пакетов, Pianoteq наконец-то запустился в консоли и не упал! Это была наша первая, хоть и маленькая, победа. Но до появления звука было еще очень и очень далеко.

Битва за звук: усмиряем ALSA и MIDI

Следующим этапом было заставить систему «увидеть» внешние устройства: нам нужен был USB-ЦАП (это цифро-аналоговый преобразователь) для вывода звука и USB-MIDI-интерфейс для получения команд от датчиков. Мы подключили их к контроллеру.

Проверяем аудиокарту с помощью утилит из пакета alsa-utils:

aplay -l

**** List of PLAYBACK Hardware Devices ****
card 0: wb8hdmi [wb8-hdmi], device 0: 1f00140.hdmi-codec-0 hdmi-0 [1f00140.hdmi-codec-0 hdmi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: KA13 [FiiO KA13], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Отлично, система видит и встроенный HDMI-аудио, и наш USB-ЦАП FiiO KA13. Теперь проверяем MIDI-интерфейс:

amidi -l

Dir Device    Name
IO  hw:2,0,0  UM-1 MIDI 1

MIDI-адаптер Roland UM-1 тоже на месте. Мы запустили Pianoteq, указав ему нужные устройства. Тишина. Программа работала, но на MIDI-сообщения не реагировала.

Проблема оказалась в правах доступа. По умолчанию в Debian устройства из подсистемы ALSA (`/dev/snd/*`) доступны для записи только пользователю `root`. Наш сервис же мы планировали запускать от имени отдельного непривилегированного пользователя `pianoteq`. Решение — создать простое правило для `udev`, системного менеджера устройств Linux. Мы создали файл /etc/udev/rules.d/99-midi-permissions.rules со следующим содержимым:

SUBSYSTEM=="snd", GROUP="audio", MODE="0660"

Это правило предписывает системе при обнаружении любого нового звукового устройства (SUBSYSTEM=="snd") назначать ему группу `audio` и выставлять права на чтение/запись для владельца и группы. Осталось только добавить нашего пользователя в нужную группу:

sudo usermod -aG audio pianoteq

После перезагрузки контроллера и повторного запуска все заработало! Мы послали тестовую ноту с MIDI-клавиатуры и услышали чистый, богатый звук рояля из колонок, подключенных к маленькой коробочке на DIN-рейке. Это был ключевой прорыв.

Битва за звук: усмиряем ALSA и MIDI

Оптимизация: выжимаем максимум из ARM-процессора

Наша радость, к сожалению, длилась недолго. Стоило начать играть несколько нот одновременно, как звук тут же начал «захлебываться», появились неприятные щелчки и треск. Это так называемые xruns (buffer underruns) — ситуация, когда процессор просто не успевает вовремя рассчитать очередной фрагмент звука, и звуковой буфер, как следствие, опустошается. Стало ясно: ARM-процессор контроллера работал на пределе своих возможностей.

Тут начался, пожалуй, самый тонкий и кропотливый этап — оптимизация производительности. Для того чтобы выполнить первоначальную настройку, мы подключились к контроллеру по SSH, используя проброс графики (`ssh -X`), и запустили Pianoteq в графическом режиме. Это дало нам доступ ко всем его настройкам.

Шаг 1: Настройки в Pianoteq

Мы последовательно внесли несколько изменений в самом синтезаторе:

  • Частота дискретизации. Снизили с 48000 Гц до 44100 Гц. Для человеческого слуха разница почти незаметна, а нагрузка на процессор падает почти на 15%.
  • Размер аудио-буфера. Увеличили его с 128 до 256 сэмплов. Это добавило пару миллисекунд к задержке, но дало процессору больше времени на обработку данных, что резко сократило количество щелчков.
  • Полифония. Ограничили максимальное количество одновременно звучащих нот до 64. Для задачи клиента этого было более чем достаточно.

Шаг 2: Настройки на уровне ОС

Даже после всех этих манипуляций мы замечали, что при пиковых нагрузках все 4 ядра процессора были загружены на 100%. Тогда мы решили пойти еще дальше и полностью изолировать системные процессы от аудиопотока. С помощью утилиты `taskset` можно «привязать» процесс к определенным ядрам CPU. Мы решили отдать три ядра из четырех целиком под нужды Pianoteq, а одно оставить для операционной системы и всех ее фоновых задач. В итоге команда запуска стала выглядеть вот так:

taskset -c 1,2,3 /mnt/data/pianoteq/Pianoteq --headless --multicore max

Эта мера оказалась решающей. Нагрузка на выделенные ядра стала более равномерной, а главное — исчезли последние xruns. Мы получили стабильный, чистый звук без артефактов даже при сложной игре.

Автоматизация и сдача: решение «под ключ»

Оставался последний, но очень важный штрих: превратить нашу тщательно настроенную систему в тот самый «черный ящик», о котором так просил клиент. Устройство должно было автоматически запускать синтезатор сразу при подаче питания и, что очень важно, самостоятельно перезапускать его в случае какого-либо сбоя.

Для решения этой задачи идеально подошел системный менеджер `systemd`, который, к слову, используется в большинстве современных дистрибутивов Linux. Мы написали для него простой сервис-файл.

Создаем файл /etc/systemd/system/pianoteq.service:

[Unit]
Description=Pianoteq Headless Service
After=sound.target

[Service]
User=pianoteq
Group=audio
ExecStart=/usr/bin/taskset -c 1,2,3 /mnt/data/pianoteq/Pianoteq 8 STAGE --headless --midi /dev/snd/midiC2D0 --audio-device "ASIO::FiiO KA13" --multicore max
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

В этом файле мы описали все, что нужно системе для управления нашим приложением:

  • [Unit]: Описание сервиса и указание, что его нужно запускать после инициализации звуковой подсистемы.
  • [Service]: Указание пользователя, от имени которого запускается процесс, сама команда запуска со всеми нашими ключами оптимизации, а также директива `Restart=always`, которая заставит systemd перезапустить сервис в случае его падения.
  • [Install]: Указание, что сервис должен стартовать вместе с системой.

Активируем и запускаем сервис командами:

sudo systemctl daemon-reload
sudo systemctl enable pianoteq.service
sudo systemctl start pianoteq.service

Теперь все было готово. Мы протестировали систему несколько раз, просто выключая и включая питание контроллера. Каждый раз через 15-20 секунд после старта система была полностью готова к работе и начинала отзываться на MIDI-команды. Задача была выполнена.

Результаты и выводы

В итоге мы передали клиенту полностью готовое устройство: это был контроллер Wiren Board 8, аккуратно смонтированный в небольшом пластиковом корпусе, с блоком питания, USB-ЦАП и MIDI-интерфейсом. Всё, что им оставалось сделать — это подключить всего три кабеля.

Итоги проекта в измеримых показателях:

  • Задержка (latency): Общая задержка от MIDI-события до звука составила около 8 мс, что является отличным показателем для комфортной игры и полностью устроило клиента.
  • Производительность: При типичной для инсталляции нагрузке средняя загрузка выделенных ядер CPU не превышала 75-80%, что оставляло запас прочности. Количество xruns — ноль.
  • Энергопотребление: Вся система потребляла менее 10 Вт, что несопоставимо с любым десктопным ПК.
  • Надежность: На момент написания этого кейса инсталляция в галерее работает уже более полугода в режиме 24/7 без единого сбоя или перезагрузки.

Этот проект стал для нашей команды в «АйТи Фреш» прекрасным примером того, как творческий подход и действительно глубокое погружение в задачу помогают решать даже самые нестандартные бизнес-проблемы. Мы не просто «настроили сервер», а создали по-настоящему уникальное аппаратно-программное решение, которое идеально отвечало всем потребностям клиента. И да, теперь мы точно знаем, как заставить промышленный контроллер играть на рояле!

Частые вопросы

Почему для проекта не подошел бы более дешевый Raspberry Pi?

Raspberry Pi, безусловно, отличное устройство для хобби-проектов и прототипирования. Но для коммерческой инсталляции, которая должна работать 24/7, промышленный ПЛК Wiren Board гораздо надежнее. У него более стабильное питание, нет никаких проблем с SD-картой (ведь используется eMMC-память), и он изначально спроектирован для абсолютно безотказной работы.

Можно ли удаленно менять настройки синтезатора после установки?

Да, конечно, такая возможность есть! Мы предусмотрели для клиента безопасное подключение к контроллеру по SSH. Если вдруг понадобится, наш инженер может в любой момент подключиться, остановить сервис, запустить Pianoteq в графическом режиме с X-forwarding, внести нужные изменения и затем снова запустить сервис.

Насколько сложно было найти и устранить все технические проблемы?

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

Нужна помощь с проектом?

Специалисты АйТи Фреш всегда готовы помочь с архитектурой, DevOps, безопасностью и разработкой — у нас за плечами более 15 лет опыта.

📞 Связаться с нами
#Linux#ARM#MIDI#ALSA#ПЛК#Автоматизация#systemd#аудио
Комментарии 0

Оставить комментарий

загрузка...

Подпишитесь на рассылку ITfresh

Раз в неделю — практические гайды для руководителя IT и сисадмина: безопасность, 1С, миграции, резервные копии, лайфхаки из реальных проектов.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.