Нет ни единого режима, который бы предусматривал верификацию и повторный запрос в случае утери битов? Как то странно. Получается, надо реализовывать не потоковую передачу файлов, а его копирование с проверкой контрольной суммы прям на цап, и потом уже преобразовывать в аналог.

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

Необходимо лишь иметь контроллер на входе до цапа + буфер, который будут заниматься сверкой crc и потом передавать порциями верные данные цапу, видимо это специально не делают

И как вот это заиметь на практике? Кто-то делает?
И остается вопрос - будет ли этот контроллер все получать с компа? Он остается в тех же условиях, что и приемник - получит только то, что увидит. Ведь компьютер все шлет все равно в реальном времени потоком и не делает пауз.. Изменять протокол передачи в компе еще тогда?
Может просто кабель покороче и получше? или комп с цапом в один корпус?

---

(30-12-2016 18:39)oleksa писал(а):  И как вот это заиметь на практике? Кто-то делает?

Когда сделают, вполне возможно, что будет, как написал onv

(30-12-2016 02:15)onv писал(а):  Вряд ли можно назвать культом легальное, законное использование дырки в помехоустойчивости протокола передачи аудиоданных для зарабатывания на этом денег. ... завтра, когда будет принят и внедрен помехоустойчивый протокол, все эти наработки обесценятся и все придет в продажную зону, грубо говоря, 2-5$

Кроме того, причина, что этого не делают ("не меняют протокол передачи данных в компе"), вероятно в том, что по ЮСБ не только хай-файщики музыку изволят прослушивать, а и профи аудиоданные записывают. И здесь нужны минимальные задержки, без которой не будет чёткой синхронизации. А буфер, сверка и повторная отправка данных естественно задержки существенно увеличит.
То есть нет жуткого заговора, чтоб "срубить бабла с Хай-Файщиков", есть объективная необходимость в минимальных задержках при работе с аудиоданными.

(30-12-2016 18:39)oleksa писал(а):  И как вот это заиметь на практике? Кто-то делает?
И остается вопрос - будет ли этот контроллер все получать с компа? Он остается в тех же условиях, что и приемник - получит только то, что увидит. Ведь компьютер все шлет все равно в реальном времени потоком и не делает пауз.. Изменять протокол передачи в компе еще тогда?
Может просто кабель покороче и получше? или комп с цапом в один корпус?

При асинхронном режиме комп шлет только по запросу устройства. Запрос на следующий пакет отправляется только если все с предыдущим.

Простой пример из практики. Аркам рдак. Вин7. Аимп. Два режима васапи эксклюзив -push и event. Пуш это когда комп сам толкает данные все подряд. Бывают щелчки (пропущенные пакеты). При режиме ивент ( запрос по событию) ни единого разрыва.

И разные кабеля Юсб не влияют, то есть разницы между ними не слышно в этом режиме event?

(30-12-2016 18:53)romeo105 писал(а):  Аркам рдак. Вин7. Аимп. ... Бывают щелчки (пропущенные пакеты). При режиме ивент ( запрос по событию) ни единого разрыва.

Щелчки в Аркаме возникают по множеству причин. Я с ними год боролся - все нервы вымотали мне. Что только не пробовал, какие только форумы не курил. Например, он щёлкает, даже когда вообще ни одного кабеля к нему не подключено... какие уж тут пропущенные пакеты.
О щелчках отписывался уже подробно. Помогло только одно действо...

(30-12-2016 18:43)Kir9790 писал(а):  

---

Когда сделают, вполне возможно, что будет, как написал onv


Кроме того, причина, что этого не делают ("не меняют протокол передачи данных в компе"), вероятно в том, что по ЮСБ не только хай-файщики музыку изволят прослушивать, а и профи аудиоданные записывают. И здесь нужны минимальные задержки, без которой не будет чёткой синхронизации. А буфер, сверка и повторная отправка данных естественно задержки существенно увеличит.
То есть нет жуткого заговора, чтоб "срубить бабла с Хай-Файщиков", есть объективная необходимость в минимальных задержках при работе с аудиоданными.

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

Странно выглядит, что записать пятигигабайтный файл на десятидолларовую флешку с 100% верификацией это не проблема, а передать 30 Мбайт на пятисотбаксовый цап с кмосами и клоками - аццки невыполнимаяя задача.

Часто в описаниях асинхронных усб аудио приблуд пишут, что в таком случае зависимость от Качества усб кабеля намного меньше

при чем тут минимальные задержки для аудиофильских ЦАПов ? Низкие значения latency важны для звукачей и конкретно для звуковых карт. Для прослушки разве не было бы логично сделать буфер, проверку crc и кешировать по несколько мегабайт наперед, затем передавать точные данные ЦАПу

(30-12-2016 19:00)Kir9790 писал(а):  Щелчки в Аркаме возникают по множеству причин. Я с ними год боролся - все нервы вымотали мне. Что только не пробовал, какие только форумы не курил. Например, он щёлкает, даже когда вообще ни одного кабеля к нему не подключено... какие уж тут пропущенные пакеты.
О щелчках отписывался уже подробно. Помогло только одно действо...

