IgorA

Драйвер всегда лимитирует буфер снизу и сверху. Но у разных драйверов эти диапазоны разные.

@ksv90965ksv, я поставил ASUS ST, проверил в 64-разрядной Ubuntu и 32-разрядной Lubuntu версий 16.04. В обеих Direct Input в ASUS с последней версией плеера нормально работает с настройками по умолчанию. То есть, проблема, видимо, связана с конкретными драйверами или настройками.

@ksv90965ksv, для ASUS для начала можно попробовать, что будет, если сделать большой буфер. Например, pf24000, bf96000.

Добрый день. Конкретных проблем совместимости с отдельными картами может быть много, поэтому я пока не знаю, что требуется для ASUS, но если что-то выяснится в дальнейшем, я напишу. Для Pulseaudio все-таки надо вручную отключать автозапуск. В /etc/pulse/client.conf autospawn=no вместо ;autospawn=yes. Точку с запятой в начале строки тоже важно убрать. И перезагрузить. В di регулировка буфера была сделана только для 24-битового вывода. Сейчас я добавил в остальные. Но в di минимальный буфер невозможен технически, так как там декодирование выполняется прямо в буфер драйвера, а выполняется оно не отдельными фреймами, а блоками, и когда дойдет до очередного блока, минимальный буфер исчерпается раньше завершения декодирования и воспроизведение остановится. Паузу я добавил (команда "B"), еще добавил перемотку на позицию в секундах. Для этого в режиме воспроизведения вводится число в секундах. Выход теперь не через "0", а через "X". Еще в текущем обновлении исправлены права доступа к файлам конфигурации. В предыдущем варианте созданные под root настройки нельзя было изменить при запуске от пользователя. ap32.tar.gz ap64.tar.gz

Консольная версия ap (linux) с дополнительными настройками. Цвет музыкальных треков пока поменял на зеленый (с учетом пожеланий в теме). Теперь ключи при запуске не используются. Настройки изменяются через меню плеера и сохраняются. Соответственно, можно переключаться между Direct Input и Full Memory, DoP и PCM. Для вывода DSD в PCM можно выбрать выходную частоту: pcm176 и т.д. Команды pf - period frames pt - period time bf - buffer frames bt - buffer time di - Direct Input mode fm - Full Memory mode pcm - DSD->PCM mode (pcm, pcm44, pcm88, pcm176, pcm352) dop - DSD DoP mode card - Select sound card В первых четырех командах после команды без пробела добавляется число: pf1024 и т.д. Теперь можно не создавать самому /etc/asound.conf. Чтобы это сделал плеер, надо запустить плеер под root. Это и вообще полезно, так как позволяет плееру повысить приоритеты и залочить память. После выбора или изменения карты по команде card требуется перезапустить плеер. Поддерживаемая драйвером разрядность вывода подбирается автоматически. 32- и 64-разрядные версии: ap32.tar.gz ap64.tar.gz

Для работы с VST инструментами плеер не предназначен и эта категория плагинов не загружается.

При настройке DSD важно не включать режим вывода Native DSD, так как в WASAPI он не поддерживается. Если даже со стандартными настройками декодера на PCM вывод возникает ошибка, может быть, некорректно распознается конкретный SACD образ. Обычно такой проблемы нет. При выводе в PCM SACD декодер выдает 24-битовый поток и в некоторых случаях он может в WASAPI не поддерживаться. Тогда может помочь включение опции конвертации 24->32 в конфигураторе WASAPI. И копировать wasapi_config не требуется, тем более, 32-разрядный в 64-разрядную версию. Все сам делает конфигуратор ap2config, если в нем выбрать модуль вывода WASAPI.

@bzx, выбор карты скоро будет в консольном плеере, но пока этого нет, команда aplay -L выдает список, в котором есть идентификатор карты. Чтобы aplay работал, надо один раз запустить alsamixer. И затем в /etc надо создать asound.conf, как было описано. В Tiny можно поставить из стандартного репозитория браузер Opera9. Он, вроде бы, форум показывает.

@giclee, бывает, что dll драйвера ASIO только 32-разрядная. Тогда на 64-разрядной системе нужно запускать 32-разрядную версию аплеера (фубар тоже 32-разрядный).

@xp-96, драйверы ALSA, подобно драйверам ASIO в Windows, принимают в режиме прямого вывода только одну разрядность. Тестовый плеер выводит 32 бита, что подходит для XMOS и Amanero, но для некоторых ЦАПов требуется 24 бита. Адаптивный к любой разрядности вариант консольного плеера скоро будет, поэтому есть смысл подождать.

