IgorA

@BSV, в коде сканирования SACD дисков для потрекового режима была ошибка в операции с адресом памяти, которая может иногда приводить к аварии. Проверьте пожалуйста вариант с исправлением (надо заменить файл in_sacd.dll в папке плеера): in_sacd_x64.zip

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

1. Остается надеяться, что основной вклад вносит джиттер на входе/выходе ЦАПа. Поскольку есть шанс какими-то способами его оценить. Хуже, если определенные паттерны помех влияют прямо на сигнальный процессор мозга. 2. В основном, видимо, да, но шине тоже могут пролезать помехи, в том числе, программно индуцированные. 3. Это какой-то шанс объяснить, почему влияние плееров заметно в столь шумном устройстве, При передаче через S/PDIF это тоже может влиять на клок ЦАПа. В асинхронном USB не должно, пока биты не начнут теряться. А это уже щелчки.

На этот вопрос я уже ответил в начале страницы. Частота прерываний возрастает, когда период подкачки данных становится меньше половины размера буфера контроллера (обычно небольшого). Программного влияния на эту частоту нет и зависимости обработки прерываний от размера буфера драйвера нет, когда буфер контроллера задействован полностью и обновляется без превышения необходимой для этого частоты пересылок. Что я и считаю нормой. Действительно, через настройки ALSA можно зажать до минимума период и буфер, повысив тем самым частоту прерываний и программную нагрузку. Но я, опять же, уже ответил, что ничего положительно в этом варианте не нахожу. И на это я конкретно вчера ответил в ответе BSV: "есть такой известный в акустике факт, что регулярные искажения даже низкого уровня намного заметнее на слух превышающих их по уровню случайных. На этом факте основан широко применяемый и известный метод дизеринга. Он касается уровней отсчетов. Вполне возможно, что с фазовым дрожанием эффект аналогичный. Помехи, синхронизированные с процессингом звука, являются регулярными для аудиопотока, а остальные - случайными." А можно ссылку, если не затруднит? Пролистать сотни страниц напряжно. Вот: http://forum.doctorh...525#entry947907 Ветка оказалась соседняя.

Это азы информатики. Суть принципа буферизации. Я-то как раз документировал влияние плееров на выходной сигнал с ЦАПа и прямо в этой теме весной картинки выкладывал. В отличие Ваших сугубо умозрительных фантазий о влиянии на этот сигнал "джиттера всей системы". А прерывания у вашего контроллера "равномерные" ? Да, прерывания у контроллера равномерные, поскольку синхронизируются аппаратно.

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

При аппаратном тактировании передачи аудиопотока и заполненном на опережение буфере какой-либо возможности прямого программного влияния на процесс этой передачи данных нет. А косвенное влияние - через помехи и наводки, естественно, тем сильнее, чем "шумнее" процессинг.

Чтобы плеер запускался, в ap2config надо отключить опцию "Управлять системной громкостью". Она не работает и плеер аварийно завершается, так как в Server 2016 Core нет службы Windows Audio.

Здесь еще есть вопрос по объективности самого ощущения лучше-хуже. Звук после эквалайзера часто лучше на слух, но хуже, если нас интересует подобие оригиналу. Кто сказал, что любого характера привнесенный в сигнал джиттер будет всегда восприниматься слушателем как "хуже", а не как более объемный и наполненный звук? У некоторых на слух и фубар всех обыгрывает по звуку. Я думаю, что в точных сравнительных измерениях соответствия копии оригиналу выиграют именно самые "тихие" варианты воспроизведения. Что касается медленных процессоров, то это палка о двух концах, так как частоты помех снижаются, но их продолжительность увеличивается при том же объеме вычислений. А вот минимизация самого процессинга, сопровождающего воспроизведение, на мой взгляд, безусловное благо.

@BSV, а папки SACD были пересканированы после переключения опции "Full disc playback mode"?

@BSV, да, ведь approxy64 обновлялся. Попробуйте этот вариант. approxy64_.zip

Так ведь нагрузка на процессор, синхронизированная с процессингом звука, это и есть та самая единственная ось зла, которую я могу представить в качестве возможного источника косвенных влияний на воспроизведение в условиях bit perfect передачи данных и опережающей буферизации с собственным клоком. Если есть какие-то другие идеи, предлагайте пожалуйста.

m@jor Видимо, только когда буфер драйвера становится меньше буфера контроллера (который и так небольшой - сотни байт), он начинает лимитировать размер передаваемого блока и возникает такая ситуация. Но по моим представлениям в этом нет ничего хорошего.

