Владимир, а каким именно образом происходит влияние, и можно ли это влияние чем либо сгладить/нивелировать? Имею ввиду на программном уровне на стороне лисенка, а не на принимающей стороне.
Я про это и пишу. Не слышу разницы при нагрузке.
Поэтому и прошу проверить на усб.
и можно ли это влияние чем либо сгладить/нивелировать?
Еще один внимательный читатель ))))))))))
Вот же
Что касается “каким именно образом” - напишу в личку))
Очень просто - не использовать рендереры, которые чрезмерно грузят процессор
Результат сравнения разных рендереров с разными нагрузками процессора — при разных интерфейсах.
USB ведет себя практически так же, как и i2s. Повышенная нагрузка процессора слышна и влияет нехорошо. @aleev
Если еще подробнее, постараюсь понятно изложить.
Для файлов 384, при i2s подключении:
Если на “отрезке качества” за условные 100 взять самое лучшее качество звучания — малая нагрузка процессора (NAA)
А за 0 принять худшее, наибольшую нагрузку, RAAT, то:
USB подключение с малой нагрузкой (NAA) будет условно где-то на 80
USB подключение с большой нагрузкой (RAAT) будет условно где-то на… 20.
Легкий эффект нивелирования разницы нагрузки Xing U30 действительно дает.
При этом сам он чуть-чуть проще прямого подключения i2s. Возможно, первое как раз следствие маскирования вторым (точнее я даже почти уверен).
Здесь i2s идет в ПЛИС и после в два чипа PCM58. Туда же, вместо Лиса, включался Xing.
Xing питался отдельно от всего, блоком SoniQ. Лис – дискретным стабом, переделки его питания на 3.3 я не делал.
ЗЫ. Эффект повышенной нагрузки на процессор в человеческих терминах могу описать как эффект повышенной температуры. Вроде все осознаешь, но в смысловом тумане ![]()
Отдельно хочу заметить, что все описанное достоверно и важно исключительно в случае, если используются паралельные ЦАПы в режиме NOS, без цифровой фильтрации, реклокинга и изоляторов.
Кстати. А из людей с реклокерами, изоляторами, с цифровой фильтрацией и OS, в резиновых перчатках и тапочках и шапочках из фольги) никто не хочет сравнить аналогичные эффекты?
Вот оно - меломания!
Сделать (с)
вот эту цитату надо в рамочку и приколотить в шапке всех тем, а лучше, как баннер в шапке форума. Как однозначное указание всем желающим сделать “лучше, проще, короче”, напихать в эндпоинт картридеры, файловые серверы, плееры, и мощный красивый вэб интерфейс.
А также распознавание образов композиторов, исполнителей и дирижеров. С палочками вместе.
Не надо, и так очевидно, что от дохлого ядра ждать нечего. Даже рун на костылях теперь))
Кому все вышеперечисленное нужно, тот возьмет тинкер.
Рун будем играть через NAA. ![]()
А в случае достаточности 16 бит и напрямую ОК.
Есть ведь еще способ, который вроде никто не проверял - играть через squeezelite. До 192 частота дискретизации поддерживается. Для хайреза больше особо и не надо.
@Oschutimiy Не хотите проверить сколько жрет в таком режиме?
Надо. DSD>PCM это все-таки 352.
Для dsd64 хватит и 192, куда там больше? Все, что выше, пролетает, да. Но жить можно, если тратиться на hqp не хочется.
Неправильный вывод. не в дохлости дело, а в процессах. У меня есть знакомый, который много лет пилит эндпоинт на X86 платформе с мощным процем. И там точно так же, слышно, как лишние процессы влияют на звучание.
Слишком размытое опрелеление слова «лишние». По вашей логике ваш знакомый занимается ерундой. А так же этим занимаются ребята из Антиподс, Мелко и прочие. Но реальность показывает обратное.
Впрочем, в этой теме это оффтоп, тут обсуждается эндпоинт, а не источник.
Конвертация этого формата традиционно кратна 1-ой сетке и по умолчанию Руном например всегда выполняется в 352. Снижать некратно в 192 очень странная затея. А 176 звучит проще, чем 352, возможно за счет лишнего шага вниз.
В целом наверное HQP – решение, да может и хватит про Рун. Все с ним понятно уже.

