Album Player и другие продукты от Игоря Антонова. Делимся опытом

В процессе тестирования драйвера ScreamALSA на Raspberry Pi 2 с системой piCoreAP 11 выявилась чувствительность драйвера к загрузке системы на слабом железе, приводящая к нарушениям синхронизации.

В результате работы над этой проблемой архитектура драйвера была полностью переработана и новый его вариант версии 2.0 улучшен во всех отношениях:
повышена стабильность работы и точность синхронизации, снижена вычислительная нагрузка, сняты ограничения на размер периода драйвера (с Audirvana должен быть совместим).

Драйвер ScreamALSA обновлен на версию 2.0 на github, в архиве на сайте и в образах систем piCoreAP 32/64 и YoctoAP для PC 64, Odroid C2, Paspberry Pi 4/5, ASUS Tinker Board 2, Nanopi Neo 3.

12 лайков

Здравствуйте, Игорь!

Огромное Вам Спасибо за очередное обновление. Поясните пожалуйста назначение параметров добавленных в файл /usr/scream/config.txt

P.S. Перезалив флешку и послушав сложилось мнение что при прочих равных (настройках) заметно увеличились периоды переходов на очередной трек. Посмотрел, действительно. По завершению воспроизведения трека добавляется порядка 9 сек. тишины. Может быть такое, или у меня что-то сбилось?

Спойлер

В плеере ситуация аналогична

Спойлер

Зато выявил закономерность. Задержка возникает при воспроизведении треков по сети с DLNA\UPnP сервера. При воспроизведении с SD карты задержки нет. Осталось понять, что в сети стало давать эту фиксированную по времени задержку.

При перемотке на сл. трек задержка не возникает.

1 лайк

LOCK_CORE захватывает последнее ядро процессора.
PRIORITY и NICE аналогичны настройкам плеера и рендерера на вкладке System. NICE повышает приоритет в минус до -20. PRIORITY - задаёт повышенный приоритет при значениях больше 0, до 99. Когда Priority не 0, NICE игнорируется.

Логика управления рендерером давно не менялась.
Такое поведение с “коробочными” настройками?

2 лайка

Это для сервера или ресивера?

Это для сервера.

1 лайк

Игорь, а можно подробнее поведение этой настройки описать? На 4-6ти ядерных процессорах все понятно: одно ядро (применена настройка single core в интерфейсе плеера) плеер возьмет для себя, еще одно ядро (??) монопольно выделится для LOCK_CORE. Оставшиеся ядра обслуживают систему. Или уже в этом описании я что то напутал? А как процессы плеера и CORE будут делить ядра на двухядерном ЦП?

1 лайк

Это актуально если сервер мощный, а приемник слабый, но должен переварить 8 каналов?

LOCK_CORE и Single Core - одно и то же. Всегда захватывается последнее ядро. Делится в режиме разделения времени.

2 лайка

Актуально, поскольку в новом варианте не залочен период драйвера, что облегчает режим работы для сервера.

2 лайка

Не совсем. Но с давно применяемыми.

Перезагрузил всех участников тракта, перезалил флешку, настроил только звуковую карту (ScreamALSA) и всё стало работать правильно. Буду пошагово возвращаться к прежним настройкам и наблюдать.

1 лайк

Удалось выяснить, что в моём случае, добавление 10 сек. тишины в конце каждого трека инициирует внешне безобидное отключение Gapless mode. И наоборот, обратное включение Gapless mode снимает проблему. На прежней версии ScreamALSA данного конфликта небыло.

Игорь, если будет время, попробуйте пожалуйста смоделировать описанную ситуацию. Спасибо.

1 лайк

Юрий, мне один раз удалось воспроизвести такой эффект, но при следующих попытках задержки не было. Скорее всего, при отключенном gapless есть “плавающая“ проблема взаимной синхронизации Kinsky и рендерера. Если отключение Gapless важно, можно попробовать использовать вместо драйвера прямую трансляцию из рендерера, которая включается галкой “Scream” на вкладке “Card“.

2 лайка

У меня также работает.
Какое-то время тоже не мог понять.
Включение гаплесс не является проблемой.

2 лайка

Игорь, спасибо.

В том-то и дело, что я использую связку с Kinsky & minimserver столько лет, сколько существует Ваш замечательный aprenderer. И в первую очередь по причине исключительной надёжности. Поэтому данная ситуация сразу бросился в глаза и я решил поделиться с Вами. Для меня отключение Gapless не принципиально и было обусловлено использованием режима воспроизведения Full Memory при средних значениях буфера драйвера ALSA. Игорь, Спасибо за участие!

Юрий, приветствую! Спасибо что присоединились к тестированию для расширения пользовательской базы.

1 лайк

Игорь, спасибо за работу.
Теперь радио работает полноценно без заиканий через вифи без изменений в железе и настройках.

1 лайк

Игорь, а если я транслирую по scream с малинки с Dietpi, на которой установлен Аплеер, что я должен обновить - драйвер ScreamALSA или достаточно только обновить плеер? Если драйвер, то как это сделать правильно?

Аплеер может стримить scream и без драйвера, когда включена галка Scream на вкладке Card панели настроек. И недавнее обновление это не затрагивало.

Драйвер можно обновить простой заменой файла snd-screamalsa.ko на новый вариант, но сначала его кто-то должен собрать из исходников для конкретной версии ядра.

1 лайк

Если стриммить с “галкой”, то там нет выявленной проблемы или Вы просто ещё не проверяли?

С драйвером понял.

С галкой этой проблемы нет.

3 лайка

@igor63r , новый драйвер работает как часы на многонаналке, без проблем с синхронизацией и щелчков!!! Просто идеально. Те проблемы которые я писал выше пару месяцев назад исчезли. СПАСИБО!!!

Теперь этот поезд тронулся!!!

LMS (NAS Dietpi)→

Aprenderer→CamillaDSP→ScreamALSA_driver (Nano pi2)→

PureFOX_8_каналов

2 лайка