IgorA

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

В Windows максимально допустимый период таймера одновременно является стандартным периодом - 15,6 мс.

Видимо, это при переключениях внутри образа с .cue. Они отрабатываются через перемотку. При этом в ресемплер SoXR передаются новые данные, но у него есть свой внутренний буфер, их которого может доигрываться остаток ранее ресемплированных данных. Я добавил сброс SoXR при перемотке, можно проверить : approxy_x32.zip

Можно записать выходной поток плеера в файл, например, через ASIO grabber, и посмотреть в аудиоредакторе, есть ли там при малой громкости не нулевые данные в младшем байте. Или спросить у автора плеера, в какой разрядности обрабатывается громкость для 16-разрядных исходников.

@AlexMi Да, на выходе 24-разрядный поток. При конкретном уровне громкости с последнего скриншота отбрасываются 2-3 двоичных разряда. Если эта обработка применяется после преобразования 16-разрядного исходника в 24 бита, то фактически ничего не теряется.

Уровня цифровой громкости относительно 100%.

В EXTRAS ASIO в основном оптимизация для "сверхтихого" режима воспроизведения из памяти, когда процессор не загружен вообще. И там не поддерживается многоканальный вывод, в отличие от out_asio.dll. С точки зрения содержания передаваемого сигнала между этими модулями различий нет. Будет ли какая-то разница за счет минимизации конвейера и процессинга в EXTRAS ASIO зависит от конкретных условий прослушивания. Про это и ещё про многое другое рассказано в файле readme_ru.txt. В Mini нет DSP/VST модуля, короче конвейер, за исключением режима Full Memory, поддерживается ультраминимизированный режим Only Wav, не поддерживается воспроизведение ISO файлов. Сужается динамический диапазон и эффективная разрядность сигнала, соответственно, при сильном ослаблении это может сказываться на детальности/прозрачности звука. Но, с другой стороны, при 24/32 битовом выходном потоке и не экстремальном ослаблении потери находятся за гранью слышимого.

@AlexMi, в некоторых драйверах громкость через ASIO управляется через системную громкость. В этом случае управление громкостью будет доступно после включения опции "Управлять системной громкостью" в ap2config. Если эта регулировка не действует, то внутренняя цифровая регулировка громкости при выводе через ASIO доступна не в EXTRAS ASIO, а в стандартном модуле вывода при использовании с ним выходного плагина out_asio.dll. Там для этого надо включать опцию "Volume Control" в панели настроек плагина. В версии Mini, доступной по отдельной ссылке на странице плеера, модуль вывода ASIO аналогичен EXTRAS ASIO из основной версии, но там для всех модулей вывода реализована возможность внутренней цифровой регулировки громкости, которая включается соответствующей опцией в ap2config.

Добрый вечер, Дмитрий! Готовые сборки тоже будут иметь смысл, но не на этом этапе. То есть, прямо сейчас мне продуктивнее об этом не задумываться.

@svladimir57 Радио будет несколько позже. Линукс-версия в стадии разработки и обновления через некоторое время будут.

В приложении TIDAL для Windows надо выбирать в настройках Streaming -> Quality Master, внизу в Streaming выбирать конкретное устройство, справа от его названия кликом по шестеренке вызывать настройки устройства и там включать Use Exclusive Mode. Тогда MQA будет выводиться в 24/88/96.

Вот актуальный 32-разрядный GUI без прерывания текущего воспроизведения: aplayer_x32_alexh.zip

Юрий, я думаю, последняя полная версия плеера - 2.110. Настройки для DSD и SACD, включая режим вывода Native, выбираются в свойствах плагина in_sacd (через команду "Форматы файлов" в контекстном меню плеера). Остальные режимы и настройки выбираются в конфигураторе ap2config. Я рекомендую выбрать там модуль вывода EXTRAS ASIO. Использовать ли режим Full Memory (выбирается на первой вкладке в ap2config) - каждый решает сам. Он самый "тихий" в отношении условий воспроизведения, но может быть неудобен из-за дополнительных таймаутов. Возможно, достаточно близко можно приблизиться к Full Memory по режиму работы, используя большой буфер предзагрузки в стандартном режиме воспроизведения. Для этого можно выбрать для EXTRAS ASIO большой буфер предзагрузки (preload buffer) в конфигураторе asio_x64_config.exe. Остальные настройки можно не менять. Я еще использую опцию "одно ядро" на первой вкладке ap2config, но для сжатого в DST потока этот вариант замедлит декодирование, поскольку декодер там многопотоковый.

