Ок. Учту.
Чтобы разбавить ситуацию. Происходящее напоминает известный анекдот )
Купили как-то суровым сибирским лесорубам японскую бензопилу.
Собрались в кружок лесорубы, решили ее испытать.
Завели ее, подсунули ей деревце.
«Вжик» — сказала японская пила.
«У, бля…» — сказали лесорубы.
Подсунули ей деревце потолще. «Вж-ж-жик!» — сказала пила.
«Ух, бля!» — сказали лесорубы.
Подсунули ей толстенный кедр. «ВЖ-Ж-Ж-Ж-Ж-Ж-Ж-ЖИК!!!» — сказала пила.
«Ух ты, бля!!» — сказали лесорубы.
Подсунули ей железный лом. «КРЯК!» — сказала пила.
«Ага, бля!!!» — укоризненно сказали суровые сибирские лесорубы! И ушли рубить лес каменными топорами…
6 лайков
Павел, существует всего четыре варианта развития событий:
- положительный;
- отрицательный;
- ложно-отрицательный;
- ложно-положительный.
Насколько я понимаю, смущает возможность получения варианта #4. Не исключено, что он может быть достигнут лишь узком диапазоне изменения частоты (например, вместо 44100 выставить 44101 Hz).
1 лайк
quote=“pm325, post:51, topic:86077”]
Павел, существует всего четыре варианта развития событий:
- положительный;
- отрицательный;
- ложно-отрицательный;
- ложно-положительный.
Насколько я понимаю, смущает возможность получения варианта #4
[/quote]
Нет, мне не интересен эксперимент т.к. результатом будет 1+4 результат или 2+3 без различия и самое главное выводов надежных ни в одном из исходов нельзя будет делать исходя из результата.
Гораздо интереснее потратить время на то чтобы разбраться с вариантами событий последующей обработки кэша. Базовым подходом видится выбор устройств умеющих действительно асинхронно обрабатывать наполнение кэша и читать из него. Любопытно насколько штатная это фича в современных ЦАПах либо скорее удел продвинутых устройств. Для подобного варианта устройства не принципиален будет вопрос под экспериментом и еще 100500 потенциаьных заморочек с входящим потоком, если исходящий поток действительно асинхронен. (Возможны и свои проблемы в этом подходе безусловно, с задержкой относительно входящего потока например, но это уже другой пласт проблем).
Так можно сколько угодно придумывать. Может плохие подавальщики ещё и пукают оглушительно, аж пианист, бедолага, от испуга дёргается. Не суть.
Суть в том, что “битперфект” то есть кол-во и порядок бит это ещё не все. Помимо этого есть временной фактор и неизвестный нам фактор влияния того или иного софта на работу железа транспорта.
Мне лично кажется, что после достижения условного “битперфекта” влияние софта уже меньше, чем самого железа транспорта. Но это просто мнение, не более того.
Поправка: в условиях данного теста допустимые комбинации несколько иные - либо 1+3, либо 2+4.
Например, сетевой модуль eRED-MODE асинхронный “by design”.
Если же подразумевается режим Bulk Transfer mode, вопрос поднимался около 10 лет назад:
UPD: Adequacy of the Universal Serial Bus for real-time systems (2003)
По теме см. раздел 3.4 Transfer (page 10)
Select your USB audio MCU with care: Scary stories from the test bench
Придумывать стОит аналогии по только рассматриваемым мотивам. Собственно выше была иллюстрация момента, о котором сейчас речь: насколько by design современные ЦАПы вообще подвержены влиянию временного фактора входящего потока.
По поводу мнения “после достижения условного “битперфекта” влияние софта уже меньше, чем самого железа транспорта” - в целом согласен. Но несколько важных моментов:
- Влияние прикладного софта (аудиоплеера) практически нивелируется, ну разве что он криво настроен либо криво использует драйвер.
- А вот системный софт (драйвер USB, если про USB говорим) действует в одной команде с ЦАП и может потенциально влиять на результат.
- Если внутри ЦАП выходной поток действительно асинхронен входящему, вполне достаточно “битперфекта”, временной фактор входящего потока уже не интересен.
Не обязательно bulk, вопрос более общий - как обрабатывается исходящий из буфера поток. Хотя надо отметить, от при bulk режиме USB или допустим при передаче на вход по TCP/IP уже точно квазисинхронной передачи с наследованием временных проблем входного потока не получится )
Когда интересовался темой по режимам USB, помнится находил ресурс с огромной простыней ЦАПов и режимов USB которые они используют. Bulk попадался, но довольно маргинален был. С учетом например текущих результатов теста про bitperfect в целом не удивительно, судя по всему потоковые режимы также достаточно надежно работают.
Легкий утренний гуглинг по теме принес следующее саммари по теме:
- судя по всему утверждение “насколько мне известно, в большом количестве моделей используется просто ФАПЧ” касается работы с SPDIF
- если говорить про USB ситуация судя по всему обратная “The vast majority of DACs these days reclock the data so jitter on the USB signal does not matter.”
- в целом при асинхронной передаче данных нас не беспокоят временные проблемы входного потока “Asynchronous communication is defined as transmission of data without the use of an external clock signal.”
Если несколько упрощенно применительно к топику резюмировать - при использовании современного ЦАПа с компьютером, аудио-плееры играют одинаково, если обеспечивают передачу звуковых данных в ЦАП bitperfect.
1 лайк
Изохронный режим действительно применяется куда чаще по той простой причине, что он гарантирует заданную пропускную способность. Bulk обеспечивает полную асинхронность и повторную передачу битых пакетов, но требует более щадящих условий для аудио приложений, ибо это вотчина soft realtime.
1 лайк
Существует несколько режимов работы связки транспорт-приемник:
Не обязательно только SPDIF.
In a typical synchronous sink endpoint implementation, the source (host) and sink (device) agree on an operation audio sampling rate ( i.e., 48 kHz). Every one millisecond (for Full Speed, at Hi-Speed every 125 microseconds), the USB host sends the SOF signal followed by the agreed number of samples (48). The SOF signal acts as an input to the USB clock generator (typically a PLL), which in turn causes the USB device clock to synchronize with the USB. The USB clock is further used to generate the master clock to the codec through a PLL block that generates the I2S clock.
2 лайка
В принципе Вы все правильно нагуглили. Теперь осталось внимательно посмотреть на устройство usb приемников, качество их клоков и питания от которого зависит стабильность работы этих самых клоков.
На мой взгляд там тихий ужас. Нет, достойные реализации есть, но не так чтобы много.
К сожалению, хорошая теория рушится почти отсутствием практических реализаций. Почему так могу только догадываться. Вероятно накручивать раздельное питание, клоки, развязки выходит довольно накладно и сопоставимо по цене с самим ЦАПом.
3 лайка
Есть еще пара идей на тему поразжигать, если порох останется - подтянусь )
Да разница в звучании софтовых плееров объясняется просто — разный профиль нагрузки на проц/память — разные помехи лезут дальше в аналоговое преобразование.
Выбирайте тот тип искажения, который вам приятен на слух.
6 лайков
Как раз на этот аспект делают упор разработчики нового протокола Diretta при сравнении с UPNP/DLNA/RAAT. Никакой мистики.
Не понял смысла тезиса, если честно ) На мой взгляд все проще гораздо. В описанном режиме на качество итогового звука влияет максимально ЦАП - соответственно в его качество и вкладываемся по максимуму (клоки и т.п.). С точки зрения передачи цифрового сигнала источником м.б. обычный компьютер с плеером обеспечивающим bitperfect (опять же если несколько упрощать).
Есть ссылки со сравнением как-то организованным/систематизированным, желательно слепым?
Хорошо, вложились в ЦАП, а всё равно CD-транспорт звучит лучше, дальше что делаем?
Да хоть глухим 
Вот же положила Are Digital Audio Cables, Protocols, and Interfaces Also Analog? - Audiophile Review
1 лайк