PolarLight

ЕМНП, Адам как-то ссылался на то, что ему не удалось подружить его DAC NAD M51 с Tiny и оттого он забросил тему Linux. Справедливости ради скажу, что мой NAD M51 охотно дружит со всеми Linux сборками, с которыми я экспериментировал. Сейчас "сижу" на fatboy0712.

Всё понятно. Значит SoC от Intel не катят.

Дмитрий, приветствую, рад слышать! Я, пока, больше для общего развития интересуюсь. Ампир хорошие характеристики на скринах выше демонстрирует, вот и размышляю вслую. Буду рад, если ему удастся довести свои наработки до законченной аудио ARM ОС. Будет с чем сравнить. Хотя, на нынешнем этапе, меня мой аппарат вполне устраивает.

ampir-nnn, в рассматриваемом вопросе важен именно ARM, или можно смотреть на девайс (например планшет ASUS Transformer Mini T103HAF) на х86, для удобства установки нормальной аудио ОС?

ampir-nnn, хочу ещё уточнить для себя. Может действительно попробую вывод с гаджета. Но у планшетов, как правило, только беспроводной вывод. Остаётся брать смартфон и использовать так нелюбимый Вами USB? Или есть/возможны варианты?

Сейчас наверное уже можно на 505 или RME ADI-2 DAC FS.

Возможно, НО с теми темпами, что усложняются ARM процессоры в гонке производителей с их мечтой встрясть в ноутбучный и серверный сегменты, плюс сближение с Windows, в самое ближайшее время мы перестанем видеть разницу между х86 и ARM. Так что время на эксперименты стремительно тает.ИМХО.

А слушать как будем эти гаджеты? Сразу на усилитель сигнал выводить или всёже через внешний DAC?

Игорь, Огромное Вам Спасибо! Всё заработало с первого раза!

Вечером непременно попробую и обязательно отпишусь. У меня fatboy0712, тот, который ещё со старым интерфейсом настроек IRQ.

Игорь, здравствуйте. Тоже столкнулся с подобной проблемой. Решил выполнть Вашу рекомендацию по исправлению, но обратил внимание, что ранее, в инструкции по подготовке запуска в режиме сервиса Вы рекомендовали скопировать файл aplayer.service (aprenderer.service) в папку /etc/systemd/system. Что я и делал. А сейчас рекомендуете искать файл aprenderer.service в папке /etc/systemd/service. Но у меня в fatboy0712 по указанному пути нет папки service. В результате я добавил строку After=network-online.target в файл aprenderer.service находящийся в /etc/systemd/system, что не дало желаемого результата. В качестве DLNA сервера использую JRiver на выделенном компьютере. Спасибо за очередное хорошее обновление. С уваженеием, Юрий.

Игорь, Огромное Вам Спасибо за очередной ликбез. Вы настоящий Друг!!

Игорь, здравствуйте! Порекомендуйте пожалуйста, в каком направлении смотреть. Актуальный рендерер для Linux, PCM output mode. DLNA сервер JRiver. Решил послушать действительно большой трек (свыше 2 ГБ) DSD 256 и столкнулся с тем, что в режиме Full Memory рендерер вылетает в процессе его декодирования даже без включения Full preloading. В режиме Direct Input воспроизведение осуществляется нормально. Объём ОЗУ источника 8 Гиг, в принципе памяти должно хватаь. Кстати, сразу после прослушивания этого трека в режиме Direct Input удавалось запустить его и в Full Memory. Видимо декодированный трек уже весь находился в ОЗУ и не требовал дальнейшей обработки. "Маленький" трек (400+ МБ) из этого же альбома заускается в Full Memory даже с Full preloading. Видимо моя проблема именно в размере файла. Прослушиваемые треки Sasha Cooke DSD 256. Понимаю, что прослушивание таких гипертрофированных файлов больше баловство, но спортивный интерес порой берёт верх над здравым смыслом. С уважением, Юрий.

@ampir-nnn, приветствую! А что, на Ваш взгляд, создаёт эту самую чрезмерную нагрузку на память? В чём она выражается? Как и чем измеряется? Вы любитель минимальных буферов и спокойно относитесь к загрузке ядер на 50+% Возможно проблема в этом? В избыточности генерируемых системой прерываний. У меня же, судя по htop на скрине выше, загрузка ядер практически нулевая. Лишь второе ядро, на котором "сидит" карта USB вывода, грузится её прерыванием на 2%. Возможно при таких общих нагрузках на CPU и ОЗУ, при сетевой загрузке, будет работать в близком к номинальному режиме? Выше, Вы постоянно напоминаете нам, что в Linux ОС хорошо кэшируется и тем самым фактически работает из ОЗУ. В чём, для обсуждаемого вопроса, тогда заключается принципиальная разница между кэшированием в ОЗУ и загрузкой в ОЗУ? ampir-nnn, если можно, попунктно. Коллеги, у кого по моему предположению, есть какие мысли? Спасибо.