@China, конвольверами я сам фактически не занимался, но их активно используют для коррекции характеристик помещения и акустики. Мест в интернете, где это обсуждается, много, в том числе, такие темы есть на форумах Soundex и Vegalab. Мне лично конвольвер пригодился для эффективной корректировки горба на ВЧ у наушников HifiMan HE-4. Сибилянты подавились очень наглядно без какой-либо слышимой деградации звука в целом. Для генерации корректирующего файла импульсного отклика использовалась бесплатная программа rePhase. Первый вариант мне сделал Михаил (sirap) на Вегалабе, затем я его сам немного скорректировал.

@AleXH, новые версии плеера запускаются только в единственной копии и для обычного использования информация в панели о пути к папке плеера не нужна, на мой взгляд. А старые версии я уже не буду переделывать. Для экспериментов со звуком можно различать варианты из разных папок с разными настройками за счет их позиционирования на экране, которое запоминается и используется при следующем запуске.

Имеет. Не длиннее его может быть только Native ASIO от изготовителей изделия.

Видимо, ее автор проверил, работает ли кнопка "Удалить тему".

@Дуст Включите (до запуска плеера) в панели настроек WASAPI (wasapi_x64_config.exe) опции конвертации в 24 бита.

Давайте конкретно разбираться. Вот ключевой тезис ampir-nnn: "я привел доказательства факта повышения стабильности фазы от простого ядра к RT ядру" Стабильность фазы чего именно повысилась и какое это имеет отношение к воспроизведению звука? В документе про метод DLL по последней ссылке от ampir-nnn читаем: New mechanism to obtain an accurate mapping between samples and system time was recently in troduced into JACK То есть, рассматриваемый в статье метод решает задачу точного отображения времени семплов аудиопотока на системное время. А теперь, внимание, задумайтесь пожалуйста все - зачем нужно точное системное время программе воспроизведения звука? Если время между семплами однозначно задается частотой дискретизации потока и больше ЦАПу ничего не надо знать про время, чтобы корректно всё воспроизвести? Правильный ответ - незачем. Почему же тогда в статье это рассматривается как актуальная задача? Ответ: Потому, что это в самом деле актуально, но только для тех, кто занимается синхронизацией различных потоков. В этом случае, да, их взаимный сдвиг во времени задает отклонение синхронизации от идеала и является минусом. И именно он является фазовой ошибкой, о которой идет речь. Почему этот фазовый сдвиг начинает волновать ampir-nnn и принимает какой-то ценностный смысл для него, сопровождаемый пропагандой этого решения в форуме? Спрашивайте у ampir-nnn. Мой ответ: от непонимания сути происходящего. Что рассказано в статье про DLL по последней ссылке ampir-nnn? Там рассказано про метод, который позволяет точнее вычислять предсказанное системное время следующего периода семплов. Формулы в конце иллюстрируют следующее: Банальное предсказание времени следующего блока - это число семплов в периоде поделить на частоту дискретизации. Это идеальное время. Если например, период содержит 4410 семплов, а частота дискретизации - 44100, то время до следующего периода - 100 мс. Реальный запрос на следующий период приходит в приложение с другой периодичностью. В статье приводятся корректирующие формулы для повышения точности предсказания следующего блока с учетом измеренной ошибки для текущего блока. Ошибка вычисляется как разность предсказанного времени и времени, реально измеренного по таймеру. Возвращаемся к исходному вопросу: зачем надо знать точные (реальные, а не вычисленные) интервалы до следующего периода и минимизировать ошибку их предсказания (ту самую loop error, которую измеряет и гордо демонстрирует всем ampir-nnn)? Ответ: это важно для синхронизации потоков и адаптивного ресемплинга, поскольку точность ресемлинга определяется точностью информации о соотношении чуть различающихся клоков источника и приемника. Другой вопрос: Имеет ли это хоть какое-то отношение к проблемам качества воспроизведения звука? Ответ: Нет, не имеет никакого отношения. Поскольку ЦАПу эти данные вообще не о чём, он работает с временем на основе заданной частоты дискретизации и собственного клока, а для драйвера ALSA проблемы системного времени только в том, чтобы вторая половина буфера драйвера с асинхронным чтением успевала заполняться раньше, чем будет передана на выход первая. Для этой задачи слежение за реальным временем также ничего не дает - делай всё по возможности быстро и с запасом по времени и никакие фазовые ошибки между прогнозируемым и реальным временем периода никакого влияния и отношения к результатам работы драйвера иметь не будут.

