IgorA
-
Публикаций
5 555 -
Баллов
14 098 -
Зарегистрирован
-
Посещение
-
Победитель дней
15
Весь контент IgorA
-
@Анд_ре, да, сейчас сравнивать можно только на WAV. Но и конвертировать FLAC в WAV - минутное дело. Например, используя xrecode II.
-
Плеер на всех этапах и во всех вариациях остается bit perfect.
-
Олег, пробовать уже можно.
-
Пробный вариант IN_WAVE2 обновился. Новый вариант с исправлениями должен работать стабильнее. Напомню, что перед использованием надо удалить стандартный in_wave.dll из папки плеера.
-
@mnbvvbnm, видимо, где-то есть ошибка при обращении к памяти. У меня в пробных запусках не проявлялась. Я посмотрю, возможно, выложу позже более устойчивый вариант.
-
Плеер загружает approxy (который в установочном комплекте плеера) только при обращении к файлам SACD, DVD-A и TAK. Можно его удалить на время тестирования. Оставить только approxy64.
-
@mnbvvbnm, в x64 сейчас могут конфликтовать файлы approxy / approxy64 поэтому лучше запускать плеер без загрузки approxy (не обращаться в этом сеансе к папкам с SACD, DVD-A и TAK).
-
@mnbvvbnm, а в какой версии плеера (32- или x64) это происходит и с каким выводом?
-
Предлагаю потестировать на примере формата WAV пробный вариант движка для 2.100, использующего разные процессы для загрузки файлов и для воспроизведения. Для использования надо удалить обычный in_wave.dll из папки плеера и скопировать туда три файла из архива. Модули вывода можно использовать любые из комплекта 2.100. Интересуют мнения о наличии и характере отличий в звуке по сравнению с текущей версией. Для сравнения удобно запускать две копии плеера из папок с разными конфигурациями.
-
Если своппинг включен - зачем вообще Full-Memory? Что касается SACD - то там как раз обычно проблемы нет, так как SACD в Full Memory загружается потреково.
-
@firewheel, когда начинаем резать - это уже не Full Memory. По частям файлы уже загружают обычные модули вывода (не Full-Memory). Разумное решение для использования Full-Memory с большими файлами - переходить на 64-разрядную систему.
-
У меня в 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, но благодаря минимизированной архитектуре они могут загружать файлы в память несколько быстрее, чем стандартные декодеры.
