Влияние цифровой передачи на качество

[Milhouse 434]

так все таки dsd-dsd существует, и что у меня всегда dsd over PCM? Зачем тогда галочка есть для DSD3/6 via DoP? Что это значит тогда у меня в софте?

В каком софте?

DSD over PCM - это прямая передача DSD данных от источника и до цапа, только для промежуточных компонентов которые "не в теме" про DSD, этот сигнал выглядит как PCM. К некоторым DSD цапам прилагаются драйверы ASIO 2.1 для Windows - они отправляют неконвертированный и "незапакованный" сигнал через USB - но это специфика устройств поддерживающих ASIO 2.1 и операционки Windows (на OS X, IOS и Linux имплементация ASIO встречается редко).

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

Изменено 11 сентября, 2015 пользователем Milhouse

[whiteeagle 7 459]

Если даже цап читает карту памяти через USB bus, то и там используется file protocol - так что всё bit perfect, потерь никаких. Осталось только найти DSD цап с USB или SD - HD-DAC1, например. ))

Направление теперь ясно)))

 

Опасная тема конечно вышла. Столько можно всего сломать, аж муражки))

[Alecs102 28]

Наверно стоит разделить на несколько причин и типов соединений.

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

По Spidf, в отличие от USB, из сигнала востанавливаеться тактовая частота по котрой осушествляется преобразование в цап. По этому важна стабильность фронтов сигнала и минимум их дрожания (джитера). Упираеться сразу во много причин, качество приемника и передатчика, качество развязывающих трансформаторов, волновое сопротивление кабеля, качество кабеля (резонансы и переотражения в нем). Есть девайсы которые принимают сигнал по Spidf но тактируются от внутрених генераторов, 1) ресемплируют в свою, обычно некратную частоту, 2) подгоняют частоту и фазу генератора к входной частоте принимаемого сигнала, 3) набирают данные в определеный буфер, при переполнении выкидывают определеный семпл или добавляют при опустошении. У меня есть вариант 1 и 3, нравиться 3, но некоторое влияние кабелей имееться тоже, что скорей связано с ВЧ помехами.

По мне потеря данных при передаче возможна только в крайнем случае. Наверно больше влияют ВЧ помехи с компа, дрожание фронтов сигнала по Spidf, качество генераторов в USB конвекторах, помехозащищеность самих девайсов.

[whiteeagle 7 459]

@Alecs102, Интересно, спасибо. А какого уровня у вас кабели, какой ценовой ниши?

[KOV 143]

так все таки dsd-dsd существует, и что у меня всегда dsd over PCM? Зачем тогда галочка есть для DSD3/6 via DoP? Что это значит тогда у меня в софте?

В каком софте?

DSD over PCM - это прямая передача DSD данных от источника и до цапа, только для промежуточных компонентов которые "не в теме" про DSD, этот сигнал выглядит как PCM. К некоторым DSD цапам прилагаются драйверы ASIO 2.1 для Windows - они отправляют неконвертированный и "незапакованный" сигнал через USB - но это специфика устройств поддерживающих ASIO 2.1 и операционки Windows (на OS X, IOS и Linux имплементация ASIO встречается редко).

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

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

Изменено 12 сентября, 2015 пользователем KOV

[Milhouse 434]

это онки плеер на андроид, но такое у него и на винде есть, оппа этот плеер рекомендует как базовый...

Теперь понятно откуда ноги растут.

Onkyo HF player на андроиде (если в kernel есть поддержка OTG) может напрямую отправлять на цап PCM до 192/24 и DSD в режиме DoP. И только DoP.

Изменено 12 сентября, 2015 пользователем Milhouse

[Urez 2 503]

так все таки dsd-dsd существует, и что у меня всегда dsd over PCM? Зачем тогда галочка есть для DSD3/6 via DoP? Что это значит тогда у меня в софте?

В каком софте?

DSD over PCM - это прямая передача DSD данных от источника и до цапа, только для промежуточных компонентов которые "не в теме" про DSD, этот сигнал выглядит как PCM. К некоторым DSD цапам прилагаются драйверы ASIO 2.1 для Windows - они отправляют неконвертированный и "незапакованный" сигнал через USB - но это специфика устройств поддерживающих ASIO 2.1 и операционки Windows (на OS X, IOS и Linux имплементация ASIO встречается редко).

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

Ну я и говорю архаичный костыль для тех контор, кого жаба душила обновить (в общем-то уже смешно доступное по цене) железо и отбашлять % лицензиару на подпись своих дров. Нормальные конторы(перечислю на лету по памяти: msb, exasound, w4s, audiobyte...да даже "бюджетный" тик 501) давно это сделали со своими плис'инами и свистками, спокойно прут(внимание, через usb 2.0) вплоть до 512 dsd в native режиме через ASIO.

