Проектирование операционных систем для обработки аудио и видео с низкой задержкой в инженерии

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

В современной технике обработка аудио и видео в реальном времени является основополагающим требованием для широкого спектра приложений. Для прямого вещания требуется, чтобы аудио и видео потоки оставались идеально синхронизированными с субмиллисекундными допусками дрейфа. Системы виртуальной реальности (VR) и дополненной реальности (AR) требуют времени ожидания движения до фотона менее 20 миллисекунд для предотвращения болезни симулятора. Промышленная автоматизация опирается на замкнутые циклы управления, где данные датчиков с камер и микрофонов должны обрабатываться и действовать в течение жестких сроков в реальном времени. Телемедицина, инструменты удаленной совместной работы и автономные транспортные средства аналогично зависят от предсказуемой обработки мультимедиа с низкой задержкой.

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

Низкая задержка определяется временем, которое требуется системе для реагирования на событие - приход аудиообразца, видеокадра или аппаратного прерывания - и получения соответствующего вывода. Для аудио задержки менее 10 миллисекунд часто считаются в режиме реального времени; для видео типичны сквозные задержки менее 100 миллисекунд для двусторонней связи и менее 20 миллисекунд для интерактивной VR. Эти ограничения выдвигают обычные операционные системы общего назначения за пределы их предполагаемого дизайна. Стандартные ОС отдают приоритет пропускной способности и справедливости, а не детерминистскому поведению. В результате инженерные команды должны принять специализированные стратегии проектирования и часто модифицировать или заменять базовую ОС для удовлетворения требований задержки.

Проблемы проектирования операционных систем для низкой задержки

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

Прерывная обработка и перерывы в задержке

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

Расписание задач и приоритетная инверсия

Стандартные планировщики (например, полностью справедливый планировщик Linux) предназначены для пропускной способности и справедливости, а не для соблюдения сроков. Задачи в реальном времени - те, которые должны выполняться в течение фиксированного временного окна - могут быть отложены процессами, не относящимися к реальному времени. Классическая проблема инверсии приоритета возникает, когда приоритетная задача блокируется в ожидании ресурса, удерживаемого задачей с низким приоритетом, в то время как задача со средним приоритетом предвосхищает задачу с низким приоритетом. Это может привести к неограниченной задержке. Проекты ОС с низким уровнем задержки должны реализовывать протоколы наследования приоритетов или использовать политики планирования в реальном времени, такие как SCHED FIFO и SCHED RR , чтобы гарантировать, что приоритетная исполняемая задача всегда выполняется.

Преимущество ядра и спиновые замки

В стандартном ядре длительные системные вызовы или операции драйвера устройства могут отключать упреждение в течение длительных периодов. Для аудио и видео с низкой задержкой ядро должно быть полностью упреждаемым. Набор исправлений Linux PREEMPT RT превращает ядро в полностью упреждаемое ядро в реальном времени, заменяя большинство спиновых замков на мутексы, которые поддерживают приоритетное наследование, и делая превентивные обработчики прерываний. Однако даже ядро PREEMPT RT может ввести недетерминизм, если небрежные драйверы устройств используют сырые шпинлоки. Инженерные команды должны проверять весь код пространства ядра, который работает в пути аудио / видео данных.

Управление памятью и ошибки страниц

Спрос на подачу, виртуальную память и прозрачные огромные страницы отлично подходят для систем общего назначения, но катастрофически для приложений реального времени. Один крупный сбой страницы может вызвать скачок задержки в несколько миллисекунд — далеко за пределами приемлемого окна для обработки аудиобуфера. Аудио и видео приложения в реальном времени должны блокировать весь свой рабочий набор в физическую оперативную память с помощью системных вызовов, таких как mlockall(). Кроме того, для предотвращения сбоев страницы во время критически важных секций производительности часто требуется пред-сбойная память и использование огромных страниц (2 МБ или 1 ГБ) для уменьшения промахов TLB и задержки перемещения по таблице страниц.

Jitter и Buffer Tuning

Задержка — это не только абсолютное время отклика; согласованность — или джиттер — одинаково важны. Система, которая иногда доставляет кадр на 5 мс позже, может быть неприемлемой, даже если средняя задержка составляет 2 мс. Jitter возникает из-за непредсказуемых задержек планирования, переменного времени доступа к памяти, теплового дросселирования и коалесцирования прерываний. Операционные системы должны предоставлять инструменты для измерения и управления джиттером, такие как изоляция процессора (isolcpus), ограничения планирования в реальном времени и возможность установки регуляторов частоты процессора в режим производительности.

Стратегии проектирования для операционных систем с низкой задержкой

Решение этих проблем требует сочетания конфигурации уровня ОС, модификаций ядра, а иногда и полного перехода на операционную систему реального времени (RTOS).Выбранная стратегия зависит от требуемых пределов задержки, сложности приложения и аппаратной платформы.

