(10-01-2017 23:41)Kir9790 писал(а):  Вот табличка с требованиями к джиттеру, кому интересно (весьма жёсткие... наносекунды):

Где жесткость? Цифровой транспорт с джиттером порядка 200 пика секунд это какое-то чудо типа BBK.

(11-01-2017 00:21)Гаруспик писал(а):  Где жесткость? Цифровой транспорт с джиттером порядка 200 пика секунд это какое-то чудо типа BBK.

Уж простите, но похоже на очередную байку из разряда: асинхронный режим не разновидность изохронного. Или щелчки при при потере 1 пакета данных по ЮСБ.
Приводите цифры - аргументируйте ссылочками.
И заодно подскажите какая величина джиттера у современных ПК, как транспортов цифры.

Нормируется джиттер даже для кабельного ЮСБ-разъёма:
   

Частота дискретизации передаваемого PCM, значительно отличается от частоты юсб. И вряд ли они кратны. PCM передается в реальном времени, значит во время передачи, временной опорой, становится частота юсб. Джитер неизбежен. А на стабильность частоты юсб, влияют клок самого юсб, индуктивность и емкость кабеля совместно с помехами. По корпусу компьютера протекают не малые вч токи, обычно. Также по массе материнской платы протекают вч токи, они разные на разных участках корпуса и массы платы. В точках между землей и массой юсб гнезда, появляется вч помеха, дифференциальная, относительно массы в цапе (провода индуктивны, частототы высоки), питающего провода, и витой пары юсб. Вся эта прелесть подается в земляной и массовый проводники юсб кабеля. То есть массы нет в гнезде компьютера, если над этим никто не работал. Джитер частоты юсб от этого растет. А частота юсб временная опора pcm, во время передачи. Цап и компьютер , соединены по вч чрез питание от сети, через паразитные емкости, это в бонус, ко всей прелести. А тут цыхры и шланги не влияют и все.......

(11-01-2017 00:28)Kir9790 писал(а):  Уж простите, но похоже на очередную байку из разряда: асинхронный режим не разновидность изохронного. Или щелчки при при потере 1 пакета данных по ЮСБ.
Приводите цифры - аргументируйте ссылочками.

Если я всяким баранам начну выискывать каждый раз ссылки, подтверждающие мои слова, то у меня времени не хватит.
Персонально для вас, последний раз, привожу измерения сидюка, который у меня был:

http://www.stereophile.com/content/ps-au...Zb4Lkgz.97

Цитата:The RMS jitter level was 51ps (worst case) and 29ps (best case). The musical signals produced the jitter plots in fig.2, which had RMS jitter values of 66ps (Firebird) and 37ps (Steve Morse). Note how the low-level musical source produced more jitter than the high-level one. The Lambda is representative of a transport with very good S/PDIF jitter performance

50 пик это очень хорошо. 100 пик хорошо. 200 очень посредственно.

Цитата:И заодно подскажите какая величина джиттера у современных ПК, как транспортов цифры.

Да откуда я знаю. Вероятно, конская, раз тысячи страниц посвящены правильной настройке компов.

(11-01-2017 00:42)Гаруспик писал(а):  Если я всяким баранам начну выискывать каждый раз ссылки, подтверждающие мои слова, то у меня времени не хватит.

В отличие от вас, я свои слова аргументирую. Например приводил ссылку из спецификации ЮСБ о асинхронном-изохронном режиме. Если вы не в курсе даже таких элементарных вещей...
И ещё один ваших перлов - щелчок, как маркер битого пакета для редбука.
Я по-умолчанию доверяю людям, если нет причин думать обратное, но тут уж... естественно доверия неподкреплённым ничем вашим высказываниям - ноль. Думаю не у меня одного. Поэтому и прошу подтверждения. Это закономерность - ничего личного.
От вас же в ответ просто просто тупое откровенное хамство.
Игнор.

А я приводил ссылку Graham Slee, вашу я даже не читал сомневаюсь что вы её вообще правильно интерпретировали.
По поводу джиттера и "моих перлов" вопросы отпали?

(10-01-2017 21:19)Kir9790 писал(а):  Прыгающее напряжение (который кабель передаёт ХМОС) в буфере не накопишь . Я ж писал выше об этом.

Почему ? Достаточно перевести это все в другой режим передачи данных, где будет повторная посылка битого пакета в случае несоответствия контрольной суммы, сделать буфер побольше и все, накопили N мегабайт уже проверенного потока и передаем ЦАПу, для таких простых задач мощности тех xmos наверняка хватит... Для прослушки же неважна небольшая пауза, чтобы подгрузилась часть композиции в память усб устройства ? Это изначально косяк усб-аудио, и прямой поток с минимальной задержкой реально нужен только для оцифровки (например, записи с микрофона или музыкального инструмента) и для проигрывания+записи с тех же входов и\или +игры на миди клавиатуре, т.е. студиям звукозаписи, домашним студиям и любителям музыкантам.