@trollmelly, здесь какой-то конфликт c Jack, судя по сообщениям. Обращения к нему происходят. Соответственно, какой-то код вклинивается автоматически и вызывает Jack, так как сам плеер обращается только непосредственно к ALSA. Я Jack пока не устанавливал, поэтому не разбирался, как его корректно отключить. С Pulse, похоже, это проще делается. Если получится, в ближайшие дни посмотрю, как ужиться с Jack, тогда отвечу в тему.

@Allek, Можно попробовать sudo chmod 777 aplayer

Period time соответствует частоте 44, а не 88. То есть, драйвер Realtek при этих значениях настроек буферов включает 44KHz, когда его просят 88. Надо начать настройку с буферов по умолчанию.

Я думаю, нам не следует погружаться в теоретические споры. На вход ЗК подают аналоговый сигнал, который может быть сколь угодно близок к образцовому. А на картинках там сравнивается качество передискретизации через ALSA и их программу. Передискретизации, которой в нормальной ситуации просто нет. В остальном все верно

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

Задержка при обработке прерываний (latency, которая меряется) и джиттер сигнала, передаваемого через интерфейс - это разные вещи. Загоняя буферы в ноль последнее Jack скорее увеличивает, чем уменьшает, о чем по сути и говорит статья, на которую я выше давал ссылку. А кроме того, еще и электромагнитный шум, порождаемый большей активностью процессора при минимальных буферах - источник помех и наводок, увеличивающих сигнальный джиттер.

@ampir-nn, Ядра умеет и Album Player под Windows захватывать. Это еще не решение всех проблем. В пользе минимализма программной активности и в том, что отправной вариант (эталон) должен быть минимальным во всех отношениях, я не сомневаюсь.

@ampir-nn, Работающий (даже в фоне терминального сеанса) GUI это уже активность процессов на уровне единиц процентов загрузки CPU. Смысл в том, чтобы в процессе воспроизведения комп был "тише травы, ниже воды" с загрузкой "0.0%". И повторюсь, такой вариант не финальная цель, а лишь точка отсчета.

@ampir-nn, подобный вариант наверно будет и, скорее всего, вообще без GUI, почти досовский загрузочный плеер, как ультраминималистская точка отсчета, с которой можно будет сравнивать все дальнейшее.

@PolarLight, предыдущие версии ap автоматически выбирают минимально доступный буфер, который не всегда работоспособен. В этом может быть основная причина проблемы. Для ее решения сделана последняя версия.

Вот универсальный вариант ap с ручной регулировкой размеров периода и буфера. Выбранные настройки сохраняются и используются при следующих запусках. В состоянии, когда нет воспроизведения, доступны команды pf - размер периода в фреймах, pt - размер периода в микросекундах, bf - размер буфера в фреймах, bt - размер буфера в микросекундах. После команды без пробела вводится число, например pf1024 - это период 1024 фрейма. Для сброса на значение драйвера по умолчанию вводится -1 : pf-1 ap.tar.gz

Без буферизации передачи по стандартным интерфейсам не бывает. И при изохронной передаче по USB передаются фреймы, содержащие десятки байтов, и, естественно, эти фреймы предварительно буферизуются в контроллере USB и последовательность их передачи синхронизируется аппаратно. Что касается влияния кабелей на звук, то если бы при передаче сыпались биты, это был бы конкретный треск, а не влияние на окраску звука. Когда влияние есть, это скорее разная чувствительность к наводкам, влияющая на тот же джиттер. В обеих версиях декодирование выполняется в процессе предварительной загрузки.

@m@jor, в API ALSA есть функции, задающие минимально допустимый период. Они должны быть адаптивны к samplerate. Ими я и пользовался. Но в любом случае в дальнейшем период будет настраиваться пользователем. Да и минимальный период, возможно, скорее фетиш, чем реальная польза для звука. Возможно, как и RT ядро. Я поставил Debian с RT ядром, но в звуке явных преимуществ не обнаружил. Зато загрузка процессора при воспроизведении вместо 0% на обычном ядре стала 7%. Собственно, "последняя миля", когда аудиопоток отдается на USB шину USB контроллером, синхронизируется уже не софтом, а чисто аппаратно. С использованием все той же предварительной буферизации. И в отношении джиттера здесь, видимо, гораздо важнее стабильность клока на плате, чем версия ядра.

@m@jor, дело все-таки в том, что драйвер по запросу возвращает минимальную длительность периода, которая не для всех частот подходит. Вот устойчивый вариант для Amanero (64 разр.), где зашиты периоды 8, 23 , 24 для 44, 176 и 192KHz. Он играет 176. ap.tar.gz

@m@jor, меньшая частота может включаться, если не поддерживается аппаратно заданная или если для минимального буфера не хватает производительности. Для 192KHz может повысить устойчивость воспроизведения запуск с правами root (sudo ap или из терминала, перейдя в root). Там какое значение периода?