Продажа? вы говорите о щелчках реле, а я о воспроизведении. Я победил в первый вечер после покупки

Странность в том, что аудио сигнал по ЮСБ жестко привязан к реальному времени, а флешка может записываться с "плавающей" скоростью, дольше-быстрее - там это не важно, как и печать файла на принтере.
Если копать глубже, тогда надо наверное смотреть детально спецификацию протокола ЮСБ для аудио в конкретных цифрах.

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

Если разница и существует, то она точно не в том, что какой-то кабель якобы теряет\искажает пакеты. Бывают просто неисправные, но тогда идут щелчки.

А буфер есть во всех нормальных приёмниках. Только он нужен для перетактования данных перед отправкой на цап. Чтобы уменьшить временную ошибку (джиттер).

(30-12-2016 19:10)Anatoly_A писал(а):  при чем тут минимальные задержки для аудиофильских ЦАПов ? Низкие значения latency важны для звукачей и конкретно для звуковых карт. Для прослушки разве не было бы логично сделать буфер, проверку crc и кешировать по несколько мегабайт наперед, затем передавать точные данные ЦАПу

Передавать "точные данные" звучит хорошо, но надо уточнить далее "передавать" по какому кабелю, по какому конкретно протоколу и какому реально существующему цапу, который этот способ передачи "понимает"?
Если это все надо специально создавать/разрабатывать, тогда вопрос сколько это будет стоить?

(30-12-2016 19:12)oleksa писал(а):  Странность в том, что аудио сигнал по ЮСБ жестко привязан к реальному времени, а флешка может записываться с "плавающей" скоростью, дольше-быстрее - там это не важно, как и печать файла на принтере.
Если копать глубже, тогда надо наверное смотреть детально спецификацию протокола ЮСБ для аудио в конкретных цифрах.

Это понятно насчет копирования и риалтайма. Но. Если при потоковой асинхронной передаче для битперфекта нужен 300 баксовый шнурок, то почему никто не додумался допилить на тот же кмос чип пару чипов памяти, и копировать туда (с верификацией) файл и после этого уже воспроизводить?

(30-12-2016 19:02)romeo105 писал(а):  Какие проблемы могут быть с задержками записи, если входящий сигнал буферизировать в оперативную память и записывать потом уже спокойно с верификациеей?

Вероятно в том, что необходимо, чтоб звук инструментов выводился или записывался без задержек.

Р.С. Что-то не нахожу своего сообщения о щелчках в Arcam rDAC, повторю.
Речь идёт о хаотично возникающих щелчках во время воспроизведения музыки Щелчках внутренней релюшки, во время которых прерывается звук. Не во время перемотки или смены трека.
Чтоб их одолеть, по различным мнениям помогало:
- настройки винды (поставить режим энергосбережения - максимальная производительность, или же запретить ЮСБ-контроллеру выключаться, когда он не используется)
- смена режима воспроизведения (AsioForAll, Васапи Event, Push и т.д.)
- установка драйвера от Плойтек (его приходится чуток редактировать для возможности установки на Вин7х64)
- смена ЮБС-кабеля (предыдущий владелец, наш форумчанин, любящий апгрейдить....стероидить ЦАПы при покупке советовал поставить ЮСБ-кабель с ферритами, и все щелчки мол пройдут)
- что-то ещё...уже не помню....но не важно - оно мне тоже не помогло
Щёлкало даже когда к Аркаму вообще ни одного шнурка не подключено! Щёлкало, когда подключен лишь оптический шнурок (к телевизору... смотришь фильм и щёлка-щёлк, звук пропадает... я нервничаю...бррр).
Словом не попробовал лишь один совет, когда владелец подпаял входной шнурок питания сразу к плате Аркама (минуя штекер и его универсальную вилку ). Лезть и паять не хотелось, поэтому просто хорошенько почистил его контакты. И чудо! 2 недели ни единого щелчка!

Для музыкантов реалтайм и низкая задержка важна ровно как для записи используя АЦП, так и для проигрывания, используя миди-клавиатуру например. Зачем этот беспорядочный поток в один конец для простого проигрывания музыки ? Ведь можно получить 1-2-5 мегабайт, проверить их, и потом передать на вход ЦАПу без перебоев используя буфер

(30-12-2016 19:22)Kir9790 писал(а):  Вероятно в том, что необходимо, чтоб звук инструментов выводился или записывался без задержек.