Операционные системы реального времени (RTOS)

Для самых строгих требований — сроков службы ниже 1 микросекунды — традиционные RTOS, такие как FreeRTOS, VxWorks, или QNX, часто являются лучшим выбором. Эти системы обеспечивают детерминированное время отклика на прерывания, предсказуемое планирование с приоритетным упреждением и минимальным воздействием на ядро. Они широко используются во встроенных инженерных приложениях: цифровые аудиомиксеры, системы контроля качества камеры и авионики на дисплеях. Однако в RTOS часто отсутствуют богатые экосистемы драйверов устройств и POSIX-совместимые программные интерфейсы, найденные в Linux, которые могут увеличить усилия по разработке, когда необходимо поддерживать сложное оборудование (например, датчики камеры высокого разрешения, интерфейсы, совместимые с USB-аудио).

Linux с поддержкой PREEMPT RT

Для многих инженерных приложений Linux с патч-набором PREEMPT RT обеспечивает убедительную промежуточную основу. Он предлагает полнофункциональную операционную систему с отличной аппаратной поддержкой, позволяя при этом низкие задержки в диапазоне 5-15 микросекунд на современных многоядерных процессорах. Для достижения этого инженеры должны:

• Включите конфигурацию ядра CONFIG PREEMPT RT.
• Назначить политику планирования в реальном времени (]SCHED FIFO) для аудио/видео потоков с высокими приоритетами (например, 90-99 по шкале 100).
• Используйте изоляцию процессора, чтобы посвятить одно или несколько ядер исключительно задачам в реальном времени, уменьшая помехи от прерываний и ведения расписания.
• Установите isolcpus и rcu nocbs параметры загрузки ядра.
• Отключите масштабирование частоты процессора, гиперпоточность (которая может ввести трэширование кэша) и любые функции прошивки, сохраняющие мощность, такие как C-состояния или P-состояния, которые добавляют задержку.

Приоритетное планирование и управление потоком

Даже с ядром реального времени, планирование должно быть тщательно спроектировано. конвейеры обработки аудио обычно состоят из нескольких потоков: нити захвата, нити обработки и нити воспроизведения. Они должны работать на самых высоких уровнях приоритета в реальном времени. Чтобы предотвратить инверсию приоритета, используйте pthread mutexattr setprotocol с PTHREAD PRIO INHERIT на всех мутексах, совместно используемых с задачами более низкого приоритета. Кроме того, рассмотрите структуры данных без блокировки (например, кольцевой буфер с использованием атомных операций) для связи между нитями производителя и потребителя — устранение блокировок вообще удаляет основной источник джиттера планирования.

Прерывание смягчения и голосования

В некоторых проектах прерывания сами становятся обязательством. Каждое прерывание вызывает переключатель контекста и смыв кэша. Для высокопроизводительных аудио/видеопотоков — например, 96 кГц 32-канального аудио — прерывание на буфер может перегружать ЦП. Существуют две стратегии смягчения:

• Прерывное объединение: Группа множественных аппаратных событий в один прерывание. Это уменьшает накладные расходы на процессор, но немного увеличивает задержку.
• Опрос: Поток приложения занят — ожидает в регистре с картой памяти для обнаружения новых данных, полностью избегая прерываний. Это дает наименьшую задержку и джиттер, но потребляет выделенное ядро процессора при 100% использовании. Опросы распространены в высокопроизводительных профессиональных аудиоинтерфейсах (например, RME, MOTU) и в захватах кадров камеры.

Оборудование для низкочастотного аудио / видео

Операционная система не может преодолеть фундаментальные аппаратные узкие места. Выбор правильной платформы необходим для достижения целей задержки.

Архитектура процессора и базовая изоляция

Многоядерные процессоры позволяют выделенные ядра для задач реального времени. Однако не все ядра равны: на современных системах Intel и AMD ядра разделяют L3 кэш и контроллеры памяти. Чтобы свести к минимуму недетерминизм, назначить потоки в реальном времени паре ядер, которая разделяет L2 кэш, и избежать использования родственной пары, которая разделяет L2 кэш. NUMA (Non-Uniform Memory Access) также имеет значение — убедитесь, что память потока реального времени распределяется на том же узле, что и его назначенное ядро, чтобы избежать штрафов за задержку кросс-сокета. numactl и taskset для мелкозернистого управления.

Подсистема ввода/вывода: DMA и архитектура автобусов

Direct Memory Access (DMA) позволяет передавать аудио/видео данные непосредственно между периферийной и системной памятью без вмешательства ЦП. ОС должна обеспечивать эффективный API DMA и обеспечивать, чтобы буферы DMA были смежными в физической памяти (или использовать IOMMU для отображения разбросанных страниц). PCIe Gen4/5 устройства предлагают высокую пропускную способность и низкую задержку, но корневой комплекс и топология коммутаторов могут вводить переменные задержки. Для окончательного детерминизма используйте устройства с выделенными каналами DMA и избегайте совместного использования той же полосы PCIe с другими высокопроизводительными периферийными устройствами.