Слов нет, есть конечно маргиналы в чьем железе и возможностях странно сомневаться, типа meithner, кто забил на это болт. Ну этим конторам до удобств клиента и его "хотелок" всегда было похер, мягко говоря... Со временем снизойдут и допилят даже не трубя об этом с новых партий-ревизий.

 

[Milhouse 434]

да даже "бюджетный" тик 501) давно это сделали со своими плис'инами и свистками

На Windows - да. На OS X и IOS поддерживается только DoP.

[KOV 143]

это онки плеер на андроид, но такое у него и на винде есть, оппа этот плеер рекомендует как базовый...

Теперь понятно откуда ноги растут.

Onkyo HF player на андроиде (если в kernel есть поддержка OTG) может напрямую отправлять на цап PCM до 192/24 и DSD в режиме DoP. И только DoP.

они через свой драйвер звук выводят, для самса натив не работает в оси. В айфоне не знаю Изменено 12 сентября, 2015 пользователем KOV

[Urez 2 503]

да даже "бюджетный" тик 501) давно это сделали со своими плис'инами и свистками

На Windows - да. На OS X и IOS поддерживается только DoP.

представить трудно как мне с этим дальше жить...

[Milhouse 434]

они через свой драйвер звук выводят, для самса натив не работает в оси. В айфоне не знаю

"Свой" драйвер от Onkyo на Андроиде всё равно требует как минимум поддержки OTG в базовой операционке, иначе они даже свои собственные цапы не видят.

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

 

Опция включения DSD в HF Player делает апконверсию материала PCM в DSD с последующей пересылкой через DoP на цап. Ест батарею в момент.

[KOV 143]

Идея понятно, в тех. Поддержку напишу, батарея ну не знаю нормально вроде

[Alecs102 28]

@Alecs102, Интересно, спасибо. А какого уровня у вас кабели, какой ценовой ниши?

Цифровые,по Spidf, Neotech NEVD-2001, по USB, DX Lab USB. Ценовая категория в общем средняя, но если нет сильных косяков в девайсах, мне кажеться, достаточная.

[whiteeagle 7 459]

@Alecs102, Интересно, спасибо. А какого уровня у вас кабели, какой ценовой ниши?

Цифровые,по Spidf, Neotech NEVD-2001, по USB, DX Lab USB. Ценовая категория в общем средняя, но если нет сильных косяков в девайсах, мне кажеться, достаточная.

 

Спасибо.

[KOV 143]

они через свой драйвер звук выводят, для самса натив не работает в оси. В айфоне не знаю

"Свой" драйвер от Onkyo на Андроиде всё равно требует как минимум поддержки OTG в базовой операционке, иначе они даже свои собственные цапы не видят.

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

 

Опция включения DSD в HF Player делает апконверсию материала PCM в DSD с последующей пересылкой через DoP на цап. Ест батарею в момент.

да в андроиде DoP, печалька, почему тот же ACIO не реализовать? Ведь поддержка есть на PC...

[whiteeagle 7 459]

да в андроиде DoP, печалька, почему тот же ACIO не реализовать? Ведь поддержка есть на PC...

 

Да, те же мысли по поводу андроида..

Изменено 12 сентября, 2015 пользователем whiteeagle

[KOV 143]

Я просто поэксперментировал и на айоси и на андроид, они все кидают через dop, поддержка dsd256 только пока для ifi все остальное через комп. Попытался вступить в активную переписку с сапортом по поводу поддержки asio, но думаю отмажуться... Но для себя одназначно решил все закидывать по dsd128, звук по сцене становиться лучше и детальней, особенно низы начинают более выразительно передаваться...

 

Я понимаю теперь почему многие плеерам отдают предпочтения и считают что там цапы лучше) они просто не кормят правильно внешние цапы...

[Pipha 305 3 Тракты]

Разговаривая о цифре, мы все время забываем, что... цифры нет Как "Ложки нет", в известном фильме. И все равно все сводится к старому-доброму перемещению электрического сигнала по токопроводящим проводникам (ОК, для простоты вычеркнул отсюда оптический Toslink - но для всего остального это справедливо).

 

Отсюда и все "различия". При воспроизведении музыки нет времени бесконечно пере-запрашивать семплы, исключая вредное влияние паразитных электических сигналов (не важно, какой они природы). Добавьте сюда требования к эл. параметрам, скажем, USB кабеля (емкость, волновое сопротивление) и их разброс у "абы-как" сляпанных - и вот вам уже не эзотерика, а вполне себе физически объяснимые явления.

 

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

 

