IgorA

У меня в Process Monitor размер занятой памяти не меняется. И в коде движка только пересылки данных, выделения памяти там нет. Если утечка в коде конкретного драйвера - это его проблемы.

@firewheel, эта проблема возникла после вчерашнего обновления или наблюдалась и ранее?

@AleXH, декодер такой, но, может быть, APlayer.exe не последний? У меня актуальный вариант при выборе не первого трека стабильно стартует на паузе. Для стандартных Full-Memory декодеров, работающих с выходными плагинами, тоже добавлена поддержка запуска с произвольного трека.

@AleXH, а используется выходной модуль ASIO-Full-Memory или STD-Full-Memory + out_asio.dll? Для последнего варианта требуется отдельная адаптация, он пока работает как раньше. Обновление коснулось специализированных модулей вывода Full-Memory-ASIO, KS, WASAPI.

@AleXH, в ASIO Full-Memory декодерах была частичная несовместимость с запуском с произвольного трека. Сейчас они обновились.

@AleXH, можно, но поскольку в HT два виртуальных ядра на одно физическое, проще добавить опциональный параметр DoubleCore = 0/1, который по умолчанию будет 0, а при значении 1 будут заниматься два последних ядра, если их вообще больше двух.

Так было до 2.100. В 2.100 концепция изменилась - в основном из-за претензий к басу в 2.99. Буфер предзагрузки в 2.100 на порядок меньше, подкачка чаще. Gapless поддерживается для стандартного декодера, работающего с выходными плагинами и для комбинации "не-full-memory декодеры из EXTRAS + не-direct входные плагины".

@AleXH, похоже, легче будет сделать, чем продолжать сопротивляться

@AleXH, GUI в этом не участвует. Видимостью индикатора прогресса управляет Full-Memory декодер из другого процесса.

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

Для меня текущая реализация Full Memory хороша тем, что это дополнительная опция для желающих ее использовать, которая не требует никаких изменений в проекте GUI плеера. То есть, интерфейс плеера даже не задумывается, с Full Memory он сейчас работает или чем-то другим. Переделку GUI для адаптации к Full Memory я не планирую. Разных декодеров в комплекте плеера и так уже слишком много - их там 16.

@APECR, с 4-мя логическими ядрами много мороки - распознавание физическое/логическое будет работать не везде и потребуется динамическая загрузка DLL из-за неподдерживаемой в старом API функции GetLogicalProcessorInformation. Проще в биосе отключить HT, если хочется полностью занимать физическое ядро. Вот с 8-ю ядрами (пока) просто, так как можно исходить из количества ядер.

@APECR, я могу добавить простой патч для i7 - если ядер 8, то занимать два последних. Программная проверка наличия Hyper-threading для разных конфигураций усложнит код и не совместима с XP SP2.

В папке EXTRAS\direct_input есть текстовый файл "Direct input.txt". Там, в частности, сказано: В папке EXTRAS\direct_input размещены специализированные версии входных плагинов, которые реализуют воспроизведение без использования буфера плеера, если для воспроизведения используются модули вывода из папки EXTRAS - ASIO, KS, WASAPI (но не Full-Memory версии). То есть, с Full Memory модулями эти плагины работают в режиме Full Memory, но благодаря минимизированной архитектуре они могут загружать файлы в память несколько быстрее, чем стандартные декодеры.

Не конфликтует.

Правильно. С этими плагинами загрузка файла в память может выполняться немного быстрее.

@firewheel, нет, не использует. Там смысл в минимизации пересылок данных и размера обрабатываемых блоков данных, что позволяет более эффективно использовать кэш процессора.

@CAH91, Но в таком случае Single Core не будет работать, я правильно понимаю? И еще вопрос: при использовании direct input есть ли смысл single core + full memory? В документации написано "если для воспроизведения используются модули вывода из папки EXTRAS - ASIO, KS, WASAPI (но не Full-Memory версии). Или это относится только к wasapi? Если Single Core запустить без опции "от имени администратора", он тоже будет работать на одном ядре и "разгонит" с него обычные процессы. Но это ядро смогут использовать системные службы. Если запустить Single Core от имени администратора, то используемое плеером ядро полностью разгружается, но восстановление штатного режима потребует перезагрузки. direct input и Full Memory - два полярных по смыслу решения. В первом случае буфер плеера исключается из работы, во втором - он вмещает в себя весь файл. Но direct input входные плагины будут выполнять свою роль по декодированию файлов и при их использовании с Ful Memory модулями вывода.

Я поправил DVD-A плагин. Можно обновиться.

Софт для качественной перекодировки может посоветовать По проблеме с русскими символами я посмотрю.

@Ilia555, достаточно будет не запускать Single Core от имени администратора. Тогда вновь запущенные после закрытия плеера программы смогут использовать ядро, которое занимал плеер. После запуска Single Core от имени администратора восстановить нормальный режим использования ядер можно через перезагрузку.

Для чайников все просто и так - нажать кнопку "пуск" и слушать. Настройки - от лукавого

Документация к плееру представлена файлом readme_ru.txt в основной папке плеера и текстовыми файлами в папках дополнительных модулей. Информация , которую я здесь сообщал, отвечая на вопросы, там есть.

Параметр buffer_std в файле aplayer.ini - это тот же Preload buffer, но он только для стандартного декодера, работающего с выходными плагинами out_xxx.dll. Этот параметр не используется декодерами из EXTRAS, для которых Preload buffer задается в собственной панели настроек.

В режиме Full Memory Preload buffer не используется и эта настройка не влияет на работу. Preload buffer также не используется с direct input входными плагинами при выводе через обычные ASIO, KS и WASAPI декодеры из EXTRAS.