IgorA

@hcn47, можно, если использовать новый (2016 года) upnp компонент для фубара и не включать в конфигураторе аплеера режим Full Memory.

@ndp, третья версия для звука ничего не обещала. А для интерфейса ее заменил ap2renderer. В теме об этом упоминалось несколько раз. Поэтому пользователи Windows не теряют ничего. Поддержка продукта продолжается, да и некоторые обновления будут.

В драйвере, который установился в Ubuntu, для Amanero минимально допустимое значение периода 8 фреймов. Соответственно, воспроизводится 8/16. При минимальных буферах экстремально возрастает нагрузка на процессор и, соответственно, интенсивность импульсных помех, поскольку пересылка между приложением и драйвером почти каждого фрейма (или каждого) обрабатывается отдельным вызовом функции, реализующей алгоритм пересылки. Уменьшает это джиттер или, наоборот, увеличивает - вопрос открытый. Возможно субъективное "увеличение объема" как раз от второго эффекта, а не первого.

@m@jor, Эти цифры для hi-res выбирает не плеер, а драйвер, исходя из минимально допустимой длительности периода.

Реальную картину надо смотреть в /proc/asound в процессе воспроизведения. У MPD в коде значение периода вычисляется через буфер поделенный на 4. А буфер в обоих случаях одинаковый. Поэтому не факт, что ALSA отрабатывает вычисленный через буфер период.

У меня играет на Ubuntu "из коробки". Возможно, конкретный драйвер ALSA оперативней обрабатывает прямую запись в память драйвера, .которую использует Jack. В apconsole этот режим использован только в Direct Input Mode. Можно будет его попробовать в Full Memory с минимальным буфером.

Эта информация в каком месте отображается - в выводе MPD или в файле драйвера ALSA?

, я не принижаю Jack, наоборот, он самый продвинутый по низкоуровневым настройкам звука продукт. Просто он не делает ничего, что не может сделать плеер и только в этом смысле Jack объективно не является необходимым звеном. Это данность. Здесь даже не о чем спорить. Он не для всех. Используемая системная конфигурация может быть не рассчитана на минимальные буферы. Но в этом и драмы нет. Я не думаю, что минимальные буферы это гарантия лучшего звука.

TinyCore есть, Wheezy пока не собирал, Клементину ставил на CentOS, но пока она только огорчила своей тяжеловесностью.

Вот точно так же и для вывода, что при равной оптимизации кода и параметров воспроизведения цепочка плеер->Jack->ALSA не может быть лучше цепочки плеер->ALSA эксперименты не требуются. Да, и это упоминалось выше в теме. Интерфейс управления будет, но не завтра.

, вот вариант 64-разрядной тестовой консольной сборки для Linux, который в режиме Full Memory (он активен по умолчанию) использует минимальный поддерживаемый драйвером размер буфера ALSA. http://albumplayer.r...p_x86_64.tar.gz Запускается файл ap. Для большей устойчивости лучше запускать процесс с root правами (sudo ap или залогинившись как root). В этом случае лочится память и повышается приоритет. Но в этом случае надо размещать плеер не в папке пользователя /home , а папке /usr .

Что касается OS X, то я только начал с Linux разбираться. Поэтому OS X лучше заняться кому-то еще. Чтобы не ждать.

@m@jor, Да, здесь три участника - контроллер, сервер, рендерер, которые могут быть скомбинированы как угодно на одном, двух или трех компьютерах. Например, Kinsky, ASSET, ap2renderer. Но JRiver и MusicBee могут совмещать контроллер с сервером.

@m@jor, time = 1000000 / samplerate * samples 45.35 мкс = 1000000 / 44100 * 2 Это для периода. Для буфера, соответственно, в четыре раза больше.

@m@jor, MPD имеет встроенный менеджер библиотеки и все внешнее управление завязано на работу с ним. Если уж использовать готовые клиенты, то пусть они и библиотекой занимаются. А это делают UPnP/DLNA контроллеры/серверы и совместимость с этим универсальным софтом планируется в той же форме, как она реализована в AP 2.110, движком которого можно управлять локально и удаленно из других GUI, включая JRiver, MusicBee, Kinsky.

, как воспроизвести конфигурацию с Jack, которую Вы считаете эталонной по звуку? Чтобы на ней и смотреть.

А Вам потребуется сравнивать варианты, чтобы сделать вывод о полезности перехода от нативного ASIO драйвера к ASIO4ALL? Сейчас два дня как проверяется способность первой тестовой сборки с настройками драйвера по умолчанию запускаться на разных дистрибутивах. Управление параметрами будет позже. Но отдельный тестовый вариант с малым буфером я сделаю.

Задержка между Jack и ALSA может равняться 0 семплов в отсутствие JACK. А период и буфер - параметры ALSA, которые могут управляться без Jack. Если в конфигураторе MPD эти параметры задаются в интервалах времени, а не в семплах, то это вопрос к разработчикам MPD, а не к ALSA.

В комплекте плеера для Windows есть веб-интерфейс и UPnP рендерер. Они управляются, в том числе, удаленно и GUI им для работы не требуется.

@m@jor, меня тоже смущает, что народ в соседней ветке как большое достижение рассматривает повышение стабильности передачи семплов от Jack к ALSA, в то время как в самом этом конвейере нет необходимости. Видимо, аудиофильский смысл Jack в доступности в его конфигураторе низкоуровневых настроек для ALSA, но ими можно управлять и непосредственно из плеера.

@grigoxyr, можно попробовать в /etc/asound.conf после строк card 0 добавить строку subdevice 1 . Или скорее надо device 1 .

@grigoxyr, там вроде только одно устройство поддерживается, поэтому можно попробовать без aplay -L в asound.conf вместо card DAC указать card 0.

Нет, так как стандартное распределение доступных в XP 4GB - пополам между системой и приложением.

Увеличится допустимый для использования Full Memory размер однофайловых образов. Но ограничение в 2GB на декодированный PCM сохранится (в 32-разр. системе).

1. Насчет исходников пока не знаю. Будет видно позже. Но, если будет надо, для конкретной платформы и я смогу наверно собрать. Для специфичных устройств обычно есть эмуляторы и средства разработки, в том числе, и под Windows. 2. Рендерер планируется, но не на первых этапах. Сначала наверно плеер с управлением и настройками через веб-интерфейс.