Это никакой не косяк т.к. ошибок нет и так. А если и есть, то ничтожное количество.
Ну либо что-то не так и ошибки идут сплошным потоком и это явно слышно.

(10-01-2017 17:11)Kir9790 писал(а):  И ещё интересные слова... что для Windows, в том числе Win 8, генерирует на 12% больше жестких ошибок в системе цифрового звукового потока , чем делает OSX Apple (это к теме о влиянии ОС на звук... в которой я лично тоже убедился в своей системе).

(10-01-2017 23:28)VNV73 писал(а):  В том материале, часть из которого я выкладывал в виде скрина для Стаса несколько страниц назад, писалось, что в асинхронном режиме джиттер в 100 раз меньше, чем в синхронном. Меньше вроде существенно, но всё равно есть.

Цифры, сухие цифры... Вся соль как мы их воспринимаем и экстраполируем. 12%!!! (опять же, грубая ошибка это ХТО?). Допустим, это неустранимая(уже не скорректировать ни каким образом- ни заменой, ни подменой, ни незаметным ".уй с ним и так сойдет". И от чего эти проценты? Скажем OSX Apple сделал 9 ошибок за трек, то Винда 10? Или из 10 пакетов один потерял 9, а другой все? (и нах нам такая "колоссальная" разница в точности?)
в 100 раз меньше, чем в синхронном. Меньше вроде существенно, но всё равно есть.
100 раз!!! Была 1 сек, стало 0,01(маловато! все одно есть!)

Ну и теперь, опять к нашим баранам, сиречь- юсб кабелю.
Комп напортачил с передачей? Или мы уверены, что он (со со своим клоком там, загогулинами...) выдал "чистые ступеньки" - читай не хочу, не ошибешься? Приемник, даже идеальные ступеньки, принял без ошибок, обработал и передал цапу. Цап, в свою очередь, тож не схалтурил и все вновь преобразовал точнехонько? Нее, бедный простой шнурок, с четырьмя жилками, который ничего ни считает, ни преобразует, ни тактируется... - Он! Главный злодей!
Давайте отрубим ему голову и ткнем цап прям в юсб, пусть разъемы за все отдуваются(нет, тогда значит не голову, а как у удава- хвост по самую шею).

urfinjuss66, поддерживаю на все 100. USB соединение уже давно не является узким местом тракта, из приличных кабелей выбрать по цвету и форме разъемов - поставить и забыть. Полно мест, которые существенно и бесспорно влияют на звук гораздо в большей степени, лучше свое драгоценное внимание и средства направить туда.

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

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

(10-01-2017 23:28)VNV73 писал(а):  В том материале, часть из которого я выкладывал в виде скрина для Стаса несколько страниц назад, писалось, что в асинхронном режиме джиттер в 100 раз меньше, чем в синхронном. Меньше вроде существенно, но всё равно есть.

Джиттер есть всегда и везде.
И будет.
В любой электронной цифровой системе.
А вот его влияние - от катастрофического до ничтожного - зависит от его величины в контексте параметров обрабатываемых данных (в нашем случае - от частоты дискретизации и количества разрядов).
В 100 раз меньше или в тысячу - зависит от того, какая элементная база, схемотехника и конструктив применены в данном конкретном устройстве.
В нашем случае - качество тактовых генераторов на "ЦАПовой стороне" асинхронного ЮСБ интрефейса, топология его печатной платы.
Как пример - посмотрите на широкообсуждаемые в соседних ветках катайские платки на ХМОСе - дешевый вариант и типа продвинутый. Отличие только в установленных тактовых генераторах. В дорогом варианте- они большие и золотые . И смысл в этом есть, и прямой. Ну - кроме генератора непосредственно для работы ХМОС - тут китайцы чисто разводят.

---

(11-01-2017 00:28)Kir9790 писал(а):  Уж простите, но похоже на очередную байку из разряда: асинхронный режим не разновидность изохронного.

Давайте немного внесем ясности.
В данном случае изохронность (исходя из значения самого слова) означает, что передача данных по ЮСБ равномерная по времени. Т.е. равномерно "валят" кадры с данными - не буду рыться в спеках- типа - кадр приходит каждую миллисекунду, тысяча кадров в секунду, и этот темп не меняется.
Асинхронность прямого отношения к этому не имеет.
Речь, если попытаться упростить, идет о том, чем тактируется выходной поток данных. Который выходит из нашего ЮСБ интерфейса.
Один способ - синхронный - тактовые импульсы привязываются к частоте следования кадров в самом канале ЮСБ.
Второй - наш случай -асинхронный - тактовым генератором для выходного потока данных есть генератор независимый от частоты следования кадров ЮСБ.
Иными словами - забрасываем в буфер со стороны ЮСБ, и пофиг нам джиттер при этой операции (в разумных пределах). А вот забираем данные из этого буфера уже под управлением наизашибенного тактового генератора, который только можем найти/позволить, джиттер которого непосредственно нам важен, потому как и наш ЦАП работает от этого же генератора.
Джитер снижается пропорционально качеству этого генератора.
На примере китайских ХМОС платок - это два из трех установленных генераторов. Золотые дороже - т.к. качество их выше, джиттер меньше...

(11-01-2017 01:47)Anatoly_A писал(а):  Почему ? Достаточно перевести это все в другой режим передачи данных, где будет повторная посылка битого пакета в случае несоответствия контрольной суммы,

Именно так хотелось бы чтоб было - и все проблемы будут решены (хотя, может появятся другие ). Но повторных отсылок нет, и всё тут. Маємо те, що маємо.

Для этого нужен большой FIFO-буфер перед ЦАПом + специфический драйвер.

(11-01-2017 09:34)urfinjuss66 писал(а):  Давайте отрубим ему (кабелю) голову и ткнем цап прям в юсб, пусть разъемы за все отдуваются(нет, тогда значит не голову, а как у удава- хвост по самую шею).

Дык уже. Уже сделали и делают ). Производители ЮСБ-кабелей... я приводил ссылку, вот выдержка:

