Можно, но на это нужно время. Которого нет. Так что это все на потом оставлено, на потом.
Самодельный Ethernet-транспорт для аудиоинтерфейса.
- Автор темы Rst7
- Дата начала
Можно, но на это нужно время. Которого нет. Так что это все на потом оставлено, на потом.
Мы сейчас наш девайс по всем параметрам сравниваем с двумя изделиями RME
1. С лучшим в индустрии по задержке RME HDSPe в инкорнации RME MADI FX
2. С лучшим с точки зрения качества AD/DA - RME ADI-2 Pro
По задержкам мы приблизились в плотную к RME HDSPe благодаря тому, что можем более точно выставить буфер, а не как у RME - 32, 64, 128,256 и т.д.
По качеству AD/DA - вот что намерили на скорую руку всем извстной утилиткой RMAA -
Нужно понимать, что RMAA меряет данные всего тракта AD/DA , но у нашего девайса AD стоит лучше и схемно реализован, чем DA - так что по качеству AD наш девайс с ADI-2 Pro очень близки.
Вот что я намерял (просто запись закороченного входа) по собственным шумам (а собственно это и динамический диаппазон)
На ADI-2Pro -
Это ADI-8 QS -
А вот на нашем девайсе -
Что касается интерполяций выпавших сэмплов у RME - я сейчас не уверен, что там есть какая-то интерполяция. Эта мысль у меня возникла по той причине, что RME крайне редко прям щёлкает при тормозах, она начинает сыпать такой цифровой шелест.... Но и Димин драйвер на сегодня ведёт себя точно так-же, активных щелчков я не слышу.
Но всё это ещё нужно тестировать и тестировать.... Пока мы явные баги и просчёты устраняем.
Последнее редактирование:
ИМХО
Допустимое в практике решение: писать буфер, как есть, а корректировать артефакты уже в треке специальной утилиткой.
В этом случае нет проблемы с глубиной анализа и продвинутостью алгоритма - причём, для идентификации артефакта можно кодировать артефакт в железяке, что б потом утилиту натравливать именно на артефакт, а не заставлять умничать с поиском...
Как мне кажется, все цифровые артефакты, которые возникают и могут возникнуть, ни как не влияют на запись..... это артефакты воспроизведения. А тут в большинстве ситуаций, что называется - пофиг.
Ну и как тут уже обсуждали - нужно ведь ещё узнать, что при записе был артефакт.... я что-то не припомню, чтоб девайсы массово об этом пользователю сообщали или ПРИ или ПОСЛЕ записи.
На сколько я понимаю ситуацию, Дима это может сделать в своём драйвере, но точно всем этим заниматься будем позже...
Последнее редактирование:
Если сбой буфера при записи - то это не воспроизведение. Это уже навсегда.
А дубли бывают уникальные - музыкант повторить не сможет.
А сбой буфера в принципе пишущим железом распознаваем - и замаркировать его нет алгоритмических проблем.
Ну, а то, что никто так не делает - не значит, что так делать не надо.
ИМХО
[DOUBLEPOST=1547750743][/DOUBLEPOST]
ОК.
Я не так понял...
Впрочем, сама идея от этого не становится хуже...
Процесс записи с мониторингом как правило, и артефакт мы СЛЫШИМ в этот момент и ни как не знаем - он во входном буфере возник или в выходном.
Дима вот утверждает, что сбой записи это из ряда вон выходящая ситуация - которую я пока не идентифицировал...., а вот артефакты воспроизводящего буфера ловлю на критически малых задержках регулярно.
@Aleksandr Oleynik, это не артефакты, это отсутствующий целиком буфер, и в этом случае возможно 2 варианта - повторение буфера (если его не затерли), или буфер с нулями, ну или как подозреваем в РМЕ какая-то интерполяция, но это был бы идиотский костыль, так как без "будущих" буферов сынтерполировать нормально невозможно, это будет что-то по качеству как FFT(размер буфера/2). И даже хуже, так как нет семплов из будущего.
это если из ADC сразу в память, а если есть промежуточные звенья - может и что-то пропасть. Но в этом случае это артефакт не записи, а передачи.
Ну в конкретно нашем случае - только если переполнились буфера на перепосылку. Повторюсь в очередной раз - у нас транспорт не UDP, как в Dante/AES67/etc, а TCP.
За время какого буфера, который большой, на запас перепосылки? Аварийная ситуация, закрытие соединения устройством и попытка открытия его заново уже хостом. Просто такая ситуация в потоке - это не единичная ошибка, а серьезная авария. Сейчас он в 32 раза больше, чем период нормального следования пакетов.
Не очень мне понятно, как контрольные суммы могут помочь восстановлению. Возможно, Вы путаете контрольные суммы и корректирующие коды? Если да и речь о корректирующих кодах - то их нет, это бессмыслица в данном случае, проще передать заново, чем восстанавливать потерю. Более того, корректирующие коды для восстановления целого потерянного пакета будут с огромной избыточностью.
Кому интересно вот пинги из нагруженной сети.
Несколько зданий, подсетей, вланов, куча хостов, роутеров, свичей. Медиа конвертеры оптические между зданиями.
Пинги при стандартном пакете 32 байта 1 мс, изредко до 3 мс.
При увеличенном пакете до 8096 байт от 3 до 7 мс.
Сеть в большей части 100 мбит
Несколько зданий, подсетей, вланов, куча хостов, роутеров, свичей. Медиа конвертеры оптические между зданиями.
Пинги при стандартном пакете 32 байта 1 мс, изредко до 3 мс.
При увеличенном пакете до 8096 байт от 3 до 7 мс.
Сеть в большей части 100 мбит
Вложения
получается к асио-буферу добавляется накопительный буфер на трансфер в 256 семплов?
@basЫl, нет. Он там параллельно живёт, на случай необходимости перепосылки. Никуда он не добавляется и в нормальном режиме задержек не создаёт. Вообще это все для того, чтобы точно не потерять ничего при записи.
[DOUBLEPOST=1547836853][/DOUBLEPOST]@Hron, почему? Работают несколько девайсов в одной сети, в полной синхронизации.
[DOUBLEPOST=1547836949][/DOUBLEPOST]Отсутствует он потому, что это лишнее удорожание девайса.
[DOUBLEPOST=1547836853][/DOUBLEPOST]@Hron, почему? Работают несколько девайсов в одной сети, в полной синхронизации.
[DOUBLEPOST=1547836949][/DOUBLEPOST]Отсутствует он потому, что это лишнее удорожание девайса.
Ну вот я тоже пытал Диму сегодня по телефону
также как и вы не въезжая до конца.Доп буфер есть! Но он не 256 сэмплов, а сколько поставите. Т.е., как и в Dante, есть ASIO буфер на стороне DAW и хвостовой буфер на стороне девайса.
Оба настраиваются с кратностью 8 сэмплов.
НО! Этот доп хвостовой буфер не для записи, а для воспроизведения. Даже если он будет 8 сэмплов, а "задержутся" при записи 200 сэмплов - они все будут записаны, а вот услышим только 8.
[DOUBLEPOST=1547840512][/DOUBLEPOST]Что касается работы клока - я сейчас тестирую работу двух девайсов в одной сети и мастером становится автоматом тот, "кто первый встал с постели", ни думать об этом, ни настраивать ничего не нужно.
[DOUBLEPOST=1547840621][/DOUBLEPOST]
Дима, я скажу зачем.
Когда нам нужно будет поток передать в MADI или Dante сеть - это нужно будет сделать.
Либо, если дойдём до цифровых (spdif, AES, adat) входов/выходов - тоже нужно будет это сделать.
Также это нужно будет обязательно, когда захотим сделать для цифровых пультво платы расширения с Нашим Эзернетом на борту.
Последнее редактирование:
Ну когда до этого ход дойдет - тогда и будем разбираться. Сейчас мне кажется, что 2/4 получился вполне самодостаточным, и пихать туда всякие цифровые in/out явно будет лишним.
2/4 получился абсолютно самодостаточным! Точно ни чего туда «пихать» ещё не нужно.
Про все «бриджи» с другим оборудованием будем думать потом.
Кстати, что DANTE, что набирающий обороты в про среде AES-67 - это ведь всё UDP протоколы, и нужно будет при стыковке с ними наш TCP/IP в него и из него конвертить.
Желанием сделать перепосылку пакетов, но нежеланием изобретать свой набор костылей для реализации их через UDP. Ну или не изобретать, а повторять то, что уже есть в TCP.
Кто быстрее?