Р.С. Что-то не нахожу своего сообщения о щелчках в Arcam rDAC, повторю.
Речь идёт о хаотично возникающих щелчках во время воспроизведения музыки Щелчках внутренней релюшки, во время которых прерывается звук. Не во время перемотки или смены трека.
Чтоб их одолеть, по различным мнениям помогало:
- настройки винды (поставить режим энергосбережения - максимальная производительность, или же запретить ЮСБ-контроллеру выключаться, когда он не используется)
- смена режима воспроизведения (AsioForAll, Васапи Event, Push и т.д.)
- установка драйвера от Плойтек (его приходится чуток редактировать для возможности установки на Вин7х64)
- смена ЮБС-кабеля (предыдущий владелец, наш форумчанин, любящий апгрейдить....стероидить ЦАПы при покупке советовал поставить ЮСБ-кабель с ферритами, и все щелчки мол пройдут)
- что-то ещё...уже не помню....но не важно - оно мне тоже не помогло
Щёлкало даже когда к Аркаму вообще ни одного шнурка не подключено! Щёлкало, когда подключен лишь оптический шнурок (к телевизору... смотришь фильм и щёлка-щёлк, звук пропадает... я нервничаю...бррр).
Словом не попробовал лишь один совет, когда владелец подпаял входной шнурок питания сразу к плате Аркама (минуя штекер и его универсальную вилку ). Лезть и паять не хотелось, поэтому просто хорошенько почистил его контакты. И чудо! 2 недели ни единого щелчка!

Я понимаю о каких вы щелчках говорите - аппаратных щелчках реле в самом аркаме, их я победил просто поджав контактный штекер бп. Я наверное неправильно выразился не щелчки а запинки в звуке (микросекунды пропуска) - в режиме васапи пуш звук пропадал. В режиме ивент - все ништяк. Это программная ошибка была в отличии от щелчков реле

---

(30-12-2016 19:18)Гаруспик писал(а):  Если разница и существует, то она точно не в том, что какой-то кабель якобы теряет\искажает пакеты.

Бывают просто неисправные, но тогда идут щелчки.

Кстати моё ИМХО в первом пункте совпадает (как ни странно :drink... скорее основная причина не в отсутствии бит-пёрфектности.

А вот по-второму... ИМХО щелчки и пропажа ЮСБ-пакетов - суть несвязанные между собою вещи (если только этих пакетов не пропала сотня-другая сразу). Как технарь, я попробовал посчитать "длительность звучания" этого пропавшего пакета:

(13-09-2016 22:07)Kir9790 писал(а):  Прикинул на пальцах...
Размер пакета данных для изохронного режима и для ЮСБ 2.0 - до 1024 байт. Возьмём 512 байт (0,5 кбайт) для расчёта - нечто среднее. (Специалисты могут подсказать более типичное значение)
Битрейт типового флака 16/44.1 примерно 1000 кбит/с (то есть 125 кбайт/с)
Итого, время "звучания" одного пакета 0,5/125=0,004 с (или 4 миллисекунды).

Слышимый нами щелчок длится явно горааааздо дольше по времени.

---

(30-12-2016 19:30)romeo105 писал(а):  Я понимаю о каких вы щелчках говорите - аппаратных щелчках реле в самом аркаме, их я победил просто поджав контактный штекер бп. Я наверное неправильно выразился не щелчки а запинки в звуке (микросекунды пропуска) - в режиме васапи пуш звук пропадал. В режиме ивент - все ништяк. Это программная ошибка была в отличии от щелчков реле

Хмм... такого рода запинания у меня были лишь в после установки не предназначенного для рДАК и Вин7х64 драйвера от Плойтек. Но там не пропуски звука, а короткие паузы (3-6 штук) за время воспроизведения трека. В других режимах, системах и настройках у себя таких заминок не наблюдал. Если это были такие миллисекунды - возможно это и правда были потери пакетов данных... но такого у себя не доводилось слышать, хотя пробовал и Ивент и Пуш.

(13-09-2016 22:07)Kir9790 писал(а):  Размер пакета данных для изохронного режима и для ЮСБ 2.0 - до 1024 байт. Возьмём 512 байт (0,5 кбайт) для расчёта - нечто среднее. (Специалисты могут подсказать более типичное значение)
Битрейт типового флака 16/44.1 примерно 1000 кбит/с (то есть 125 кбайт/с)
Итого, время "звучания" одного пакета 0,5/125=0,004 с (или 4 миллисекунды).

Ну во первых флак разжимается на стороне пк и на цап уже идёт pcm. Типичный хай-файный цап понимает только pcm и иногда dsd. Битрейт 44.100 hz 16 bit stereo около 1500 кбит\сек. Т.е. щелчок ещё короче. А слышим мы его не потому что он длинный, а потому что акустика (да и усилитель в известной мере) штука инерционная.

(30-12-2016 19:35)Kir9790 писал(а):  Хмм... такого рода запинания у меня были лишь в после установки не предназначенного для рДАК и Вин7х64 драйвера от Плойтек. Но там не пропуски звука, а короткие паузы (3-6 штук) за время воспроизведения трека. В других режимах, системах и настройках у себя таких заминок не наблюдал. Если это были такие миллисекунды - возможно это и правда были потери пакетов данных... но такого у себя не доводилось слышать, хотя пробовал и Ивент и Пуш.

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