Цитата:Стандартные потери в кабеле несколько скруглят форму сигнала и сдвинут его, что приведет к ошибкам и потере данных, изменениям в окраске звука и искажениям. Ущерб легко распознать при сравнении стандартных USB-кабелей и специальных референсных адаптеров, в которых разъемы припаяны непосредственно друг к другу. Создание кабеля, который минимизирует эти потери и отклонения от оригинальной формы сигнала — единственное, что может уменьшить число ошибок. (David Salz, Wireworld)

Верить производителям hi-fi кабелей - себя не уважать.
Если они даже делают аудиофильские ethernet кабели

Повторится в 6 раз насчёт асинхронного-изохронного? Специально кое-для кого...
Есть же стандарт ЮСБ! Universal Serial Bus Specification (Revision 2.0 April 27, 2000)
Не книги, не статьи, не рассуждения и прочие мудрствования, а чёткая Спецификация, в которой чётко и недвусмысленно написано (с. 71-72):

5.12.4 Isochronous Devices
Synchronization type:
− Asynchronous
− Synchronous
− Adaptive

Никакой интерпретации сего двоякой быть не может.

Вот ещё пост (и подобных я неделей ранее приводил несколько), где говорится о том же самом
http://hi-fidelity-forum.com/forum/threa...pid3598548
"Реализованный в современных USB ЦАПах асинхронный режим является, по сути, частным случаем изохронного."

Вообще, чтобы вылечить проблемы юсб, проще от него совсем избавиться

(11-01-2017 12:52)EvgenioZ писал(а):  Вообще, чтобы вылечить проблемы юсб, проще от него совсем избавиться

+1 полно же транспортов по ethernet. Поэтому надо бы пообсуждать влияние ещё и витой пары.

Для пуристов придумали SD... А для остальных распберри + i2s в слейв-режиме....

Eugene Balakin, абсолютно со всем согласен и полностью поддерживаю кроме вот этого умозаключения

(11-01-2017 11:20)Eugene Balakin писал(а):  Иными словами - забрасываем в буфер со стороны ЮСБ, и пофиг нам джиттер при этой операции (в разумных пределах).

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

---

(11-01-2017 12:52)EvgenioZ писал(а):  Вообще, чтобы вылечить проблемы юсб, проще от него совсем избавиться

Дык тоже один из родоначальников асинхронного ЮСБ об этом прямо и чётко заявил!
Не пользуйтесь ЮСБ, от него одни проблемы.

Цитата:Гордон является человеком, который проектировал Ayre QB-9 и Audioquest DragonFly ЦАП, а также протокол USB WaveStream® IsoSynchronous....чтобы воспроизводить аудио с компьютера ....если возможно, держите вашу музыку на Firewire, ESATA или Thunderbolt ездить, а не USB. (перевод)