Дети к слову. А доки я читаю постоянно, как и экспериментирую. Чего и Вам... Только осознанно, насколько получится.

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

При включенном адаптивном ресемплинге в zita-j2a семплы, передаваемые в карту, корректируются так, чтобы воспроизводимый сигнал выровнялся по меткам времени, получаемым от JACK. То есть, если в карте время чуть медленнее, чем в таймере Джека, семплы для нее чуть ужимаются на шкале времени, если чуть быстрее, семплы чуть растягиваются. Это и есть адаптивный ресемплинг. Если темп времени источника чуть плавает, то в стабильную карту переносится эта нестабильность, поскольку источник - эталон, к которому подстраивается темп звучания. Зачем это делать? А иначе просто не синхронизировать две карты с отдельными кварцами. То есть, это плата за саму возможность синхронизации нескольких устройств.

Суть то в том, что Zita сделана для адаптивного ресемплинга (смотрите все публикации о Zita, у которых это в названии) и его отключение переводит Zita в режим дополнительного буфера, ничего в джиттере не меняющего и бесполезного. Кстати в справке про опцию -S сказано, что она для случая, когда JACK тактируется одним клоком с картой: The -S option disables resampling. This requires that the device is synced via word-clock to the one used by Jack. Насколько корректно будет работать с этой опцией Zita при невыполнении этого условия - неизвестно. Что касается перехода на клок Джека при включении адаптивного ресемплинга - это факт.

Давайте, все вместе внимательно разберемся в смысле картинок, которые выложил (и далеко не в первый раз уже выкладывает) ampir-nnn выше на этой странице. Это очень важно для того, чтобы разум восторжествовал и победил мифологию, порождаемую безграмотностью вкупе с безответственностью. ampir-nnn использует компонент Zita-ajbridge, содержащий модуль zita-j2a. логи работы которого выложил выше на странице ampir-nnn. Как работает этот компонент? Он внедряется между JACK и драйвером ALSA как ещё один дополнительный посредник, включающий в себя ресемплер. Вот его внутренняя структура из статьи про Zita: Зачем в структуре этого модуля нужен еще какой-то ресемплер, если надо просто передать звуковой поток драйверу? Ответ на этот вопрос даётся уже в самом первом предложении статьи о Zita: Combining audio components that use incoherent sample clocks requires adaptive resampling - the exact ratio of the sample frequencies is not known a priori and may also drift slowly over time. This situation arises when using two audio cards that don’t have a common word clock. То есть, Джек раздает один поток на разные карты, которые неизбежно будут расходиться во времени воспроизведения больших блоков семплов, а их надо насильно подгонять к синхрону, создавая для них две версии раздваивающегося входного потока, каждая из которых адаптирована к соотношению входного клока и клока конкретной карты. За счет этого рассинхрон подавляется. Именно эту задачу решает адаптивный ресемплер в Zita. В качестве актуальной проблемы в статье отмечается то обстоятельство, что неравномерность получения данных о текущем времени воспроизведения в карте от драйвера ALSA приводит к погрешностям в подгонке потоков (ресемплинге, передискретизации), создавая аналог джиттера. Вот теперь внимание! Это и есть тот самый джиттер, с которым столь торжественно, пафосно борется ampir-nnn, демонстрируя всем свои достижения. То есть, это джиттер, создаваемый адаптивным ресемплингом. В Zita применяются определенные решения, чтобы его минимизировать. А вы еще не догадались, как побороть его более надежно, на 100% и навсегда? - Правильно! Вообще не использовать адаптивный ресемплинг, JACK в паре с Zita. Но следующий и главный вопрос - откуда берется тот общий клок, к которому подгоняет Zita все карты? Какая-то из карт становится главной, а другая подчиненной? Нет! В качестве точки отсчета объективного общего хода времени используется Jack’s microsecond timer. Именно время Джека становится в этой модели общей точкой отсчета, абсолютом, к которому надо подстраиваться. Представьте себе теперь весь драматизм ситуации: борьба за аудиофилию превращается во вредительство. Наиболее стабильный клок звуковой карты подменяется на клок Джека (программы), который задается генератором системной платы. И звуковой поток, передаваемый в карту, ресемплируется на основе данных от таймера Джека. Статья, которая это все описывает, вот (обратите внимание на красноречивое название статьи и имя файла): http://kokkinizita.l...dapt-resamp.pdf

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