m@jor

А вот мне, например, малость надоело читать в разных форумах про то, кому что послышалось после очередного искривления программной части своего плеера (я не про aplayer, а про плееры, как источники цифры для ЦАПа) с помощью очередного новомодного костыля или очередного бездумного перебора цифирек в настройках. А тут прекрасная возможность пообщаться с образованными людьми. Спасибо Игорю - прояснил для меня кой какие моменты. Кстати, я своими впечатлениями поделился. Только лично я сильно сомневаюсь, что от моих впечатлений кому то будет какая то польза.

Получается следующая фигня. Если в mpd.conf для period_time установить достаточно малое значение (типа 90-100), то peiriod_size устанавливается в значения 8 для частот 44 и 48, 12 для частот 88 и 96, 23 и 24 для частот 176 и 192 соответственно. Минимальное возможное значение period_time - 125 µs. Кстати эта цифра встречается в файле /proc/asound/Amanero/stream0 в таком виде Data packet interval: 125 us

При 44100 period_size: 8 buffer size: 16 При 96000 12 и 35 DSD DoP = 176000 23 и 64 Чутка странноватые цифры. Не кратные.

Эта информация в каком месте отображается - в выводе MPD или в файле драйвера ALSA? Это то, что я задаю в mpd.conf При меньших цифрах вроде начинает затыкаться, но я в малые цифры копнул бегло Извините, но с сегодняшним движком Игоря легко справляется 2-ядерный пентиум и загрузка на ядрах не более 7% на каждом. Может что то в консерватории?

Ну и на 24/96 Новый движок показывает: ALSA period time: 125 µs ALSA period size (frames): 12 ALSA buffer size (frames): 24 И отлично играет.

"Не необходимое" является лишним Давненько у меня чесались руки на параметры period_time и buffer_time. Вот только руки не доходили. Но тут меня чуток возбудили :attack : Пока Игорь писал код новой версии я поэкспериментировал с mpd-dsd-rt, идущем в комплекте со Snakeoil. Собрался написать о результатах и тут увидел новую тестовую версия. Заодно ещё и её попробовал. С MPD получилось следующее period_time = 91 µs buffer_time = 364 µs Если я правильно понял формулу, то на частоте 44100 это 91 µs / 44100 Hz = 4 семпла buffer_size - 16 сэмплов Запустил новую версию движка и получил (на 44100) ALSA period time: 181 µs ALSA period size (frames): 8 ALSA buffer size (frames): 16 Как я понимаю, это ровно те же самые -p8 -n2, с которыми запускается Джек несколькими постами выше. Игорь, можете пояснить, почему period_time у MPD и Вашего движка различаются в два раза. Или я чего то не допонял? И еще. Вот этот вопрос был как раз об этих параметрах?

Если формулу переписать в традиционном виде, то становиться всё банально и очевидно. Время в секундах = кол-во семлов / samplerate Соответственно period_time (в микросекундах) = 1 000 000 * кол-во семлов / samplerate Соответственно например для 16 семплов period_time должен быть равен 167 мкс Фигасе

Отсталый я - с этими штуками не знаком. Это всё работает по DLNA? То есть нужен будет DLNA-сервер, а плеер будет работать как рендерер? Или это как то иначе?

Когда я пробовал JACK на TinyMPD у меня работоспособными были такие значения настройки Джека: 8/2 для 16/44, 16/2 для 24/96 и 32/2 для 24/192. То есть получается, что жизнеспособная настройка буфера в сэмлах зависит от samplerate. То есть, в свою очередь, настройки передаваемые от MPD в ALSA в интервалах времени, а не в семплах более логичны. Или я что не так понимаю? И если можно, подскажите, плз, как персчитать настройки в сэмплах в настройки buffer_time и period_time в микросекундах. Или я порю чушь? Не силён я в этих буферах.

Существующий год назад веб-интерфес меня очень сильно не устроил. А потом надобность пропала по причине отказа от винды. Я наслышан, что потом были подвижки, но уже не актуально. Осмелюсь повторно озвучить вопрос в части управления плеером. Да простится мне моя упёртость. А нет ли возможности (а почему бы не...) использовать для управления готовые клиенты управления mpd, коих есть некоторое количество на любой вкус и для разных платформ? Как я понимаю, исходники mpd открыты и разобраться в командах управления на стороне плеера для профи не составит великого труда. Если конечно это не сопряжено с какими либо лицензионными ограничениями. Это избавило бы Вас от затрат на написание интерфейса управления и дало бы возможность пользователю выбирать программу управления под свой вкус и железо.

Поскольку, похоже, что в данном случае "остальные" - это я, вынужден ответить: 1. Спасибо за добрый совет, но я сам определюсь, что мне писать стоит, а что нет. Писать не стоит технически безграмотный бред. Или, как любят некоторые удифилы, не стоит обобщать свой несчастный случай на всё вселенную. А я лишь поделился своим личным наблюдением и описал ситуацию, имевшую место на другом форуме. 2. Я действительно не понимаю, какую полезную функцию выполняет данная прокладка. О чём и написал. Если Вы можете технически грамотно это объяснить, буду безмерно благодарен. Это логическая ошибка. Из факта использования Джека отдельными индивидами вовсе не следует правильность и необходимость Джека для большинства, ибо: 1. Могу предположить, что вполне могут быть такие кривые и убогие конфигурации железа и софта, которым и "Джек в помощь". 2. Многие удифилы из-за безграмотности любят феньки из проф. мира. А если ещё и настройками дадут порулить, то вообще счастье. 3. Удифилы наивны, стадны, легко внушаемы и любят всё новое. Стоит паре-тройке "энтузиастов" чего то напеть про "очередной прорыв" или "эволюцию" и вот уже десятки последователей разносят чушь по форумам и сотни потом это "слышат". Пункты 1-3 к Вам безусловно не относятся - я просто пояснил ошибочность Вашего суждения.