На то она и цифра - электрически ошибка в уровне при передачи может быть довольно велика пока начинается физическая потеря данных. Есть диапазон напряжений пока это всё ещё единица - и из этого коридора нужно ещё постараться выйти. Если при воспроизведении музыки есть возможность один раз запросить повторно (а скорости usb более чем хватает), то это уже более чем достаточно. Конечно есть вероятность что ошибка появится повторно - но это уже такая малая вероятность, что жизни может не хватить чтобы это событие встретить (и так далее с экспоненциальным {более строго говоря - в геометрической прогрессии} убыванием вероятности - причем с диким показателем экспоненты). И опять же скорости юсб хватит. И даже если чудо случилось - раз в жизни - ты вы попробуйте заметьте, что где-то точечно (в одном месте) был интерполирован сигнал. И, опять-таки, даже если бы я был уверен, что способен заметить, то раз в жизни небольшая фальшь - это ничто по сравнению разницей в качестве звучания для разной аппаратуры, время от времени встречающимися проблемами с щелчками просто при настройке ПО (а также перегрузке процессора/сети и пр.).

 

Далее, согласно материалу который я перебирал, даже синхронное USB уже устраняет проблему джиттера на промежуточных этапах, то есть в принципе на порядок лучше spdif. А асинхронное ещё и позволяет корректировать ошибки (будь они хоть и крайне маловероятны) - после того как мы знакомы с практически безупречными на слух системами на spdif нам дарят ещё два порядка надежности (!). Другое дело, что есть некий рынок устройств, различная распространенность интерфейсов, исторические факторы - что может приводить к тому, очевидно, что мягко говоря есть spdif устройства выше классом чем USB - например, банально аналоговая выходная часть лучше. Но это (что надеюсь также очевидно) факт не доказывающий и не опровергающая изложенные факты относительно архитектур. Грубо говоря, это ещё одно наблюдение (причем неоднозначное) - которое будучи в такой общей форме изложенным носит гораздо более теоретический (т.е. в частности оторванный от реальности) характер. Например потому, что легко подрать для сравнения как пары устройств usb vs spdif где выигрывает компонента с первой реализацией - так и противоположный случай. [см. также usb class 1/2 - ж)]

 

Безусловно помехи могут просачиваться через кабеля а также наводиться на них - и таким образом как-то влиять на сигнал. Но вкладывать большие деньги в usb кабеля ради помехоподавление - считаю крайне неразумным - есть более перспективные пути борьбы с этими проблемами и более разумные способы потратить средства.

 

Наконец, вообще говоря jitter в spdif и подобных сигналах тоже устраняем. Единица в ноль не превратится (опять-таки перещелкнуть уровень, утрируя, это нужно совсем драный кабель постараться использовать а вокруг сотовыми обложиться), а фронт можно вернуть на место. Сам немного экспериментировал на FPGA с похожими алгоритмами, не говоря о том, что куча устройств заявляют, что у в них есть какие-то решения для устранения джиттера. Кстати, те же MS Audio Laboratory про свои DAC'и утверждали, что они практически не чувствительны к качеству цифры.

 

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

Изменено 12 сентября, 2015 пользователем Pipha

[Pipha 305 3 Тракты]

Кстати, вот про asio - в частности, в википедии:

 

"Сфера применения данного аудиоинтерфейса, как правило, ограничивается Microsoft Windows, так как в других операционных системах (например, в Mac OS X или Linux) отсутствуют подобные проблемы с задержками и микшированием (см. Core Audio и ALSA). ... . В 2007 году создан экспериментальный ASIO драйвер для WINE — wineasio, использующий звуковой сервер JACK, и позволяющий многим ASIO-приложениям работать с низкой задержкой под WINE" - вот вам и повод говорить про исключения - которые опять таки без windows не появляются - ж).

 

соответственно в частности ASIO для андроид опять таки превращается в "овцеводство антарктиды". так что (получается же!) в не-windows системах даже если где-то какой-то аналог ASIO может быть сколько-нибудь осмысленно воткнуть (что для меня далеко не очевидно), то понятно, что технология будет совсем другая (так что полагаю ни о каком массовом повторном использовании исходного когда составляющих ASIO процедур в других ОС речь идти не может).

[KOV 143]

Тогда почему передачу асинхронную на компе без проблем реализовали, а в виде драйвера f на андроиде нет, на сколько я понимаю реализовать им это никто не мешает и не мешал, но пошли на совместимость с USB Audio?

[Pipha 305 3 Тракты]

Тогда почему передачу асинхронную на компе без проблем реализовали, а в виде драйвера f на андроиде нет, на сколько я понимаю реализовать им это никто не мешает и не мешал, но пошли на совместимость с USB Audio?

 

