Разные свитчи, могу показать известные аудиофильские, которые я слушал в своей системе.
1 лайк
Смотря где и как.
Надо выбирать тот, который показывает хорошие результаты в конкретной системе и кдп
Разные стримеры ведь совсем по разному должны реагировать на очистку ethernet от грязи? И в самих стримерах разве совсем не борются с помехами? Хотя, вполне допускаю, что нет, ибо уровень заморочек тут запредельный, возможно производителям все это видится не нужным.
У меня LogoSD есть, там сеть не влият вообще. А уровень достаточно высокий.
Ну так вот все дельтасигмисты и наращивают фильтрационную мышцу. От безымянного китая до чистой магии. )
Сами микрокомпьютеры не ориентированы на аудио и вообще как таковое D/A преобразование, вокруг которого всё и пляшет. У них базово другие задачи, просто данные передать, 0-1… А стримеры построены на них.
Я про аудиофильские стримеры говорю. Лично мне кажется странным, когда к Aurender, например, нужно ещё паровоз тянуть. Чтобы он заиграл…
2 лайка
Так не надо паровозов никаких тянуть 
Аурендер наверняка играет. Всё играет, в любых условиях. Как-то.
А Roon например очень четко и очень давно сразу заявлял – уберите “нас” из комнаты с аналоговой частью.
Необходим для стримера качественный входной ethernet - стабильный во времени (за это отвечает мал. фазовый шум/джиттер) и с идеальным фронтом сигнала (за это отвечают в частности шумы, качество схем, кабели и прочее). Для этого существуют аудиофильные свитчи, задача которых сформировать такой ethernet и выдать его на вход стримеру.
Легче подавить шумы в зародыше, чем бороться с ними после их возникновения.
Вопрос на сколько они эффективны.
По опыту многих - им (свичам) нужна помощь
Бесспорно верно! Поэтому система сервер/клиент и имеет преимущество изначально.
Опубликую тезисы одного очень грамотного в сетевых делах человека, настоящего энтузиаста, имеющего хорошую аудиосистему, много экспериментирующего и делающего.
1
Как передаются данные при стриминге?
Цифровой поток формируемый из статических данных с исходного носителя легко конвертируется обратно в статические данные без ошибок. По тому что при проверке или считывании фактор времени ни кого не заботит. Hash - тот же, и ладно.
Но, стриминг по протоколу DLNA или RAAT подразумевает работу именно с потоком. Поток представляет собой, конвейер из обрывков исходных данных, перебрасываемых из буфера в буфер (промежуточных полустанков там хватает), а на выходе этого конвейера крутится процесс воспроизведения поступающих обрывков в реальном масштабе времени.
Рассогласование скорости заполнения и опустошения крайнего буфера, рождает самые значительные искажения временнОго характера, которые мы и воспринимаем на слух и обзываем разными не лестными эпитетами, они по сути являются следствием накопленных ошибок на предыдущих участках конвейера, где в аналоговых цепях интерфейсов компараторы отсеивали и перезапрашивали отрывки сигнала в случае наличия ошибок восприятия их формы в следствии влияния помех разного характера, после чего создавали задержку формирования пакетов данных в цифровом домене, от этого рождалась неоднородность самого потока, приводящего к рассогласованию загрузки выходного буфера в стримере.
Далее рождается неоднородность загрузки вычислительного ядра и шины памяти (которая очень много кушает!) соответственно неоднородно нагружает стабилизаторы питания.
И виной всему шум в аналоговом домене, казалось бы цифрового интерфейса.
Правильный компонент сети именно чистит сигнал от налипшего шума, воссоздавая его на своих выходных интерфейсах как можно точнее. Так что бы последующие компараторы на входящем интерфейсе меньше времени тратили на сопоставление сигнала референсу.
2
Цифро-Транспорт высокого конца можно сравнить со звукоснимателем (иглой или магнитной головкой), высокочувствительный инструмент считывания информации в реальном масштабе времени . Для него входящие данные с сервера должны быть максимально точно фрагментированы по времени, за это в значительной степени отвечает сетевая инфраструктура.
Сам транспорт должен быть оптимизирован на обработку входящего потока с упором на реальный масштаб времени. т.е. минимизирована активность процессов не связанных с обработкой потока, промежуточная буферизация отключена, там где это возможно, там где не возможно - количество и размер буферов будет задавать весь характер звучания транспорта. Работа с каждым буфером это выделенный трэд, для систем реального времени на такт процессора трэды исполняются в строго ограниченном количестве. Не успевшие исполнится в своем такте треды переносятся на новый такт. В не RT OS, такты для процесса резиновые, но сути это не меняет.
Получение стабильного качества возможно добиться если зафиксировав частоту работы процессора, подобрать настройки ядра ОС таким образом что бы не происходило перераспределения трэдов между обработкой входящих и выходящих данных. И исполнение тредов обработки для потоков аудио любого разрешения укладывалось в выделенный такт. Переносы рождают всплески нагрузки, вынужденные простои ядер и как следствие разрушение слитности потока на выходном интерфейсе.
Если честно, не могу в принципе себе представить работу стримера и сервера на одной платформе… Распределением ресурсов ОС и процессора для выстраивания на выходном интерфейсе ламинарного потока данных должен заниматься сам Илон Маск) лично.
5 лайков
Из чего следует, что как ни изголяйся все будет зависеть от ОС и софта
Ну так поэтому к примеру Бигль, а не Малиновые. Но влияния пути доставки никак не отменяет.
а какая между ними принципиальная разница ?
Бигль играет с ЮСБ лучше, а устроены одинаково +-
Не верный подход. Пока некоторые ищут аудиофильский грааль, который вот влегкую, раз - и заставит звучать идеально любую аудиосистему, другие исповедуют системный подход ( и я тоже!) , когда все имеет значение и подтягивание всех многих составляющих аудиотракта позволяет подняться над унылым излучением звуков из электро-механических преобразователей, а получить музыкальное событие, тот самый мэджик, который невозможно описать словами. Только софтом это никак не решается.
4 лайка
Устроены кем? Совершенно не одинаково. И софт, мягко говоря, очень очень разный.
Выбор каждого элемента – часть поиска грааля, давайте будем честны. Нет серебряной пули, зачем ее придумывать. Фактически, все делают одно и то же.
АRM проц, обычный линукс, софт у меня одинаковый - Yocto.
Ну да, автомобили тоже обычно 4 колеса имеют ))