Почему сетевой источник Сервер–Клиент лучше?
Система, которая делает десяток операций: считывание с носителя; конвертация; апсемплинг/даунсэмплинг; управление точкой доступа; софтовый плеер и др. никогда не будет так же хороша, как чистый эндпоинт в компонентной системе сервер-клиент. Все эти операции нагружают процессор, увеличивают потребление питания, оказывают негативное влияние на главную функцию - звук.
Чистый эндпоинт делает только одну операцию - принимает поток аудио данных по эзернет и отдаёт его на цап в цифровом аудио формате. Весь остальной процессинг выполняется внешним мощным сервером.
Если, в бюджетных аппаратах, такой мульти функционал допустим, как компромисс и конъюнктурный ответ производителей на желание потребителя иметь всё сразу и занедорога, то в хайэнд сетапах должна быть только система сервер-клиент!
Кстати, если сетевой стример "всё-в-одном" разгрузить от функций, перенести их на внешний сервер, то звучание от этого явно выиграет.
Зачем нужно фильтровать шум, помехи в ethernet сетях.
Сначала давайте выясним, откуда этот шум и помехи берутся. Дело в том, что, контроллеры ethernet генерируют очень мощные шумы и помехи, потому что им нужно накачать мощный сигнал в длинную линию, ведь по стандартам, длина ethernet кабеля может достигать сотню метров. Что бы, в таком кабеле сигнал не затухал, вкачивать нужно с большой мощностью. Побочным результатом такой большой мощности является довольно широкий спектр генерируемых помех, причем обладающие еще и большой амплитудой.
больше в локальной сети сетевых устройств, тем больше суммарный спектр помех в сети. Все эти помехи, по поверхности проводников ethernet кабеля легко проникают в сетевой стример, плеер. Важно понимать, что все эти помехи не подмешивается в цифровой сигнал эзернет протокола, а существуют независимо от него. Они попадают в стример, из него в цап и далее в аналоговые компоненты системы. И в каждом компоненте они оказывают негативное действие на звук системы.
Все устройства, работающие по езернет генерят помехи не только в свой интерфейс, но и в питание. Поэтому, необходимо принимать меры по изоляции всех компонентов аудио системы по питанию от сетевых девайсов. Применение дополнительных сетевых фильтров для свитчей, роутеров, нас и серверов – обязательно.
Как передаются данные при стриминге?
Цифровой поток формируемый из статических данных с исходного носителя легко конвертируется обратно в статические данные без ошибок. По тому что при проверке или считывании фактор времени ни кого не заботит. Hash - тот же, и ладно.
Но, стриминг по протоколу DLNA или RAAT подразумевает работу именно с потоком. Поток представляет собой, конвейер из обрывков исходных данных, перебрасываемых из буфера в буфер (промежуточных полустанков там хватает), а на выходе этого конвейера крутится процесс воспроизведения поступающих обрывков в реальном масштабе времени.
Рассогласование скорости заполнения и опустошения крайнего буфера, рождает самые значительные искажения временнОго характера, которые мы и воспринимаем на слух и обзываем разными не лестными эпитетами, они по сути являются следствием накопленных ошибок на предыдущих участках конвейера, где в аналоговых цепях интерфейсов компараторы отсеивали и переспрашивали отрывки сигнала в случае наличия ошибок восприятия их формы в следствии влияния помех разного характера, после чего создавали задержку формирования пакетов данных в цифровом домене, от этого рождалась неоднородность самого потока, приводящего к рассогласованию загрузки выходного буфера в стримере.
Далее рождается неоднородность загрузки вычислительного ядра и шины памяти (которая очень много кушает!) соответственно неоднородно нагружает стабилизаторы питания.
И виной всему шум в аналоговом домене, казалось бы цифрового интерфейса.
Правильный компонент сети именно чистит сигнал от налипшего шума, воссоздавая его на своих выходных интерфейсах как можно точнее. Так что бы последующие компараторы на входящем интерфейсе меньше времени тратили на сопоставление сигнала референсу.
Цифро-Транспорт высокого конца можно сравнить со звукоснимателем (иглой или магнитной головкой), высокочувствительный инструмент считывания информации в реальном масштабе времени. Для него входящие данные с сервера должны быть максимально точно фрагментированы по времени, за это в значительной степени отвечает сетевая инфраструктура.
Сам транспорт должен быть оптимизирован на обработку входящего потока с упором на реальный масштаб времени. т.е. минимизирована активность процессов не связанных с обработкой потока, промежуточная буферизация отключена, там где это возможно, там где не возможно - количество и размер буферов будет задавать весь характер звучания транспорта. Работа с каждым буфером это выделенный трэд, для систем реального времени на такт процессора трэды исполняются в строго ограниченном количестве. Не успевшие исполнится в своем такте треды переносятся на новый такт. В не RT OS, такты для процесса резиновые, но сути это не меняет.
Получение стабильного качества возможно добиться если зафиксировав частоту работы процессора, подобрать настройки ядра ОС таким образом что бы не происходило перераспределения трэдов между обработкой входящих и выходящих данных. И исполнение тредов обработки для потоков аудио любого разрешения укладывалось в выделенный такт. Переносы рождают всплески нагрузки, вынужденные простои ядер и как следствие разрушение слитности потока на выходном интерфейсе.
Если честно, не могу в принципе себе представить работу стримера и сервера на одной платформе... Распределением ресурсов ОС и процессора для выстраивания на выходном интерфейсе ламинарного потока данных должен заниматься сам Илон Маск) лично.
