willow

Кхм, AdionSoft WASAPI: http://adionsoft.net/winampwasapi/ Maiko WASAPI у меня в подписи. Распаковываем, кладём туда же, куда распаковали плеер. Должен всё увидеть. Про работать не смею утверждать, но видеть эти модули под семёркой обязан.

1) Установить Windows Vista или Windows 7. Обновления желательны. XP не поддерживает WASAPI вовсе, для этой операционки идеальный вариант это ks - и наоборот, ks нестабилен для более новых операционок. 2) Копировать модуль AdionSoft WASAPI или Maiko WASAPI в папку к его dll братьям. Можно (я бы так и сделал) оба сразу, чтобы выбрать что лучше работает. 3) В меню выбор режима вывода звука выбрать интересуемый модуль.

Там, возможно, смена частоты на стыке треков, несовместима с режимом "Gapless mode". Но это, опять же, внутренняя проблема выходного плагина. Профанация! Тогда можно спросить, что же такое иное плеер ожидает от комбо Quit()-Init()? Quit()-Init() успешно завершает gapless переход, после Quit() воспроизведение звука невозможно. Gapless работает только на Close()-Open()

IgorA, Рекомендую на каждый вызов WASAPI цеплять кейс с сообщениями. Если результат функции не ноль, то печатай имя функции, место где приключилась ошибка и её расшифровку. Не без издержек. В своё время лихо подчистил свой код на предмет ненужностей, потом пришлось возвращать дотошный анализ результатов каждого вызова, как было. Ибо когда случится облом, то понять что-то либо будет затруднительно. Теперь почти на каждый чих у меня сообщение. А ещё рекомендую вести лог. Лучше один раз увидеть документальное свидетельство чем сто раз услышать правду пользователя. Всё это немного подъедает память и производительность, но другого адекватного способа отлаживать кернел вывод просто нет. Экстремальные сборки не рулят. Только предельная аккуратность - в основе maiko лежит древний SDK-пример WinAudio от беты висты. Для Win7 в SDK теперь уже четыре современных примера, а WinAudio исключён за древностью. Мне ещё только предстоит их тщательно изучить на предмет получения лучшей совместимости с Win7. Всё как бы и так работает, но kernel есть kernel, всегда в тапки нассыт.

Скоро IgorA придёт к выводу что самое-самое эффективное чтение с диска это объём, кратный размеру сектора и выровненный по секторам. Гигантизм должен пройти и придёт чистое понимание откуда идут накладные расходы. К тому же, процессорный кэш нужно беречь. Эти мегабайты данных, по сути, хлам. Выиграешь в операциях с диском, но проиграешь с памятью. Радикальное улучшение звука (если вообще рассматривать аудио-эзотерику за которой следует бан на некоторых фубар форумах) состоит в максимальном переносе всей работы в процессорный кэш. Работа шин данных и шин управления кроме энергозатратности работает на создание помех разного рода, плавающая электрическая нагрузка, высокочастотные наводки, блокировка аппаратных ресурсов. Скажем, та же аудиокарта также использует DMA процессор который разделяет ресурсы шины с CPU... и с жёстким диском. Однако, аудиокарта это одно из наиболее чувствительных устройств как в плане помехозависимости так и в плане задержек. Это устройство категорически не терпит "подождите, занято" отношения со стороны операционки и системы. Поэтому для операционки и шин снижают кванты времени - но я не рекомендую без нужды опускаться до таких твиков ибо также растёт непроизводительная работа и различные издержки. Лучше просто рационально использовать кэш - но это, как я уже сказал, требуется ещё осознать ибо с не машинным мышлением это не совсем очевидно.

