IgorA

Проблема только в том, что WASAPI для XP не существует.

А как надо - отказываться воспроизводить 32 бита? На самом деле 32 бита часто требует сам аудиодрайвер в режимах вывода ASIO и WASAPI. Поэтому с точки зрения плеера целочисленные 32 бита с выхода декодера могут быть именно тем форматом, который не требует дополнительных преобразований. Чаще всего целочисленный 32 битовый формат является контейнером для 24-битовых оцифровок, дополненных младшим нулевым байтом, который ничего не меняет и не искажает. То есть, это по сути транспортный, а не воспроизводимый формат. Еще используется удобный для DSP формат 32 бита с плавающей точкой (float). При воспроизведении он обычно преобразуется в целочисленный формат. В фубаре 32 float - стандартный внутренний формат. Декодеры фубара всегда выдают 32 float, а при передаче драйверу этот формат преобразуется в целочисленный.

64-разрядный ap2config нужен только для настройки 64-разрядных VST плагинов. В остальном его заменяет 32-разрядная версия.

@Anubis, тогда получится усложненный конструктивно режим Full Memory, работа которого и сейчас сводится к пересылке полностью декодированных данных из оперативной памяти в буфер драйвера без использования буфера плеера. А если больше нравится звук Direct Input, можно и сейчас использовать Direct Input с виртуальным диском. Кто-то так уже делал, используя bat-файл для автоматизации копирования альбома на виртуальный диск и загрузки в плеер.

Что касается сравнений с другими плеерами. Мне XMPlay нравился больше всех остальных плееров, пока я не начал делать вторую версию своего. Об этом я даже написал у них в форуме в мае 2010-го (сообщение #59). Однако у меня при его использовании заметен эффект компрессии. Реверберация в записи несколько подавляется и уменьшается воздух/объем. Например, на prime test CD (t=1004653) хорошо заметно в треках 6, 7, 30, 38.

Не забыл, но давно не обновлял. 2.103 там с главной страницы доступен.

Сейчас слушаю через внешний ЦАП с асинхронной USB платкой Amanero на борту. Но послушал на волне последнего обсуждения, и, действительно, некоторая разница в версиях 2.101 и 2.104 слышна и у меня. Откуда она берется в этом случае и как пролазит на выход - трудный вопрос. Код движка фактически тот же, в процессе воспроизведения потребляемые ресурсы и динамические характеристики совпадают. Но на слух, разница, вроде бы, от файла ap2decoder. С 2.104 звук несколько ближе/артикулированней. Мне 2.104 больше нравится.

В 32-разрядной версии ASIO EXTRAS FM код, работающий с данными, не менялся, начиная с 2.101 по финальную 2.104. Сдвигу там взяться неоткуда. Впрочем, можно перехватить и исследовать поток, непосредственно отдаваемый драйверу ASIO, используя ASIO4ALL + VAC.

@Chris Rea, я использую последнюю версию, доступную на странице плеера. Однако за исключением реализации режима Full Memory (в особенности для ASIO x64) версии 2.101 - 2.104 используют единый звуковой движок и наблюдаемые где-то кем-то различия в их звучании скорее определяются внешними и не учитываемыми факторами или являются субъективными. От 2.101 до 2.104 существенно менялся модуль approxy, но в Full Memory он выгружается из памяти в начале воспроизведения, а для тех, кого беспокоит добавленный в approxy DSP и VST процессинг, в актуальном комплекте есть исходные минимизированные версии approxy в папке EXTRAS.

Я АЧХ не меняю.

Там ничего не менялось. Поэтому причина не в обновлении. Настройки могут не сохраняться, если плеер размещается в 'Program Files' и запускается не от имени администратора.

@Chris Rea, если значения будут равными, то буфер при каждой записи в него будет полностью заполняться новыми данными. Так обычно не делается.

@Chris Rea, такая терминология используется только в Linux ALSA. buffer time - размер буфера драйвера (длительность звучания данных в буфере). period time - периодичность обновления данных в буфере. Типовое значение period time - половина buffer time. Чем меньше эти значения - тем меньше задержка воспроизведения, чем больше - тем выше стабильность воспроизведения. Оптимальные значения могут быть разными для разных конфигураций.

В третьей версии будет оперативный доступ к набору плейлистов, но, возможно, не через вкладки, а через список.

@sinak, а я пояснил, что изменение 19.10 заключается в одном байте, не участвующем в воспроизведении. Поэтому вполне вероятно, что хуже у Вас играет тот же плеер, но из другой папки, или тот вариант, который запускается вторым по порядку (или первым). Проверьте, будет ли сопровождаться рокировкой звука рокировка файлов ap2decoder.exe в сравниваемых папках. Вполне вероятно, что не будет. А версии местами поменяются.

В обновлении от 19.10 единственное изменение - в коде модулей ap2decoder.exe поменялся один единственный байт, который на что-то влияет только в случае, когда слишком долго не запускается процесс approxy.exe. В этом случае ожидание без сообщения об ошибке длится дольше, чем в прежних версиях. Поэтому моя версия ответа на вопрос о причинах изменений в звуке: причина этого явления - болезненная мнительность отдельных слушателей. И заразная.

@Conrad, в этом списке выбирается не драйвер, а устройство вывода. И "Первичный звуковой драйвер" всего лишь обозначает устройство, выбранное в настройках Windows по умолчанию. Оно же всегда встречается дальше в этом списке. При любом из способов выбора этого устройства результат изменяться не должен.

Общие настройки уже доступны в общем конфигураторе. А в отдельных конфигураторах - настройки опциональных альтернативных модулей из папки EXTRAS.

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

Размер буфера из asio_x64_config.exe работает, если в ap2config.exe выбран режим воспроизведения "Стандартный". Некоторое неудобство (непрозрачность) в этом есть, но так сложилось в процессе поэтапной эволюции структуры плеера.

Кто-б ещё-бы написал такой readme В readme уже описаны особенности буферизации в каждом из режимов:

Размер буфера из asio_x64_config,exe учитывается только в стандартном режиме. В Full Memory и Direct Input режимах этот буфер не создается. Влиять может только размер буфера драйвера из "ASIO Control Panel".

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

Я, что мог объяснить, насколько способен, объяснил уже выше.

Речь о практической проверке с помощью Light Alloy - какие комбинации клавиш приходят в программу при нажатии кнопок пульта. Если они соответствуют назначенным клавиатурным, все должно работать. Это не понятно?