Мне это идея кажется банальной и очевидной. Если источник нормальный, то он стоит в стойке вместе с ЦАПом и усилителем (заранее извиняюсь у всех владельцев ушных систем, может у Вас иначе). А если он в стойке, то там обычно нет ни клавы ни монитора. Зачем же там ОС с ГУЕм? Жрать ресурсы и мутить звук? Помнится, я Игорю над безгуевым плеером предлагал еще под виндой подумать. Тогда бы его можно было бы запускать под сервером в Core режиме. Но, наверное, идея не понравилась. Недавно довелось попробовать Jack+Clementine с более менее низкими задержками в составе AVLinux. Относительно того, что есть сейчас абсолютно не впечатлило - объем дутый, локализация хуже, всё чутка мутнее чем сейчас. Вполне допускаю, что я просто не умею Jack готовить или не лучший вариант ОС для этого выбрал. Но я бы такой звук за эталон брать не торопился. Кстати на форуме TinyMPD была попытка вбросить в коллектив вариант с Джеком. В начале было много энтузиазма, но потом он подостыл. Дутое пространство дало вау-эффект, а потом он прошел. Но всё равно "стронников" осталось больше чем "противников" А может кто технически грамотно пояснить в чём польза от этой дополнительной прокладки? Умных статей на эту тему я не нашел, а англоязычные форумы я не понимаю.

до создания файла /etc/asound.conf aplay -L выдаёт список после создания не выдает но если сделать sudo aplay -L то список будет можкт что то с правами на /etc/asound.conf но у меня стоит на этот файл 100666, куда уж больше

Добавка: Full Memory в тестовом движке вроде лучше, чем Direct. Под виндой у меня было наоборот.

Album Player for Linux Engine test Тест пройден. Вчерась удалось послушать презентованный движок. Нормально звучит. Сразу хочу сказать, что великим слухачом не являюсь. Да и более-менее нормальный "канал передачи" данных по USB не страдает излишней чувствительностью к программным делам. Всё, что не совсем криво, ему вполне хорошо. Но тем не менее: слушал - докладываю. Сравнить с плеером под винду не могу, за неимением оного. Но могу сравнить через пару промежуточных этапов. Последняя версия, с которой имел дело - 108-я на очень неплохо оптимизированной Win7. С неё перебрался на TinyMPD, которая звучала получше аплеера на винде. С неё - на Snakeoil OS, который в свою очередь на мой ух звучит самую малость лучше TinyMPD. Под Snakeoil и поставил движок. ГУЯ там нет, активных процессов - минимум. Плеер для сравнения mpd-dsd-rt. Материал для сравнения - хорошо записанный джаз в DSD и PCM 24/96. На мой глухой ух тестовый движок ни сколько не уступил штатному плееру. Даже временами казалось, что движок чуть яснее и чуть громче. Второе немного странно, но несколько раз ловил себя на этом ощущении. В общем я двумя руками приветствую продолжение работ в этом направлении. Особенно если это будет правильно-минималистичный безГУЁвый демон, управляемый по сети отдельным приложением или на крайняк веб-интерфейсом.

Спасибо. Но я уже часа полтора как экспериментирую со вчерашней - библиотеки по Вашим советам поставил ещё днем. Звук есть. Чуть позже отпишу свои первые впечатления. И новую тоже попробую обязательно. P.S. Не всегда я с Вами согласен. Но по отзывчивости Вы вне конкуренции

Спасибо. Вторая команда выполнилась с какими то ошибками, но плеер завёлся. По папкам бегает. Звукоизвлечение смогу проверить только вечером поскольку сейчас вдали от системы.

@IgorA, К сожалению пока не помог ===== Album Player for Linux Engine test Output to ALSA default device Full memory mode /usr/local/bin/aplayer: relocation error: /usr/local/bin/aplayer: symbol _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference major@snakeoil:/usr/local/bin$

И снова здравствуйте, Игорь. Давненько перестал интересоваться Вашим плеером для виндовс (а интересовался я им на хоботе) поскольку под линуксами у меня получилось всё гораздо интереснее по звуку , намного удобнее в использовании и быстрее в настройке. Но люди добрые сообщили о Ваших свежих экспериментах :attack : . Памятуя, чего Вам удалось достичь под виндой , не смог пройти мимо. Уж извините, ещё чутка покапаю на мозг. 64-битную версию пока запустить не удалось. Ошибка такая Album Player for Linux Engine test Output to ALSA default device Full memory mode /usr/local/bin/aplayer: relocation error: /usr/local/bin/aplayer: symbol _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference Плеер и библиотеки разместил в /usr/local/bin/ Версия Линукс эта: https://www.snakeoil-os.net/forums/Thread-Frequently-Asked-Questions-FAQ