IgorA по загрузу: Сложно сказать, возможно подразумевался ресемплер. Не скажу что-бы он капитально грузил, но это не бесплатное удовольствие, конечно. Всё, что по существу в maiko потребляет процессор - это он. Стараюсь нагрузку держать адекватную, 2-8% на своём AMD X2 4200+ (2200мгц). Загрузка варьируется +-2% в зависимости от коэффициента ресемплирования. Ресемплер даёт нагрузку на одно ядро, никакой параллелизации не предусмотрено. Никаких фантастических 20% и 50% быть у меня не может. Иначе на этом калькуляторе элементарно не пойдут сами седьмые окна или виста. Более того, я даже наличие SSE2 не проверяю - а это уже говорит о используемом поколении процессоров. Человеки, услышьте совет: Если используете maiko и плагина активна (движется шкала заполнения буфера), пожалуйста не ленитесь копировать содержимое Status log в тегах code. Чем меньше неопределённости, тем проще искать проблемы. Input stream: 16 bit PCM encoding in 2.0 (Stereo) setup. 44100Hz rate MAIKO buffer/latency: 3781 samples (85737 µs) Output stream: 24 bit (32bit padded) PCM encoding in 2.0 (Stereo) setup. 96000Hz rate Client buffer: 30720 samples (320000 µs) Client latency: 20000 µs Mixer scheduling period (latency): 10000 µs Minimum device period (latency): 3000 µs Exclusive mode renderer Data route: Maiko mixer Plugin latency reported to Winamp: 96 ms Peak output loudness detected: 0.000000 db

Наверное, эти вопросы стоит адресовать автору плагина а не аплеера. Я тоже замечал, что с майко-плагином проц капитально загружается, например по сравнению с азио. Причём и в режиме EXCLUSIVE и в обычном. Я бы охотно помог, но дело в том, что плагина в отличии от аналогов принципиально не создаёт тредов (параллельных программных потоков) кроме как в момент перехода между дорожками. Управление идёт от входной плагины которая как бы проталкивает данные. Но в случае, если идёт постоянное переполнение, т.е. объём данных значительно превышает потребности в порции, причём постоянно, то maiko как-бы "засыпает", не возвращая управление входной плагине покуда большой кусок не будет кусочками проигран. Со стороны входной плагины кажется, будто запись происходит с лагом пропорциональным переполнению (если вообще её это волнует). В нормальной ситуации входная плагина спрашивает сколько байт можно выводить и выводит именно это или меньшее их количество. Далее идёт ресемплер и/или пересчёт колонок - опционально. В идеале засыпать должна входная плагина, хотя и с выходной проблем быть не должно ибо управляющий поток един. В таком самосинхронизирующемся режиме я цеплял плагину к консольному эмулятору - никаких проблем, maiko помимо собственно звука начинает работать как клок кратный минимальному Sleep (~10ms). Поскольку приходится гонять дворами то накладные расходы растут, 1-2% самый максимум, но не так, чтобы 50-60%. Я же не циклом гоняю, а опрашиваю оборудование, копирую очередной блок или если делать более нечего - сплю 10ms времени - затем по новой.

IgorA, Из уважения, исключительно. Автоматически, по своей плагине приходится саппортом работать и не помнишь к кому на Вы а к кому на ты. Рассчитываю на продолжительное сотрудничество со всеми Вылетал.... ну, грустно, конечно. Такое почти невозможно отловить. Я днями гоняю плагину даже если не программирую, и с ресемплером и без. И звуковушки три стоит. И цифру и аналог на каждой гонял. Cловом, WASAPI, как и KS это драйверы уровня ядра и проблемы у них неборимые, железячные. Неприятно, что ещё и с плавающей точкой проблемы компилятора приходится исправлять и общий баг один с линковкой заборол. Он мне давал искажения в ресемплере небольшие. Разумеется всё работает и без тонких твиков, но для появления ощущения коммерческого ПО приходится код в дизассемблере перепроверять и делать большой объём ассемблерного программирования. Про переключатель - делай обязательно. У меня эта фишка в планах, но так как функциональная обвязка обязывает, то руки не доходят до этого. Сейчас переписываю микшер, очень много радикальных переделок, так что следующая версия нескоро (в ноябре?). В целом плагина будет чуть легче по ощущениям и звук будет чуть лучше, если кто хотел спросить . Ну, а битперфектный режим облегчать уже дальше некуда, так что тут без изменений. Под новый год планирую Push\Pull переключатель

IgorA Push режим говорите? Добро пожаловать в клуб . Открою тайну, большинство WASAPI плагин всё-таки Pull. Это на практике совместимей чем Push, особенно с USB DAC'ами, так что не спешите с выводами. Как работает Shared mode микшер - загадка , но у него похоже что особые привилегии на более низкоуровневый доступ напрямую к драйверу и он обходит наши проблемы. Между прочим, вы же говорили что у вас мой Push не работает , не так ли?

