Понятно, продолжайте.
Берём истоники:
- большой_комп
- малина
- неттоп
- большой_комп_через_монтор_с_USB_хабом
Слушаем…
Расположил по порядку приятности лично мне звука. Приёмник во всех случаях Amanero.
Последние два варианта очень хороши. Что изменилось? Питание.
Позволю себе припомнить аналогии с пианистом. Он может быть сыт, голоден, пьян, опять же. И это, я думаю, найдёт отражение в манере исполнения. Если не найдёт, то реально великий мастер со стальными нервами и парентеральным питанием.
1 лайк
А на мой вопрос будет ответ?
Все в рамках исходного вопроса — все плееры звучат одинаково.
1 лайк
Чему уступили, если не секрет?
Если обязательное требование - контроль влияния через изменяемый параметр в неких “попугаях”, сразу вспоминается классический J-test. Выполнить его, конечно, можно и с помощью бытового оборудования, но весьма желательна предварительная калибровка для оценки погрешности. Стоит учитывать, что прямой корреляции уровня джиттера (измеряется условно интегральный показатель) и субъективной оценки, как правило, не наблюдается.
2 лайка
В личку получил вопрос, а будет ли так же все гладко с bitperfect если в плеере эквалайзером например поиграться.
Проверил (JRiver + M-DAC через WASAPI). Уменьшение громкости с 100 до 99% (минимальное изменение доступное) и тест не начинается. При начале теста на экране ЦАП выводится Scanning for match, да так и остается в этом состоянии. С 100% громкостью через несколько секунд эта надпись сменяется на Data is accurate (и сохраняется далее 5 минут протяженности трека). Аналогично с эквалайзером. Включение эквалайзера без регулировок - тест успешен. Изменение на 0,5 дБ (минимальное изменение доступное) в одной из полос - тест не стартует.
Помнится на pinkfishmedia в ветках по M-DAC его разработчик участвовал активно. Про тест джиттера отвечал скептически и обещал продукт с тестом джиттера (который не случился). Могу ошибаться (столько времени прошло), но в целом симтоматично выглядит.
В чем разница по приятности была и какого объема?
В основном, повышение гладкости-мягкости подачи при сохранении разрешения. Сильно заметно на состыковке низов с верхами, когда басовые инструменты дополняются высокочастотными составляющими и всё становится одним целым. Количество баса тоже меняется, как ни странно. Тарелки вместо тщщщщ, начинают сыпать как-то более мягко. На примере видеорендеринга, похоже на antialiasing. На слух весьма заметно, как на переключении, так и на долговременном прослушивании.
Я тоже заметил. Жаль что не удается объяснить.
Заговора нет, есть экономика.
Попробуйте найти модели ЦАП с настоящей ассинхронной передачей (bulk).
Даю подсказку, это не все usb цапы. Подавляющее большинство работает в изохронном режиме.
Абсолютно аналогичная ситуация для моделей цап/конвертеров с поддержкой DoP. Любое вмешательство, будь то регулировка громкости, либо что-то ещё, приводит к искажению маркеров DoP и переключению режима приемника в PCM с соответствующей индикацией. Если же это сопровождается щелчками с полной амплитудой (наблюдается у некоторых моделей) - можно попасть на замену твиттеров.
Xivero MusicScope обладает требуемым функционалом. К сожалению, в настоящее время компания прекратила продажу и поддержку программного обеспечения. Однако тестовые файлы с разрядностью 16 и 24 бита по-прежнему доступны и измерения можно выполнить вручную, руководствуясь The Diagnosis and Solution of Jitter-related problems in Digital Audio Systems
Доступ к методичке Audio Precision и APx J-Test (Jitter) Measurement Utility закрыт.
UPD: J-test доступен в ARTA. Ссылка на тестовые треки jtest files
Как правило, для решения проблемы ранжирования/классификации сложных массивов данных, когда вообще непонятно, какую из множества характеристик выбрать в качестве определяющей, привлекается многомерный факторный анализ (метод главных компонент и т.п.). Но тут это совсем оффтоп.
Можно расширить круг подозреваемых, включив в него стримеры, желательно в виде приемников, встраиваемых в цап. Передача в таком случае асинхронная по определению, но, судя по накалу страстей в профильной ветке, автоматическое решение всех проблем это не гарантирует.
1 лайк
Исторически все компьютерные и сетевые протоколы для передачи потокового аудио-видео стриминга никогда не гарантировали 100% восстановление, так как цитата
Изохронный режим позволяет устройству резервировать определенную часть от полосы пропускания с гарантируемым временем ожидания (latency). Это идеально для аудио и видео приложений, где перегрузка канала может привести к заметной потере данных или понижению частоты кадров. Каждый режим передачи предоставляет разработчику компромиссы в области детектирования ошибок и восстановления, гарантированного времени ожидания и полосы пропускания.
Вот и ответ на вопрос - для гарантированного latency мы готовы терпеть часть ошибок.
А как иначе? Представте концерт, где часть музыкантов играет в живую, а часть музыки идет с компа. И вот мы получили битый пакет - стоп, давайте всё остановим, остановим музыку, подождем пока повторно запросим и получим битый пакет и потом снова продолжим игру? @levap, воспроизведение музыки - это не копирование фильма на флешку - скорее процесс реального времени
В случае usb audio термин “асинхронный” относится в большей степени к независимости частотных доменов транспорта и приемника, нежели возможности повторной отправки. Для гражданских применений bit error rate на уровне 10exp-12, то есть проблема битых пакетов скорее умозрительная.
В целом согласен, для soft real-time разработчики предпочитают изохронный режим, однако примеры изделий с использованием Bulk transfer mode, как ни странно, тоже есть:
@birdie, @firewheel, коллеги, остановитесь пожалуйста, ну уж совсем на широкий круг зашли сейчас с самого-самого начала ветки )
Я выше писал, что некоторое время назад уже интересовался темой bulk/изохронная, даже помнится список ЦАПов попадался в сети, о чем выше писало (жаль сейчас не удалось оперативно нагуглить его).
Возвращаясь к проблемах, которые @birdie отмечал, вижу следующее
- про проблемы с передачей данных включая т.ч. тайминг - именно на них в маркетинговом определении “асинхронного USB” направлено решение судя по имеющимся материалам проблема решается в ЦАП с “асинхронным USB”.
- про проблемы с влиянием по электрической части - остается актуальной проблема, причем беда весьма многогранна, судя например по длинной цитате @pm325. Также остается открытым вопрос - насколько велика значимость этой проблемы (точнее, скажем так, кластера проблем), каков объем влияния на итоговый звук.
Но это все уже про ЦАПы, не про тему ветки - аудио-плееры.
Применительно к теме про аудио-плееры еще раз резюме:
- В части передачи данных протестированные плееры одинаковы и одинаково успешны.
- Из потенциальных источников разницы аудио-плееров отмечено только потенциальное влияние различных аудио-плееров на помехи проходящие через электрическое соединение в ЦАП. Каких-либо замеров или методически проведенных результатов прослушиваний, подтверждающих данное влияние, на текущий момент не выявлено.
- Методично проведенных сравнений разных аудиоплееров с подтверждением разницы в звуке не приводится.
Итого в практическом плане
- стоит понимать, что аудио-плееры играют одинаково,
- что впрочем не должно мешать расширять итоговое впечатление от прослушивания внезвуковыми параметрами плееров )
1 лайк
Перефразируя, “хороший индеец - мертвый индеец”, т.е. в идеале в момент воспроизведения должен исполняться некий минимум кода проигрывателя, остальное - задача драйвера.
А в жизни плееры звучат по-разному.
Вот такая фигня. Как не пытайся подвести базу.
Кстати, покажите доказательство, что плееры звучат одинаково. Измерения там какие-нибудь. С подтверждением одинаковости звучания.
6 лайков