IgorA

Для работы с 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). Там какое значение периода?

@ampir-nn, Соседнюю тему я читаю, просто на эту статью перешел, просматривая тему на другом сайте. Что можете возразить по существу проблемы? Каким образом Jack может влиять на равномерность передачи семплов от ALSA драйвера в USB контроллер, если он работает до ALSA? Есть единственный вариант - если драйвер работает с минимизированным до нуля буфером и его реакция на прерывание, запрашивающее данные зависит от равномерности подкачки отдельных семплов от Jack. Но это ситуация по сути аномальная, так как буферизация в технике для того и придумана, чтобы не было таких проблем.

С этой минимизацией буферов люди иногда не задумываются, что вообще происходит и почему. Например, на dastereo.ru была ссылка на статью о том, как Jack изобрел свой способ бороться с джиттером: http://kokkinizita.linuxaudio.org/papers/usingdll.pdf Но если эту статью посмотреть, то обнаруживается, что Jack борется только с тем джиттером, который он сам создает, неравномерно передавая драйверу отдельные семплы. А если передать туда данные сравнительно большими блоками, как это делают обычно, то и причины этой нет. Получается, что пресловутая low latency, за которую Jack борется сугубо для realtime коммутации, оказывается генератором джиттера.

Здравствуйте. Звуковой движок плеера использует один поток и он обычно загружает ядро менее чем на 1%. Да и декодеры, за исключением DSD, однопотоковые. Поэтому увеличение числа поддерживаемых аппаратно потоков скорее всего ничего не даст.

Возможно, драйвер не поддерживает 32-битовую разрядность аудиопотока, которая используется для всех форматов в тестовых сборках. Адаптивный к устройствам вариант будет позже. Насчет вчерашних экспериментов - попробуйте автозапуск Pulse отключить, иначе он не дает выводить в ALSA непосредственно. Выше, в 11-09 информация по этой настройке.

Если не прописывать в /etc/pulse/client.conf autospawn = no (с перезагрузкой), PulseAudio автоматически вклинивается в любой вывод через ALSA. Насколько я помню, OnlyWav тоже будет работать.