Cox. Задействуй Gapless mode. В момент перехода между песнями устройство вывода закрываться и заново открываться не будет, исчезнет разрыв между дорожками. IgorA Что касается распределённой процессу памяти, которая в воспроизведении не задействована - несколько её мегабайт ничем систему не грузят. Верно. То же самое можно сказать и о всей операционке - сидит в памяти и ничем систему не грузит. Но тем не менее, это оказывает кумулятивный эффект. В основном это нагрузка на виртуальный менеджер, его нельзя считать частью плеера но между тем он участвует в процессе. Поскольку операционка управляет большими блоками памяти, то самый важный момент заключается в максимальном разделении кода играющего и управляющего, рабочего и просто подгруженного. И вообще.. программа висит как работающая но ничего не делает - не верю! Пока жив WndProc программа живее всех живых. Посмотрел по Spy++ - пока плеер никто не трогает, событий нет. Не возьмусь судить о чистоте эксперимента. На самом деле не возьмусь, ибо те же самые службы которые якобы ничего не делают таки потребляют некие ресурсы и уменьшение количества служб ускоряет выполнение активных задач. Ну, например, как операционка определяет жива ли задача или нет ? Об этом можно спросить только саму задачу, больше не у кого. Проявляется это не так явно - но полагаю, что важен масштаб проблемы а имеенно количество ничего не делающих задач что висят на шее у планировщика. Разве в кэш загружается из скомпонованных библиотек код, который не используется? Возможно не понял вопрос. И нет и да. ОЗУ кэшируется блоками. Дальнейший ход мыслей думаю понятен - что в блок включено, то и загружается, независимо от того, есть ли ссылки на остаток или нет. Чем выше кэш уровнем, тем крупнее и он сам и его блоки.

IgorA Интересно. На моей системе (AMD X2 4200+) Boom лежит на нуле. Тот же ProcessExplorer это показывает - даже не дёргается, всегда ноль во время воспроизведения. По памяти выигрыш в два раза. Про вообще не участвует в процессе воспроизведения это понятно. Но не всё так просто, как минимум плеер обрабатывает события Windows а это спам ещё тот. Требуется содержать код плеера в кэшах. Вот сейчас смотрю в Process Explorer - 23Мб - в кэш нереально подгрузить. Понятно, что лишь часть кода требуется одномоментно, но "пухлость" плеера как раз таки способствует интенсификации непроизводительной работы ПК и гарантирует всплески энергопотребления. На макроуровне происходит множество интересных вещей даже если плеер "лишь спит". Чего только стоит переключение задач, огромный объём работы. Плюс, ещё плюс, ещё плюс - никто ничего не делает а компьютер уже шумит по всем шинам и проводникам. Для чистоты звука, с моей точки зрения, наибольший вклад даёт уменьшение потребления памяти (заветная цель полностью влезть в кэш) и лишь потом потребление вычислительных ресурсов.

На скрине выбран out_ds_ssrc.dll. По скрину ставлю неуд. По шкале прогресса - она в Aplayer подделка, анимация, и никак не соотносится с реальным положением курсора проигрывания. Если выходной плагин застрял то плеер об этом не узнает просто потому, что это ему не интересно. Ранние версии Aplayer показывали действительное положение курсора. Сейчас же достаточно точное в слоновьих масштабах, если не учитывать прекэшинги выходной системы, прекэшинги ЗК, и фактический момент старта буфера на ЗК. Попробуй переименовать out_ks363.dll в out_wave.dll предварительно запрятав вcе остальные out_* куда-нибудь. Обычно я переиновываю в out_*.dl чтобы APlayer или Winamp прочие выходные плагины не видели. Проверяем. Если не играет, настраиваем буферы.

