Дистрибутив Yoctoap: Album Player + UPnP Renderer + Console Player + Roon/LMS Bridge + GUI

Я вообще почти никогда не использовал Full Memory, но сейчас на тестах заметил глюк:

  1. если нажать на альбом и ничего не трогать играет нормально
  2. но если начать переключаться между треками в середине, а потом вернуться к какому-то ранее проигранному треку, проигрывание может внезапно остановиться. И даже если нажать на потом повторно этот же трек, проигрывание остановится в том же месте где в прошлый раз.

Что-то явно с кешированием не то… Глюк встречал много раз… Повторяемость не 100%, но если много прыгать по трекам - легко.

Режим APlayer, монтировка NFS.

Тут, видимо, суть в том, что если во время загрузки файла в режиме Full Memory при воспроизведении приходит команда «Стоп», то файл остаётся недозагруженным, а возможность воспроизведения загруженного фрагмента сохраняется. А файл может быть многотрековым альбомом с .cue и там не все треки будут загружены. Или можно переключиться на трек, которого ещё физически нет в памяти, и будет тишина. Выход в том, чтобы выбирать другой файл или дожидаться окончания загрузки текущего, если хочется по нему свободно путешествовать. В классическом интерфейсе аплеера на время загрузки исчезает полоса прогресса, а по окончании выскакивает, сигнализируя о доступности управления.

У меня все FLAC порезаны. Речь про отдельные треки.
Может сделать принудительную загрузку ?

Если после Стоп-Старт загружать файл заново, с этим свои минусы связаны. Без стресс-тестов обычно и так всё нормально.

А можно подробнее ? По какому принципу кеширование сделано ? cp файл /dev/null или более хитро ? По top не видно, что aplayer вдруг потребил много памяти. В идеале выкидывать из кеша все недокачанные файлы.

ну не такой уж я делал стресс тест, просто недослушав переключаешь, возвращаешься, а там засада…

Кстати, обычный cp копирует в 3х быстрее, чем кэширует aplayer (18мбит против 60мбит). Может заодно сменить алгоритм кэширования ? Речь про pi1. pi3, pi4 вероятно могут быстрее, но ненамного (помню когда гонял yocto на pi4).

Готов быть бета тестером, чтобы остальные не страдали :slight_smile:

Аплеер в Full Memory не только копирует, но и декодирует при предварительной загрузке в память (если не WAV).

1 лайк

Согласен, на распаковку FLAC нужно много ресурсов CPU…
Но тогда (если условно cp) корректная работа возможна только при принудительном новом копировании каждый раз при проигрывании ? Есть какие-то средства проверки состояния кеша в линуксе ?

И при переключениях Radio / Плеер валится очень часто.

На какой платформе и с какой версией (по дате загрузки) Yoctoap наблюдаются проблемы?
Я сейчас побегал в Full Memory хаотично по файлам-трекам в актуальной Yoctoap (на BBB) с коробочными настройками, только Full Memory включил. Файлы с ноутбука, W10, cifs. У меня всё стабильно переключается. И переключение Радио/Файлы без проблем.
Собственно кэшированием плеер не занимается, это в ведении операционной системы, вряд ли там что-то не так.
С Full Memory могут быть проблемы, когда памяти на борту мало и не хватает на декодированный файл. Памяти может требоваться довольно много, потому что, когда вывод 32-разрядный, в памяти размещаются 32-разрядные семплы.

Проблема с последней сборкой под pi1, эта малина хоть и медленная, но памяти там достаточно - 512мб.

То есть, используется образ для Zero W с отключенным Wi-Fi?
А настройки чем-то отличаются от исходных?

да ZeroW
Preload Buffer 176400
ALSA Period 1024
ALSA Buffer 32768
NFS rsize, wsize 8192, udp

Я погонял с этими настройками плеера на RPi1 в Full Memory файлы с NFS сервера на lubuntu. Пока у меня проблемы не воспроизводятся - и файлы, и радио нормально переключаются. Может быть, есть завязка на конкретный NFS-сервер.

1 лайк

Я вот сейчас с одного раза убил плеер:
Было Full Memory 16bit output
Включил Volume control (радио обычно громче играет) 16 бит не трогал
Потом нажал Radio и плеер умер.
(плеер был включен более часа назад)

Как это ни странно, но переключение радио/плеер умирает чаще когда плеер долго чем-то занимался (играл радио или файлы). А когда намеренно дергаешь - заметно реже.

Еще я использую только интерфейс Dimas, браузер Chrome.
NFS на базе малины4, нареканий нет, провод без свича идет прямо в pi1. dmesg на pi4 чистый.

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

Здравствуйте Игорь!
Подскажите пожалуйста, галка на «Lock Memory» должна быть установлена для любых режимов воспроизведения?
Использую Yoctoap PC, режимы «Стандарт» и «Full Memory».
P.S. Ещё вопрос насчёт ядер. Процессор у меня двухъядерный. Что предпочтительнее «Without selecting cores» или «Single Core»?

Михаил, обе опции неоднозначные, их роль комментируется в руководстве пользователя в описании панелей настроек. Обычно нет необходимости их изменять, но есть возможность поэкспериментировать. Вполне возможно, что заметной разницы не будет. Плеер в режимах воспроизведения Standard и DirectInput позволяет переключать эти вещи без остановки воспроизведения, поэтому можно объективно оценить, есть ли их влияние на результат. Точно не нужно включать SingleCore, если преобразовывать DSD в PCM или воспроизводить SACD с DST сжатием. Там декодер использует все ядра.

Игорь, огромное спасибо за подробный ответ!

1 лайк

Система YoctoAP x64 на ядре 5.0.3, консольный плеер версии 1.05, режим вывода - Native DSD/Full memory, ALSA period 512, ALSA buffer 16416. При старте воспроизведения файла DSD1024 выдается сообщение об ошибке:

Loading/usr/bin/ap.sh: line 4: 1087 Segmentation fault ./ap “$1”

Необходимо обновить встроенный консольный проигрыватель?

German, я имел в виду отсутствие ограничений в рамках поддержки ходовых форматов DSD64-DSD512. На DSD1024 используемый плагин SACD изначально не рассчитан и обновление здесь потенциально возможно, но в будущем.

2 лайка