Так и вопрос, с которого обсуждение началось, был задан о настройке буферов для этого плеера. В linux версии в DI весь процессинг синхронизирован с подкачкой этих блоков, а в FM вынесен во времени за рамки их передачи. В других плеерах собственный буфер тоже может регулироваться. То, что происходит на этапе передачи данных из памяти драйвера в аппаратный контроллер вообще находится за рамками софтовых настроек. Там передаются фиксированные фреймы размером от десятков до сотен байт. И в контроллере тоже опережающая буферизация. То есть, передает он один блок данных и параллельно принимает другой. Поскольку из памяти трансфер на порядки быстрее передачи данных по интерфейсу, то опоздать здесь невозможно и ускоряться, в общем-то, незачем.

Размер периода в настройках буфера драйвера определяет размер регулярно передаваемого плеером в драйвер блока данных. Соответственно, именно с блоками такого размера выполняется процессинг. И чем меньше этот размер, тем больше вероятность того, что обработка данных будет локализована в кэше. При использовании DMA данные передаются только из ОЗУ. Из плеера в драйвер блок передается программно и кэширование работает.

Если в стандартном режиме вывода выбрать максимальный буфер предзагрузки, то работать будет подобно Full Memory - предзагружаться большими блоками, но играть будет сразу. В дальнейшем, скорее всего, в настройки добавится выбор режима загрузки диска целиком или по трекам. Впрочем, если начинать слушать с первого трека альбома, то и сейчас Full Memory x64 должен начинать играть сразу.

В ситуации снижения частоты импульсные помехи становятся менее интенсивными, но более длительными, так как объем вычислений остается тот же. Что из этого будет лучше для звука, я с ходу не знаю - это вопрос для отдельного исследования.

Для DI и FM, я думаю, нет принципиальной разницы - 3 или 8MB кэш.

Например, для стандартного режима воспроизведения - если буфер предзагрузки весь умещается в кэше, то чтение из него будет происходить без обращения к оперативной памяти.

grigoxyr Поддержка воспроизведения с CD дисков в linux версии возможна, но если это будет, то в дальнейшем, в версии с графическим интерфейсом. Но воспроизведение рипа диска из памяти в любом случае прямее по отношению к процессингу тех же самых PCM данных чем проигрывание CD диска на компьютере.

Наверно, чем больше, тем лучше.

m@jor Я имел ввиду кэш L1. Что касается прерываний от контроллера, то при передаче ему данных драйвером стандартным является использование DMA. В этом случае данные считываются из памяти, а не из кэша. Основной процессинг данных, скорее всего, происходит в контексте плеера и его потоков, включая работу кода ядра при приеме драйвером этих данных.

Насчет размера буферов существуют противоположные мнения. Экстремально низкие размеры существенно повышают нагрузку на процессор, что вряд ли чем-то помогает воспроизведению. Чем больше размеры, тем меньше вычислительная нагрузка. С другой стороны, небольшие размеры буферов могут быть оптимальны в том плане, что основная работа с данными будет выполняться во внутреннем кэше процессора. Но для этого, видимо, достаточный минимум - 64/128 фреймов или 128/256. Связаны размеры буферов в том смысле, что размер буфера должен быть больше размера периода в два раза или больше. Способ задания этих размеров в фреймах или микросекундах альтернативен в том смысле, что первый вариант создает буфер фиксированного размера, а второй - буфер, увеличивающийся при увеличении частоты дискретизации.

Адам, настройки можно менять командами с клавиатуры, завершаемыми Enter, при оставленном воспроизведении: pf - размер периода в фреймах, без пробела - pf1024 , pf512, и с другими параметрами аналогично. pt - длительность периода в микросекундах bf - размер буфера в фреймах bt - длительность буфера в микросекундах di - Direct Input mode fm - Full Memory mode pcm - DSD->PCM mode (pcm, pcm44, pcm88, pcm176, pcm352) dop - DSD DoP mode card - выбор устройства вывода (после выбора нужен перезапуск). Графический интерфейс будет доступен позже.

Если задать в семплах и period_size, и buffer_size как period_size * 3, то так и будет. Для всех версий Windows режим вывода DSD потока плеером (PCM/DoP/Native) выбирается одинаково - в панели настроек входного SACD плагина (через "Форматы файлов" в контекстном меню).