Кернел драйверы это просто прелесть. Всё давно отлажено, и тем не менее, проблемы регулярно всплывают CoX Попробуй использовать ASIO4ALL. Хотя, в идеале, лучше добиться рабочего KS - так "правильнее". Для этого хотя-бы сообщи в какой момент возникает ошибка. Также стоит поиграться с размерами буферов, некоторые ЗК (или их драйверы?) чувствительны к этому и действительно "падают" при попытке что-либо проиграть. А как он по звуку в сравнении с A player? Сложно сказать. Ядро-то наследовано 100% от фубар. Однозначно, достойный проигрыватель. Ядро монолитное, флакон всё в одном. Плюсы: компактный, очень низкое потребление памяти и ресурсов. Интересный интерфейс. Минусы: Только DirectSound. Нет шкалы прогресса-поиска, полезная вещь. Edit: Даже не так. Если сравнивать по потребляемым ресурсам c Boom, то APlayer это нечто вроде WMP, в 2-3 раза выше нагрузка на систему. По дисковому пространству раза в 2 уступает. Я смотрю на вещи реалистично, не пытаюсь кого-то унизить, просто намекаю на то, что Delphi это не подходящий язык для плеера. Слишком много накладных расходов выходит. Размер тела плеера со всеми наворотами до UPX упаковки должен быть порядка 100кб. Иначе нужны серьёзные меры. Если UPX значительно уменьшает размер кода значит код дутый. На слух Boom mp3 играет заметно приятней, чем в фубар (за счёт компактности плеера) но увы, я всё равно не переношу этот декодер. Ну, и поддержка только DirectSound существенно ухудшает характеристики Boom под Win7\Vista

Не нужно инсинуаций! Смотрим вкладку Exclusive, флажок Free device when idle. Если флаг стоит, то в остановленном состоянии плагин освобождает устройство (разумеется с риском того, что кто-то его не освободит когда это потребуется плагине). Кто вкладкой Exclusive не интересовался, тот сам себе козявка. P.S. Что скажешь о Boom? Чего-то Питера Павловского пробило недавно на свой альбомный плеер. Результат супер. P.P.S. Проверь, пожалуйста, out_maiko на Windows XP. Есть репорты, что падает. Под XP загрузка выглядит так: LoadLibrary производит упрощённую инициализацию на XP. Раньше функция возвращала NULL, но по какой-то причине я передумал и решил библиотеку-таки грузить. winampGetOutModule() должен возвращать NULL и на этом приключения out_maiko должны заканчиваться.

IgorA Как видишь, обработка всё-таки нужна. Но вот доказывать битперфектным пуристам необходимость в её наличии чрезвычайно трудно. Я обращу внимание на твою маленькую ошибку в терминологии. Входной плагин не может быть совместим с выходным устройством, он может быть совместим с выходным плагином. Здесь вот какая штука, если входной плагин смог прочитать и декодировать файл, то он уже выполнил свою работу на отлично. Всё остальное далеко вне его компетенции. К примеру, для меня далеко не секрет, что некоторые пользователи имеют по два-три одновременно подключенных устройства и скорее всего, и те имеют отличные друг от друга характеристики. Так что твоё решение может стать следующей проблемой. Кто знает характеристики устройства ввода-вывода? - только выходной плагин. Причём что-то он выясняет по ходу дела, прямо во время инициализации воспроизведения, всё это из-за массового распространения устройств с горячим подключением. С точки зрения логики если выходной плагин не смог активизировать воспроизведение в требуемом формате то это его недочёт. Выходной плагин должен уметь подбирать родственные режимы добавляя свою программную обработку-адаптер. Вообще, любая обработка должна идти строго своим чередом, что-то идёт заключительным этапом, тем более квантование, т.е. представление амплитуды сигнала в отрезках равной длины т.е. разрядности. Есть такой эффект, как шум квантования. Он неизбежен. Вот например, если вдруг после твоего переквантования встретится цифровой регулятор громкости, то наверняка произойдёт очередное переквантование. Ну конечно, это всё не критика была, а попытка объяснить ограниченность решения. Тогда уж сделай фантомное устройство воспроизведения, обёртку с обработкой. Так хотя-бы появится универсальность и не будет так сильно заметна местячковость решения. А вообще, поскольку выходной плагин не является выходным устройством, а является чёрным ящиком это всё равно будет непонятным "мутным" решением.

Можно попробовать тон (Вкладка Tone виндовой панели) покрутить. Также можно сменить тип динамика. Я выбираю всегда полнодиапазонные. Разумеется, тесты стоит начать с режима Audio Creation c галочкой Bit-Matched Playback. На X-Fi два FX слота из четырёх заняты неотключаемыми эффектами, не забудьте их придушить (mute)

Пора FAQ составлять.. Галочек всего четыре, но сколько вопросов.. Смотрите вкладку Exclusive, там будет пункт "Slave to input encoding" то бишь по-русски подчинить устройство входной кодировке. Логично, что при активировании галки вычислитель выходного формата для внутреннего процессора будет предпочитать входную кодировку в качестве выходной. Медиатор, переговорщик формата работает так. Смотрит входной формат, Смотрит общий формат, Анализирует накладываемые пользователем ограничения и высчитывает выходной формат так, чтобы он приводил к минимальным потерям и был работоспособен в принципе. Пользовательскими ограничениями можно "уговорить" переговорщика на любой желаемый формат. Копирование один к одному это лишь частный случай. Если входной формат в точности совпадает с выходным, то используется специальная программа копирования. Специальная потому что оформлена как отдельный обработчик единственной задачей которого может быть только копирование. Вы не можете выбрать обработчик. Медиатор может. А вы общаетесь с медиатором настройкой ограничений. Ограничения накладываются во вкладке "Exclusive". Медиатор штука не шибко умная но и не тупая. Если форматы совпадают, он битперфект и без вашего мнения сделает, спасибо. Смотрим названия пунктов: Подчинить входной частоте, Подчинить по каналам, Подчинить по кодировке, Отключить громкость. С точки зрения медиатора это функциональность, он не имеет права произвольно отключать функциональность т.е. ставить галочки за пользователя. Ставя галочки вы говорите медиатору: ДА, мне не нужен ресемплер. Я беру на себя все последствия того, что он выключен. ДА, мне не нужен микшер каналов. Я беру на себя все последствия того, что он выключен. ДА, мне не нужен софтварный аттенюатор. Я беру на себя все последствия того, что он выключен. ДА, я хочу чтобы кодировка на выходе соответствовала тому, что есть на входе. Я беру на себя все последствия того, что преобразований нет. После таких ограничений вполне ПРЕДСКАЗУЕМО выходной фомат будет аналогичен выходному и медиатор, оптимизируя вычисления, выберет отдельный алгоритм копирования. P.S. Копирование возможно лишь с выключенным регулятором громкости. Никаких фубаровских трюков вроде битперфекта с регулятором на максимуме. Побитовая копия в логе отображается так: Exclusive mode renderer Data route: Bit-copy

Venerdi AdionSoft WASAPI плагина работает на обоих машинах?

Интересное наблюдение. А ещё есть такая особенность, что жалуются только на Win7, по Vista у меня не было ни одного замечания. Сам пользую висту без переустановки с того момента как стала продаваться и считаю, что слухи о её глюкавости и супертормознутости несколько преувеличены и содержат ненужные эмоциональные оценки. Что-то не то в семёрке подкрутили. И не могу перейти на семёрку. Не ломается виста и всё тут, уже сколько внезапных отключений питания было, зависаний оборудования - всё нипочём.

Thom_Yorke Не имел дело с этой картой. Посмотрите, может быть, есть есть фирменная панель с переключением мастер-частоты. ASIO всегда идёт через фирменные драйвера и те чаще всего переключает мастер-частоту, для WASAPI же таких гарантий нет. Так происходит на X-Fi. Так происходило на бета драйверах ESI Juli@. Если есть фирменные ASIO, используйте их за образец и точку отсчёта. На профессиональном оборудовании гарантируется их функциональность, в отличии от, к сожалению, всего остального. Ну, у меня есть мысли на этот счёт. В тех WASAPI плеерах, которые работают, а MAIKO в тех же условиях не работает, используется event exclusive метод проигрывания. Это лишь предположение. У меня используется push exclusive. Как соберусь с духом, сделаю еще один рендер эклюзивного режима. В очередной раз масса переделок того, что уже давно должно было работать

Пара заметок: 32 бита может много где работать. Но разумеется, не как бит-в-бит, а с помощью аппаратного дизеринга до 24 бит. Это приправа на вкус, поэтому не стал программно ограничивать выход до 24 бит. 44100Гц в 48000Гц пересчёт стоит избегать. Он очень некомфортный с точки зрения теории. Если уж плагина работает только с пересчётом, то пусть уж лучше в 96000Гц

Thom_Yorke Чуда в полной мере не произошло. Data route: Maiko mixer это значит, что используется полно-функциональный внутренний микшер. По логу работает ресемплер Maiko. Пересчёт из 44100 в 48000. В 0.35 немного подкрутил ресемплер чтобы не красил звук, держался в нейтрале. Эффект улучшения может быть связан с этим. Кроме того, в расшаренном режиме работает стандартный дизеринг винды. Я его тоже не очень перевариваю и в экслюзивном режиме дизеринга нет. Эффект улучшения также может быть связан и с этим. Для лучшего результата (пока) найдите наибольшую поддерживаемую разрядность. Поверьте, я это как создатель плагины вам говорю, функциональные блоки в Maiko высококомбинированные, если работает ресемплер, то всё остальное "за бесплатно". Стерео-в-Стерео и так ничего не делает, его можно и не включать, разницы ровно никакой. Громкость скомбинирована с другими шагами. Лучше используйте регулятор громкости для снятия перегруза перед усилителем для перекомпрессированных альбомов. А разрядность до 16 бит снижать не выгодно, поскольку DAC будет поднимать частоту до 24 бит внутри. Вы получите 8 бит случайного шума в нижнем регистре вместо сигнала. Не важно, что услышать это практически невозможно. Но хоть из принципа. В 32 бит, скорее всего, будет работать аппаратный дизеринг DAC. 24 бит или 24 упакованные в 32 выйдут бит-в-бит с аппаратной точки зрения.

Ресемплер выключен всегда, когда Status log пишет что входная частота равна выходной. Когда используется битперфект, пишется: Exclusive mode renderer Data route: Format adapter Для входных форматов непредставимых аппаратно Либо Exclusive mode renderer Data route: Bit copy Для входных форматов представимых аппаратно Slave to input sample rate when enabled. Когда галка установлена, она игнорирует все установки и ориентируется только на частоту источника. Если галка не установлена, то используется непосредственно заданная цифра-частота выраженная в герцах. К этой константе будет пересчитана любая входящая частота. Если указан 0, то будет использована частота для общего режима, указанная в панели управления Windows. Thom_Yorke, Процитируйте полностью Ваш Status log, пожалуйста. Во время проигрывания.

Thom_Yorke Жесть. Там как раз полный битперфект должен был включиться. Ещё предстоит выяснить что происходит. Ну, если ресемплер включён, то все остальные галки не оказывают сколь-нибудь существенного влияния на звук. Slave to input encoding when enabled, наоборот, ухудшает звук искусственно ограничивая разрядность.

На ноутбуках стоят медленные энергосберегающие пятитысячники. Они не сильно шумят, но это не значит, что их не слышно совсем. Да и у каждой модели свой "голос". На идеальном компьютере нет помех и посторонних шумов. Значит, не будет разницы между плеерами. Но если Вы не слышите шум жёсткого диска, свист блоков питания, значит у Вас идеальный комп и именно для Вас разницы между плеерами действительно нет. Лично я выхожу из метро на 15% контуженный, на 7% после работы за офисным компом, и отчётливо слышу внешние шумы даже в закрытых наушниках, среди всего этого различаю шумы компьютера, LCD монитора и старый электрический счётчик в дальнем конце корридора с его "дзжиииу-дз-дзжииу". Вчера наконец, его поменяли на электронный и теперь гада уже не слышно. И новое пластиковое окно на кухне значительно улучшило звук даже в наушниках. И разумеется, любое серьёзное сравнение нюансов звучания плееров возможно только в два часа ночи. То, что с возрастом слух ухудшается это факт, слух вообще непостоянен и зависит от настроения, биоритмов, от того, поели ли Вы, выспались ли. Ровно как и зрение, нюх. Говорить, что между плеерами нет разницы это слишком обобщающее утверждение. Для этого сначала нужно доказать то, что компьютер является идеальным электрическим усройством. Или за насмешками прячут обиду за то, что какую-то разницу не слышат. А мне вот обидно за слабое зрение, и то, что расплываются автобусные номера, например.