Ну как не портит, не зря же режимы Рун онли есть и таже РОК руновская из которой выпилили не нужные процессы, здесь так же, любое украшательство это процесс. А выравнять в цифровом домене на уровне потока и получить уже нужный на входе в цап намного умней.
1 лайк
Почему тогда файлы с диска ( с визуализацией ) и те же файлы со стриминга ( без визуализации ) в ROON звучат одинаково?
Со стриминга не файлы, а поток. Это две больших разницы. И если оно звучит одинаково, значит какой-то компонент в системе сильно всё причёсывает под себя.
2 лайка
А файлы это в итоге не поток, а… что? :-)))
1 лайк
Файл становится потоком в плеере.
При стриминге поток принимается и кэшируется плеером – это еще условно файловая структура. Никто не гонит же насквозь PCM-поток в ЦАП.
Но даже если какой-то сервис льет PCM-поток, что это меняет для входа в ЦАП? В обоих случаях на входе поток со стороны плеера. Если его не сломали по дороге - какая разница? При учете, конечно же, мостов и вот этих “всех тяжких”.
1 лайк
Для цапа никакой разницы, для стримера разница. А то, так можно договорится, что все стримеры звучат одинаково.
Нет, так мы не договаривались 
Ну и опять же, стример стримеру рознь и тамбовский волк. Разделяем же функционал и расположение?
Давайте для простоты вернемся в тему Roon. Какая разница, откуда транслируется исходник, выливающися в удаленный end-point по RAAT? Если они при этом были идентичны (что вообще наверное большая редкость ))))
1 лайк
Легко сделать эксперимент, взять файлы с Qobuz (к примеру), разместить их на диске. И потом попробовать поочередно запустить через roon стрим с сети и с диска что сохранили. Гипотетически исходники должны быть одинаковы. Останется только услышать/нет разницу
1 лайк
в рун это тоже файлы. Со стриминга рун качает текущий и следующий трек на диск, и отдает на endpoint уже с диска, игнорируя стриминг. Можно даже отключить интернет пока играется текущий и следующий трек - все продолжит работать
файлы анализируются заранее, и сохраняются в базе рун - это делается при добавлении файлов в медиатеку
Я пробовал. Файл чуть вкуснее у меня звучит.
Вот тут находится ошибка. Не всегда будет так. Например, если выбрать для воспроизведения только один трек, а не плейлист, то ни roon, ни удалённый сервис не будут знать какой трек будет вторым и будет ли он вообще.
Недавно была информация, что стриминги не разрешали Aurender кешировать свои потоки, что бы не добывали их из кеша. Не знаю как с этим у roon.
Ну и про разницу. Считывание и воспроизведение плеером файла и это же плюс одновременное кеширование - это всё же разные процессы, отсюда я и вижу разницу. Точно так же, как забрать файл с NAS по самбе или получить поток NAA с сетевого сервера HQP.
Если она есть и влияет на итоговую выдачу данных в поток в сторону конечной, то Roon давно бы закопали.
ну можно изобретать edge-кейсы.
а можно посмотреть статистику кто как слушает.
большинство тех кто слушает имеет плейлист. слушает альбом или список.
даже если мы слушаем один трек, он в начале скачивается на диск, потом играет. Это четко видно по исходникам.
Да даже и без них - можно зайти на машину с Roon-server и посмотреть когда и что и куда пишется на диск.
т.е. технически это разные потоки - тот кто подкачивает на диск следующий трек, и тот кто воспроизводит.
Да - они грузят общий ЦПУ/память итд. В этом и разница с проигрыванием напрямую с диска. Но это не “поток” - который real-time идет из сети, у рун чуть хитрее.
Поток - всегда - с диска на end-point.
разница кто-то в параллель на диск подгружает, или же играют статичные файлы
я про эти процессы и писал
Давайте только сразу исключим ситуацию “ЦАП воткнут прямо в Roon-сервер” Иначе там каждый взмах любого крыла любого процесса выльется в …
1 лайк
я такую ситуацию никогда и не рассматриваю. Сторонник систем сервер/эндпоинт.
А про нагрузку тест-то еще проще, без “скачивания” треков кобуза.
Выключаем Background Work в Off.
Берем диск, размещаем на нем сколько-то альбомов (скажем, сотню). Включаем его в сервер. Когда все альбомы добавились, включаем и слушаем музыку, — и потом включаем настройку Fast и выше в On-demand - unscheduled и на все ядра. Сервер начинает “взлетать”, всеми силами высчитывая анализ треков для вейвформ прямо сейчас.
В норме доставляемый поток raat и соответственно играемая в этом режиме музыка не должна никак страдать на слух. Разумеется, сервер унесен от системы как можно дальше. На другой этаж, в идеале, чтобы не слушать результат помех конкретного железа в сеть (обе – и силовую, и ethernet).
1 лайк
Ну вот, если есть генерация шумов в питание и в сеть данных, то есть и в самого себя. Дёрганные данные это джитер, как минимум.
Генерация шумов опасна аналоговой системе (конечной и ЦАП). А генерация “в самого себя” и джиттер в мультикаст-поток… это как?
Если бы он возникал там, то абсолютно каждая железяка в виде Рун-сервера имела бы совершенно свой уникальный, приятно неповторимый характер звучания, и … mission failed.
Кстати. То, что нельзя называть, считает, что RAAT это всё еще данные…