посольку андроид для меня с точки зрения подключения ЦАПа не слишком интересен (зачем?) - лишних деталей не знаю. Не разбирался с резализацией асинхронного USB - есть она или нет. Не особо интересуют детали истории поддержки разных классов USB Audio на Андроиде. Но это не меняет того, что было сказано выше.

[whiteeagle 7 459]

Разговаривая о цифре, мы все время забываем, что... цифры нет Как "Ложки нет", в известном фильме. И все равно все сводится к старому-доброму перемещению электрического сигнала по токопроводящим проводникам (ОК, для простоты вычеркнул отсюда оптический Toslink - но для всего остального это справедливо).

 

Отсюда и все "различия". При воспроизведении музыки нет времени бесконечно пере-запрашивать семплы, исключая вредное влияние паразитных электических сигналов (не важно, какой они природы). Добавьте сюда требования к эл. параметрам, скажем, USB кабеля (емкость, волновое сопротивление) и их разброс у "абы-как" сляпанных - и вот вам уже не эзотерика, а вполне себе физически объяснимые явления.

 

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

 

На то она и цифра - электрически ошибка в уровне при передачи может быть довольно велика пока начинается физическая потеря данных. Есть диапазон напряжений пока это всё ещё единица - и из этого коридора нужно ещё постараться выйти. Если при воспроизведении музыки есть возможность один раз запросить повторно (а скорости usb более чем хватает), то это уже более чем достаточно. Конечно есть вероятность что ошибка появится повторно - но это уже такая малая вероятность, что жизни может не хватить чтобы это событие встретить (и так далее с экспоненциальным {более строго говоря - в геометрической прогрессии} убыванием вероятности - причем с диким показателем экспоненты). И опять же скорости юсб хватит. И даже если чудо случилось - раз в жизни - ты вы попробуйте заметьте, что где-то точечно (в одном месте) был интерполирован сигнал. И, опять-таки, даже если бы я был уверен, что способен заметить, то раз в жизни небольшая фальшь - это ничто по сравнению разницей в качестве звучания для разной аппаратуры, время от времени встречающимися проблемами с щелчками просто при настройке ПО (а также перегрузке процессора/сети и пр.).

 

Далее, согласно материалу который я перебирал, даже синхронное USB уже устраняет проблему джиттера на промежуточных этапах, то есть в принципе на порядок лучше spdif. А асинхронное ещё и позволяет корректировать ошибки (будь они хоть и крайне маловероятны) - после того как мы знакомы с практически безупречными на слух системами на spdif нам дарят ещё два порядка надежности (!). Другое дело, что есть некий рынок устройств, различная распространенность интерфейсов, исторические факторы - что может приводить к тому, очевидно, что мягко говоря есть spdif устройства выше классом чем USB - например, банально аналоговая выходная часть лучше. Но это (что надеюсь также очевидно) факт не доказывающий и не опровергающая изложенные факты относительно архитектур. Грубо говоря, это ещё одно наблюдение (причем неоднозначное) - которое будучи в такой общей форме изложенным носит гораздо более теоретический (т.е. в частности оторванный от реальности) характер. Например потому, что легко подрать для сравнения как пары устройств usb vs spdif где выигрывает компонента с первой реализацией - так и противоположный случай. [см. также usb class 1/2 - ж)]

 

Безусловно помехи могут просачиваться через кабеля а также наводиться на них - и таким образом как-то влиять на сигнал. Но вкладывать большие деньги в usb кабеля ради помехоподавление - считаю крайне неразумным - есть более перспективные пути борьбы с этими проблемами и более разумные способы потратить средства.

 

Наконец, вообще говоря jitter в spdif и подобных сигналах тоже устраняем. Единица в ноль не превратится (опять-таки перещелкнуть уровень, утрируя, это нужно совсем драный кабель постараться использовать а вокруг сотовыми обложиться), а фронт можно вернуть на место. Сам немного экспериментировал на FPGA с похожими алгоритмами, не говоря о том, что куча устройств заявляют, что у в них есть какие-то решения для устранения джиттера. Кстати, те же MS Audio Laboratory про свои DAC'и утверждали, что они практически не чувствительны к качеству цифры.

 

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

 

Спасибо, очень интересные наблюдения!

[Ганс 59]

В продолжение темы: я тут столкнулся с еще одной особенностью реализации цапов, как уже писал Выше на-2 очень хорошо реагирует на апсемплинг в dsd, а оказывается ifi этого апсемплинга не переваривает, звук становиться хуже, хотя на апсемплинг PCM реагирует положительно, родной dsd файл вопроизводиться одинаково хорошо на обоих цапах, вот такая особенность...