(16-01-2017 07:47)urfinjuss66 писал(а):  Нам интересен режим передачи аудиоданных без проверки и повторной отправки пакетов. Ни у кого ж нет претензий к витой паре интернет, который идет х.з. знает где(электрические щитки...) и длиной километры.

Не будем говорить про то, что битперфетность - это прямо указанный параметр в официальных спецификациях производителей чипсетов и интерфейсов ЮСБ аудио. А официальные спеки публиковать - это уж точно не на аудио форумах фантазировать...
Поговорим про другое.
Зачем сравнивать совершенно , принципиально несравнимые вещи?
Передачу данных на расстояния в тысячи/сотни км (не ограничено) с единицами метров (до 5). Не нужно сравнивать систему, надежность передачи данных которой рассчитана на устойчивость при глобальном ядерном ударе, с подключением периферийных устройств на метровых расстояниях, надежность которого (в сравнении с надежностью связи в усл. глобального ядерного конфликта) вообще пофиг. Это я про Пентагон, АРПАНЕТ и Интернет - ее прямого наследника (с его протоколами).
Такая себе отличная иллюстрация известного философского закона про переход количества в качество.
Не нужно прикручивать протоколы с квитированием туда, где они наверняка совсем не нужны.
Вот смотрите - АйПи пакеты продвигаются в Интернет, адрес назначения один. Но пути могут быть разными, расстояния разными, устройства - разными, технологии по ходу продвижения - разными. По ходу продвижения пакета меняются его заголовки, он может инкапсулироваться в разные протоколы, ожидать в разного рода буферах и - ГЛАВНОЕ - он может отбрасываться - штатно. Т.е предполагается, что на том или ином этапе пакет может быть дропнут. Не дождался своей очереди в буфере, потому, что продвигался более приоритетный трафик, например. Буфер переполнился. До побачення, пакет.
То же самое с кадрами на 2-м уровне. Все же слышали про так называемое качество обслуживание в эзернет сетях? Там теги всякие, очереди. Причем коммутаторы могут по-ходу продвижения кадров эти теги менять, т.е. кадр постоянно претерпевает какие-то изменения. И, конечно, при определенных условиях, и тоже штатно, может отбрасываться. Это не неисправность. Это так эта машинерия работает. Для чего? - например - чтобы вы могли АйПиТВ пользоваться комфортно. Причем это все работает вплоть до домашнего роутера. Иногда проприетарные алгоритмы.
Т.е. продвижение данных в Интернет, посредством стека АйПи протоколов, предполагает, что они могут теряться. В штатной ситуации. А значит, нужны и механизмы на уровне протоколов, чтобы можно было данные доставить гарантированно. Там, где то необходимо, конечно.

А теперь - наш случай - ЮСБ. Его скорее нужно с СПДИФ сравнивать.
В СПДИФ, при исправном интерфейсе, потеря данных невозможна, СПДИФ поток и есть данные. Это изохронный синхронный интерфейс. Чтобы он потерял данные из-за внешнего воздействия, наверное нужно построить специальное устройство - индуктор там какой-то.
А если взять балансный вариант передачи - как в АЕС/...
ЮСБ - балансный интерфейс, расстояния - до 5 метров. Ничего такого с его кадрами не происходит при передаче, никакой обработки. Сравните с Интернетовской (как одна из технологий в рамках - Эзернетовской) машинерией со кучей всяких обработок по-ходу и штатной возможностью дропанья пакетов/кадров!
Как бы не было как с интерполяций в СДДА - она типа есть, но на практике применяется чрезвычайно редко- кадры могут теряться, но раз в 100 часов прослушивания.
Зачем в таком случае протокол с квитированием и повторная передача кадра?
Я тут пытаюсь поставить эксперимент, но без фанатизма. Поставил Кэйк Валк - но это целая студия - программа сложная, спешить разбираться не буду. А с наскоку - фигвам - не выходит. Может кто-то посоветует программу по-проще, чтобы записывала с СПДИФ входа?