1) Задача и исходные предпосылки
Требуется организовать двусторонний аудиоканал между двумя устройствами Magewell Pro Convert Audio DX поверх сети на базе SRT. Формулировка выглядит простой, однако за ней обычно скрывается типичная путаница между тремя разными сущностями:
Аудиоканалы (например, стерео = 2 канала L/R).
SRT‑потоки / SRT‑сессии (каждая сессия переносит медиапоток в одном направлении).
Сетевые роли Caller/Listener (кто инициирует соединение и как это проходит через NAT/динамические IP).
Euclid Lab провела воспроизводимый эксперимент на базе Pro Convert Аudio DX : подтвердить одновременную двустороннюю передачу стерео‑аудио (full‑duplex) между двумя устройствами, используя простой и прозрачный метод контроля — USB Audio + две копии VLC на каждом ПК.
Иными словами, нужно было не просто «увидеть статус Connected», а получить доказательство уровня «ухом слышно», что обе стороны одновременно:
отправляют локальный звук в сеть и
принимают удалённый звук из сети, без переключений и без работы «по очереди».
2) Физический стенд
2.1 Компоненты
2 устройства Magewell Pro Convert Audio DX (далее: Устройство A и Устройство B)
2 компьютера (ПК A и ПК B)
1 небольшой гигабитный коммутатор между устройствами (Gigabit Switch)
2 USB‑подключения (каждый ПК подключён по USB к своему Magewell как UAC‑аудиоустройство)
2 Ethernet‑подключения (каждый Magewell подключён к гигабитному коммутатору)
2.2 Сетевая топология (лаборатория)
Оба устройства работали в одном лабораторном сегменте Ethernet, со статическими адресами в одной подсети (для чистоты эксперимента и удобства диагностики). Логика эксперимента полностью переносится на схему «публичный IP ↔ NAT/динамический IP» — различаться будет только обеспечение доступности портов и выбор роли Caller/Listener.
3) Концепция: что именно мы строим
3.1 SRT‑поток — одно направление
SRT‑сессия (то, что часто называют «SRT‑каналом») переносит медиапоток в одном направлении: либо A→B, либо B→A. Да, внутри SRT есть служебный двусторонний обмен (контроль, подтверждения, повторная отправка потерянных пакетов), но это не второй медиапоток.
Практическое следствие:
Полный дуплекс (full‑duplex) требует две SRT‑сессии.
Одна сессия — «туда», вторая — «обратно».
3.2 Аудиоканалы живут внутри потока
Стерео — это два аудиоканала (L/R) внутри медиапотока. Они не равны SRT‑сессиям.
Корректная логика такая:
что��ы получить двустороннее стерео, нужно:
2 SRT‑сессии (A→B и B→A),
и в каждой сессии — стерео‑аудио (2 канала).
3.3 Caller/Listener — это про сеть, а не про направление звука
Ещё одна типовая путаница: кажется, что Caller/Listener определяет направление аудио. Это не так.
Caller — тот, кто инициирует соединение (обычно сторона за NAT/с динамическим IP).
Listener — тот, кто ждёт входящее соединение на порту (обычно сторона с публичным статическим адресом).
Направление аудио определяется TX/RX, а не Caller/Listener:
TX — устройство отправляет аудио в сеть.
RX — устройство принимает аудио из сети.
Отсюда важное следствие для реальных инсталляций:
сторона за NAT/динамическим IP может быть Caller одновременно и для TX, и для RX,
а сторона с публичным IP держит два Listener‑порта.
4) Настройка устройств: два потока, два порта, полный дуплекс
Мы собрали full‑duplex следующим образом.
4.1 Поток №1: A → B
На Устройстве A настроили SRT TX (передача) в режиме Listener на порту P1.
На Устройстве B настроили SRT RX (приём) в режиме Caller, указывая адрес Устройства A и порт P1.
4.2 Поток №2: B → A
На Устройстве A настроили SRT RX (приём) в режиме Listener на порту P2.
На Устройстве B настроили SRT TX (передача) в режиме Caller, указывая адрес Устройства A и порт P2.
Таким образом:
Устройство A одновременно «слушает» два порта: один для направления A→B, второй для направления B→A.
Устройство B одновременно поднимает два исходящих подключения: одно для своей передачи и одно для своего приёма.
Это выглядит непривычно, если ожидать «один порт — один канал», но именно так получается корректный full‑duplex в SRT‑логике.
4.3 Параметры передачи (принцип настройки)
Для обоих направлений выставлялись согласованные параметры (кодирование, битрейт, latency, MTU, overhead). Идея проста:
одинаковые и разумные параметры на двух потоках дают предсказуемое поведение,
в случае проблем проще локализовать причину (сеть vs. маршрутизация vs. приложение на ПК).
5) Маршрутизация аудио внутри Magewell: USB ↔ SRT
Ключевой момент эксперимента — использование USB Audio как наглядного интерфейса ввода/вывода.
На каждом устройстве была настроена логика «мост»:
USB Audio (с ПК) → в SRT TX
из SRT RX → в USB Audio (на ПК)
То есть:
если ПК отправляет звук в USB‑аудиоустройство Magewell — этот звук уходит в сеть,
если из сети приходит звук — он появляется на ПК как USB‑вход.
6) Проверка «в бою»: две копии VLC на каждом ПК
Чтобы проверить полный дуплекс максимально честно, мы выполнили одинаковые действия на ПК A и ПК B.
6.1 VLC №1 — «передатчик» (Playback)
Открываем аудиофайл и запускаем воспроизведение.
В качестве устройства вывода выбираем Magewell (USB Audio).
Результат:
VLC отправляет звук по USB,
Magewell принимает звук по USB и направляет его в SRT TX.
6.2 VLC №2 — «приёмник» (Capture/Monitoring)
Запускаем вторую копию VLC в режиме захвата аудио (Capture).
В качестве устройства ввода выбираем Magewell (USB Audio).
В качестве устройства вывода выбираем локальные динамики ПК.
Результат:
всё, что приходит из сети по SRT RX, Magewell отдаёт в USB,
VLC подхватывает это как входной звук и выводит на колонки.
6.3 Итог наблюдения
На ПК A слышно аудио, которое воспроизводит ПК B.
На ПК B слышно аудио, которое воспроизводит ПК A.
Оба направления работают одновременно, то есть это именно full‑duplex, а не режим «по очереди».
7) Выводы и практическая ценность
Полный дуплекс по SRT между двумя Pro Convert Audio DX реализуется через две SRT‑сессии, по одной на каждое направление.
Стерео — это вопрос количества аудиоканалов внутри потока, а не количества SRT‑сессий.
Caller/Listener — сетевой механизм установления соединения (критичен при NAT/динамических адресах) и не определяет направление аудио. Направление определяет TX/RX.
Методика теста через USB Audio + две копии VLC — простой, быстрый и воспроизводимый способ доказать работоспособность решения без специализированного ПО.