Пропускная способность памяти и задержка

Видео высокого разрешения (4K, 8K или несколько потоков) оказывает огромное давление на полосу пропускания памяти. Поток видео 4K 60 fps в сыром виде превышает 12 Гбит/с. Операционные системы должны быть сконфигурированы, чтобы избежать голодания полосы пропускания памяти: использовать огромные страницы для снижения давления TLB, закрепить память на локальном узле NUMA и обеспечить, чтобы контроллер памяти не был переподписан другими процессами. Для аудио, низкая задержка часто требует небольших размеров буфера (например, 32 образца при 48 кГц - ~0,67 мс буфер). Это заставляет многие небольшие транзакции ввода/вывода, которые чувствительны к задержке активации строк DRAM.

Выбор ОЗУ с более низкой задержкой (например, DDR4 3200 CL14 против CL22) и запуск контроллера памяти на максимальной частоте помогает.

Специализированные аппаратные ускорители

FPGA, GPU и выделенные DSP могут загружать обработку с процессора, но они вводят свои собственные проблемы задержки и синхронизации. При использовании FPGA для предварительной обработки аудио / видео (например, цветовая градация в реальном времени или реверберация свертки) ОС должна управлять передачей данных на ускоритель с минимальными накладными расходами. Технологии, такие как Intel Data Streaming Accelerator (DSA) или AMD SmartDMA , могут выполнять копии памяти и преобразования данных без участия процессора. В экстремальных сценариях с низкой задержкой весь цикл обработки может работать на ткани FPGA, причем ОС отвечает только за конфигурацию и мониторинг.

Методы оптимизации программного обеспечения для аудио/видео трубопроводов

Помимо конфигурации на уровне ОС, методы на уровне приложений необходимы для достижения минимально возможной задержки.

Запирание памяти и предвзятость

Как уже упоминалось, mlockall(MCL CURRENT | MCL FUTURE) блокирует все текущие и будущие страницы памяти в ОЗУ. Однако это только предотвращает замену; это не гарантирует, что записи в таблице страниц заполнены. Чтобы избежать ошибок страницы при первом доступе, предварительно нажмите на каждую страницу аудио/видео буферов, написав на каждую страницу один раз во время инициализации. Для огромных страниц выделите их перед блокировкой памяти и используйте /dev/hugepages или mmap с MAP HUGETLB.

Атрибуты потока в реальном времени

Тщательно установите атрибуты потока:

• Используйте pthread attr setschedpolicy(&attr, SCHED FIFO) или SCHED RR.
• Установите приоритет, используя pthread attr setschedparam , до высокого значения (например, 80-99), но избегайте использования максимального приоритета, если поток действительно не является наиболее важной задачей всей системы.
• Как только нить создана, позвоните pthread setschedparam снова, чтобы поднять ее приоритет над тем, что из ядра потоков, как irqbalance .
• Установите сродство процессора потока к выделенному ядру с pthread setaffinity np .

Очереди и буферы без замков

Традиционные мутексы вводят вызов ядра (sys futex) и потенциальный джиттер планирования. Для медиа-проводников используют буферы колец без блокировки, однопользовательские (SPSC) . Они полагаются на семантику заказа памяти (например, C11 atomic store explicit с памятью order release) и никогда не вызывают в ядро. Многие профессиональные аудио фреймворки, такие как JACK и PipeWire, используют этот подход для передачи буфера с нулевым копированием между клиентами.

Кодирование практики для детерминизма

• Избегайте динамического распределения памяти на горячем пути. Предварительно распределите все буферы.
• Не используйте синхронный I/O. Используйте асинхронные или неблокирующие API (например, io uring с режимом опроса).
• Минимизируйте системные вызовы, команды пакетов, где это возможно.
• Избегайте плавающих точек для целых преобразований или других операций, которые могут заманить вас на медленный путь.
• Используйте встроенные компиляторы для операций SIMD (SSE/AVX) для эффективной обработки образцов.

Тематические исследования: системы с низкой задержкой на практике

Профессиональные аудио рабочие станции (DAW)

Цифровые аудио рабочие станции, такие как Pro Tools и Logic Pro, работают на macOS или Windows, но для окончательного отслеживания с низкой задержкой инженеры часто обращаются к Linux с JACK Audio Connection Kit. JACK позволяет использовать суб-5 мс задержку в оба конца на товарном оборудовании, используя бесблокировочный обмен буферами и планирование в реальном времени. Многие студии звукозаписи используют специально построенные Linux-машины с ядрами PREEMPT RT и выделенными ядрами ЦП для аудиодрайвера. Например, AVL Drumkits и