На мой взгляд, как я уже как-то писал ранее, реальный профит от загрузки всей ОС в ОЗУ можно получить при сетевой загрузке, за счёт исключения из системы системного диска с его IRQ. На скриншоте выше хорошо видно, что для общения с системной флэшкой, в процессе работы, постоянно генерятся прерывания (IRQ 121), в количестве большем, чем у сетевого адаптера (IRQ 128), что в нашем случае ни есть кошерно. При том, что по сети на источник у меня поступают воспроизводимые треки приличного размера. А системная флэшка, со слов ampir-nnn, в это время должна спокойно отдыхать. Но к сожалению имеем то, что имеем.

Fatboy MPD тоже в процессе работы постоянно обращается к загрузочной флэшке (интересно зачем, если всё уже в кэше), что хорошо видно по имеющемуся на ней светодиоду. Именно поэтому автор и рекомендует ставить Fatboy MPD и иже с ним на SSD, дабы, хоть как-то, ускорить этот процесс. Игорь, добрый вечер.К сожалению проверить Вашу рекомендацию не получилось. Как я уже писал выше, система стартует, ЦАП "подхватывается", но в браузере ни Web-интерфейс, ни окно рендерера запустить не удаётся. По SSH, зайти тоже не удалось. Т.к. источник стоит в стойке, то монитор, для отслеживания процесса загрузки, не подключал. Остановился пока на имеющихся в системе возможностях настройки, благо они позволили достаточно компактно развести потоки по ядрам. Огромное Спасибо за Вашу отзывчивость. От всей души хочу пожелать Вам творческого вдохновения и новых интересных решений! С уважением, Юрий

Игорь, попробовал предложенный Вами вариант. Перезагрузка вроде прошла нормально, ЦАП "подхватился", высветив на экране стартовую частоту. НО в браузере ни рендерер ни Web-интерфейс не запускаются. Допускаю, что это может быть связано с тем, что перед перезагрузкой я не отключил изоляцию 3-го ядра в окне "Настройки CPU & IRQ" Web-интерфейса. Попробую позже и обязательно отпишусь о результатах.

Посмотрел у себя файл /etc/default/grub. Строка GRUB_CMDLINE_LINUX_DEFAULT= имеет параметр "quiet". Замена его на "nomodeset isolcpus=3" приводит к зависанию первоначальной загрузки. От дальнейших экспериментов пока отказался, т.к. задавая изолирование 3-го ядра через форму "Настройки CPU & IRQ" и сравнивая два вышеприведённых скриншота, заметна существенная разница в кол-ве потоков на ядро. Пока остановлюсь на этих настройках. Спасибо за Ваши консультации!

Игорь, огромное Вам Спасибо, за исчерпывающий ответ. Действительно, при наблюдении видно, что из всех присутствующих потоков рендерера, попеременно работают всего два, изредко нагружая процессор на минимальную величину. (За исключением момента первоначальной обработки трека и его загрузке в ОЗУ).

Спасибо, буду знать. На основе Ваших пояснений, внёс изменения в настройки,Кстати, Игорь, если возможно, прокомментируйте пожалуйста ситуацию. Сейчас обратил внимание, что в случае изоляции последнего ядра с рендерером, на этом ядре выполняется значительно меньше процессов чем когда ядро не изолировано. Но даже в первом случае, кроме работающего рендерера, с ним на ядре выполняются и другие процессы. Тоесть рендерер вытесняет не абсолютно все процессы. Моя ситуация нормальная или "картинка" должна быть лучше? И ещё вопрос. Такое большое количество процессов ap2renderer при воспроизведении трека это нормальная ситуация или нет? Спасибо.

Игорь, здравствуйте! К Linux версиям это тоже относится? С уважением, Юрий.

Не во всех ОС. fatboympd например, в процессе работы, достаточно часто обращается к системной флэшке, (видно по работающему светодиоду). Почему автор и рекомендует устанавливать эту ОС на SSD, дабы уменьшить задержки при обращении к системному диску. Друзья, подскажите плиз, как назначить конкретное ядро исключительно под рендерер Album Player?

ampir-nnn, я не про отличия, я в принципе про то, что:- Попытки измерить джиттер в домашних условиях, да еще и на одной звуковой карте с общим генератором для тракта записи и воспроизведения, как правило обречены на провал. - Применение же этих треков для контроля джиттера I2S сигнала, приходящего со звуковой карты на её же ЦАП, практически бессмысленно, поскольку фактически, I2S является полностью синхронным интерфейсом, тактируемым в данном случае одним генератором (на звуковой карте) вместе с ЦАПом, поэтому возникновение ошибок в SRC ЦАПа исключено, хотя фактический джиттер (для стороннего измерителя) может быть сколь угодно большим. REN.

ampir-nnn, Ваш тест не подпадает под условия описанные здесь при использовании одной звуковой карты? Абзацы три и пять.

Об этом я и писал выше, что: