IgorA

Сергей, надо отключить в ap2config опцию "Управлять системной громкостью" (справа внизу на первой вкладке).

Попробуйте этот вариант. Должно быть без артефактов. waveout2.zip

@ndp, проблема была в том, что для вывода через WaveOut не поддерживается остановка из состояния паузы. Проверьте пожалуйста вариант модуля вывода EXTRAS WaveOut с исправлением (надо заменить файл ap2decoder.exe в папке плеера): waveout.zip

@ndp, спасибо, я посмотрю, как работает этот вариант конфигурации и настроек.

А при использовании стандартного модуля вывода из полной версии и out_asio.dll эта проблема тоже наблюдается или нет?

В самом ap2decoder при отработке команды "Stop" циклов нет вообще. То есть, зациклиться с большой загрузкой ядра может только код драйвера. Можно попробовать, как влияют на ситуацию альтернативные варианты опции "Hold ASIO Output".

Возможно, конкретный драйвер плохо переносит последовательный stop/start с коротким интервалом.

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

@AleXH, громкость в диапазоне 0..255 принимается модулями вывода и системным микшером и может при желании управляться в полном диапазоне с минимальной дискретностью через веб-интерфейс. В GUI пиксельный диапазон ввода с регулятора масштабируется к диапазону 0..255.

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

Там цветом фона выделяется полоса, кликом по которой можно вернуть картинку обратно.

@AleXH, 232 в качестве максимального кода передаваемого для позиционирования - это наследие GUI версии, чтобы общий код не менять. Там это физическая ширина полосы прокрутки. 0..255 - диапазон уровней громкости в плеере, в который преобразуется диапазон 0..100 ползунка.

Там все по пикселям отрисовывается, поэтому переделывать уже не буду. Для тех, кому тесны рамки стандартного интерфейса, сделаны UPnP/DLNA рендерер и веб-интерфейс, в котором в HTML разметке можно сделать любые размеры и пропорции.

@AleXH, HTPC окно более емкое. Для Mini его можно взять из полной 2.110. Подходит.

Такая процедура не подходит, если cue содержит несколько файлов альбома (при этом расширения файлов в cue могут не соответствовать реальным). Обработка cue при сканировании папок и так нетривиальная, поэтому усложнять ее дополнительно я не планирую. Модель "папка = альбом" для сканера меняться не будет. Если есть необходимость раскидать контент папки по отдельным альбомам плейлиста, это можно сделать, последовательно открывая cue.

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

@ppy, я отправил. Но на virustotal.com на этот файл 0/61 детектов, включая Avira.

@PilyaSega, да, является.

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

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

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

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

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

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

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