Как включить 3D-звук в играх в Windows 7/8/10
Наверное практически всем известно, что с выходом Windows Vista ещё в 2007 году, а в след за ней и во всех последующих версиях Windows звуковой API DirectSound3D был удален из Windows, вместо DirectSound и DirectSound3D стали использоваться новые API XAudio2 и X3DAudio. Вследствие чего в старых играх стали недоступны звуковые спецэффекты ЕАХ(звуковые эффекты окружающей среды). В этой статье я расскажу, как вернуть тот самый DirectSound3D/EAX во все старые игры, которые поддерживают данные технологии играя на Windows 7/8/10. Конечно, опытные геймеры всё это знают, но возможно кому-то статья будет полезна.
Старые игры не ушли на свалку истории, наоборот они пользуются огромным спросом, как у пользователей старшего поколения, так и у младшего. Старые игры лучше смотрятся на современных мониторах с высоким разрешением, для многих игр выходят моды улучшающие текстуры и шейдеры, но вот со звуком поначалу не повезло. С выходом следующего поколения Windows Vista, вслед за Windows ХР, разработчики Microsoft сочли, что DirectSound3D морально устарел — он имел ограничение в 6-канальный звук, не поддерживал сжатие звука, был процессорно зависимым и поэтому ему пришел на смену XAudio2/X3DAudio. А так как технология ЕАХ компании Creative была не самостоятельным API, как был в своё время A3D от компании Aureal, а всего лишь расширением DirectSound3D — звуковые карты компании Creative оказались за бортом. Если не использовать специальные программные врапперы, то играя на Windows 7/8/10 в старых играх пункты меню включающие EAX будут не активны. А без EAX звук в играх будет не таким сочным, объемным, позиционируемым.
Для решения этой проблемы компания Creative разработала программу-враппер ALchemy, которая перенаправляет вызовы DirectSound3D и EAX в кроссплатформенный API OpenAL. Но эта программа работает официально со звуковыми картами компании Creative и то не совсеми моделями. Например, современная карта Audigy Rx имеющая аппаратный DSP-процессор СА10300 официально не работает. Для владельцев других звуковых карт, например встроенной Realtek, нужно использовать ещё программный-драйвер Creative Sound Blaster X-Fi MB, который стоит денег. Можно ещё попробовать родную программу 3DSoundBack, но она не была закончена компанией Realtek — остановилась на стадии beta версии, работает не качественно и не со всеми чипами. Но есть способ лучше, он проще в использовании и бесплатен.
Первый способ
Начну со звуковых карт компании ASUS. Звуковые карты компании ASUS DGX/DSX/DX/D1/Phoebus базируются на чипах C-Media и даже чипы ASUS AV66/AV100/AV200 — это всё те же перемаркированные чипы C-Media. В характеристиках этих звуковых карт написано, что они поддерживают ЕАХ 1/2/5. Все эти чипы получили в наследство от своего предшественника CMI8738 DSP-блок программно-аппаратный EAX 1/2, EAX 5 уже программный.
Владельцам карт серии Xonar очень повезло, все видели кнопку GX на панели драйвера, но возможно не все знают, что она делает. Покажу на скриншотах из программы AIDA64, вот так выглядит закладка DirectX-звук при не активной кнопке и у владельцев встроенных звуковых карт Realtek в Windows 7/8/10:
Все звуковые буферы равны нулю, все API не активны. А вот сразу после включения кнопки GX мы видим
Т.е. очень удобно — не нужно запускать дополнительные программы, как Creative ALchemy и копировать в каждую папку с игрой файл dsound.dll. Вот возникает большой вопрос, почему так не сделала компания Creative в своих драйверах? Более того, она во всех новых моделях Sound Blaster Z/Zx/AE не использует аппаратный DSP-процессор для обработки ЕАХ, а делает это программно через драйвер по упрощенным алгоритмам. Некоторые люди считают, что программной обработки звука достаточно, потому что современные ЦП намного мощней процессоров звуковых карт 10-летней давности, которые аппаратно обрабатывали звук. Это совсем не так. ЦП оптимизирован обрабатывать х86-команды, а DSP гораздо быстрей обрабатывает звук центрального процессора, как и видеокарта быстрей производит растеризацию, чем ЦП. Центрального процессора хватит для не сложных алгоритмов, а вот качественная реверберация с множеством источников звука будет отнимать слишком много ресурсов даже мощного ЦП, что скажется на падении ФПС в играх. Это уже признала компания Microsoft и уже вернула поддержку обработки звука DSP-процессорами в Windows 8, а также компания Sony, которая добавила в свою приставку PS5 отдельный чип для обработки 3D-звука.
Второй способ
Этот вариант подойдет для пользователей встроенной звуковой карты в материнскую плату, которых большинство. Есть такой проект DSOAL — это программная эмуляция DirectSound3D и ЕАХ с помощью OpenAL(OpenAL должен быть обязательно установлен в системе) не требующая аппаратного ускорения. Если ваш звуковой чип имеет какие-то аппаратные функции для обработки звука то они будут использоваться автоматически. Программа настолько хорошо работает, что через неё ЕАХ заработал у меня на всех старых играх, где есть галочка ЕАХ в настройках. Вот так выглядит окно AIDA64, если скопировать файлы DSOAL в папку программы:
Если же этого не произошло и у вас картинка, как на самом первом скриншоте, значит родной Windows dsound.dll не даёт перехватить API, как это было и в моём случае. Тогда поможет такой метод — нужно будет загрузиться с какого-нибудь Windows Live-CD образа и удалить файл dsound.dll не без помощи утилиты Unlocker (предварительно сделав копию на случай отката) из каталога С:\Windows\SysWOW64 и записать вместо него те самые dsoal-aldrv.dll и dsound.dll. Я так сделал и у меня, как сама Windows, так и все игры работали без сбоев и так даже удобней — не нужно каждый раз копировать эти файлы в папки с играми, в крайнем случае, можно будет вернуть обратно родной dsound.dll на место. Правда такой способ подойдет, если вы не будете пользоваться другими звуковыми картами ASUS или Creative, потому что в этом случае у вас всегда DirectSound3D будет работать только через DSOAL, а не через родной драйвер или ALchemy.
Послушать DSOAL можно в этом видео:
Сравнивая как звучит ЕАХ на разных звуковых картах я с удивлением обнаружил, что на встроенном Realtek ЕАХ звучит лучше, чем на Асусах или на моей Audigy Rx. Если почитать даташиты, то практически все чипы Realtek поддерживают DirectSound3D/ЕАХ 1&2. Запустив AIDA64 из под Windows XP можно увидеть:
Оказывается, Реалтеки в отличии от ASUS и Creative звуковых карт поддерживают ещё какой-то I3DL2 (не в каждом Реалтековском даташите об этом написано). I3DL2(Interactive 3D Audio Level 2) — это открытый промышленный стандарт для работы с 3D интерактивным звуком, это расширение для DirectSound3D для работы с реверберацией и окклюзией. В принципе аналог ЕАХ, но звучит приятней — более приятная реверберация в играх шагов, когда персонаж бежит по пещере или замку, более реалистичное звучание объемного звука в помещениях. Поэтому если старая игра работает на Windows XP то я играю только на ХР, вдруг звуковой движок сможет задействовать I3DL2. DSOAL хоть и открытый проект и его любой может усовершенствовать, но он никогда не сможет задействовать I3DL2, т.к. OpenAL не работает с I3DL2, а только с ЕАХ 1-5. Но есть и хорошая новость — начиная с Windows 8 I3DL2 включен в библиотеку XAudio 2.7. Так что звук в новых играх под Windows 10 будет лучше, чем под Windows 7.
Ну и напоследок хочу напомнить, что все эти технологии 3D-звука разрабатывались для наушников, на 2х колонках вы практически 3D-звука не услышите. Чтобы насладиться детальным звуком наушники уровня SVEN AP860 не подойдут, из недорогих наушников нужно начинать с Axelvox HD 241 — уже будет разница со SVEN AP860, как небо и земля. Вот как-то так ориентируйтесь.
MME, Windows DirectSound или Wasapi
Так im с помощью Audacity и было интересно, какое устройство записи / системы я должен использовать для лучшего качества звука? Есть MME, Windows DirectSound и Wasapi.Im на ноутбуке Windows 7, и я попробовал их все, и я не вижу большой разницы между three.By по умолчанию настройки были на MME.
2 ответов
MME часто является выбором по умолчанию, так как он поддерживается большинством ОС Windows (MME был выпущен в 1991). Между DirectSound и WASAPI нет большой разницы, так как DirectSound-это в основном просто интерфейс, связанный с DirectX, для интерфейса Windows Audio Session API (WASAPI). WASAPI имеет самую низкую задержку из всех (по дизайну) и поэтому должен быть предпочтительным для записи (особенно когда дело доходит до многодорожечного).
«MME: это Audacity по умолчанию и наиболее совместим со всеми аудио устройств.
Windows DirectSound: это более свежее, чем MME с потенциально меньшей задержкой.
Windows WASAPI: этот хост является самым последним интерфейсом Windows, который поддерживает Audacity, между приложениями (например, Audacity) и драйвером звуковой карты. WASAPI был впервые официально выпущен в 2007 году в Windows Vista. WASAPI особенно полезен для «loopback» устройства для записи воспроизведения на компьютере. Поддерживает 24-разрядные устройства записи. Воспроизведение эмулируется с помощью этого хоста. В результате ползунок воспроизведения на панели инструментов Mixer будет масштабировать только текущий уровень ползунка воспроизведения системы вверх или вниз, а не непосредственно манипулировать этим системным ползунком.»
все между кавычками произошло непосредственно от Audacity. Похоже, им было много, чтобы сказать о WASAPI.
Программирование звука в DirectSound
DirectSound — сравнительно новый программный интерфейс, входящий в семейство «мультимедийных» интерфейсов DirectX (DirectDraw, Direct3D, DirectInput и т.п.). Первым продуктом данного семейства является интерфейс Direct Draw, созданный почти одновременно с Windows 95 и предназначенный для оптимизации работы игровых приложений с видеоадаптером. Затем к нему добавились интерфейсы Direct3D, DirectInput, а впоследствии для многих классических интерфейсов с оконечными устройствами были введены Direct-версии.
Название DirectX трактуется буквально — «прямой, непосредственный интерфейс X». Классические системные интерфейсы с видео-, звуковыми и игровыми адаптерами относятся к Windows первых версий, когда внутренняя организация большинства адаптеров была достаточно разношерстной, многие решения находились в стадии отработки, а приложениям требовалось в первую очередь отображать прямоугольные окна, текст и графики, проигрывать длительные непрерывные звукозаписи и т.п. С массовым переходом производителей игр на платформу Windows и развитием видеотехнологий выяснилось, что большинство классических интерфейсов слишком абстрактны, поэтому при работе с конкретным устройством возникают заметные накладные расходы, ощутимо снижающие быстродействие; при частой и хаотичной перерисовке элементов экрана, выводе коротких одновременных звуков выполняется множество лишних операций. Семейство DirectX было разработано именно для того, чтобы приблизить аппаратуру к приложению, предоставив эффективный интерфейс.
Ценой эффективности явилось снижение универсальности интерфейсов, более явная привязка их к определенным схемам и протоколам взаимодействия. Для полной поддержки DirectX необходима установка специального расширенного DirectX-драйвера; традиционные драйверы устройств, как правило, для этого не годятся. В первые несколько лет существования DirectX выпуск DirectX-драйверов часто отставал от выпуска устройств; сейчас этот разрыв практически отсутствует, хотя далеко не все драйверы поддерживают полный набор заявленных функций. В случае появления новых технологий вывода изображения и звука может оказаться, что они не укладываются в схему DirectX, и тогда потребуется серьезная переработка как интерфейсов, так и использующих их приложений.
Интерфейсы семейства DirectX состоят из общесистемной части — подсистем DirectX, с которыми общаются приложения, и набора драйверов с поддержкой DirectX — обычных драйверов устройств, в которые добавлена поддержка новых объектов и функций. Центральной частью любой подсистемы DirectX является HAL (Hardware Abstraction Layer — уровень отвлечения от аппаратуры) — промежуточный интерфейс, который скрывает частные, непринципиальные особенности используемых аппаратных средств, но сохраняет полный контроль над основными, ключевыми возможностями аппаратуры. HAL реализуется на уровне драйвера устройства.
Поддержка DirectX включена в стандартную поставку начиная с Windows 98 и NT 5. В системах Windows 95, OSR2 и NT 4 поддержка DirectX не предусмотрена, однако Microsoft выпускает отдельные расширения для Windows 9x и NT, установка которых восполняет в системе отсутствующие компоненты — собственно подсистемы и распространенные драйверы.
Поддержка интерфейсов DirectX есть в большинстве систем программирования C++, Pascal и Basic, выпущенных после 1995 года. Семейство имеет целый ряд версий; в настоящее время используется версия 7. Если в среде программирования поддерживаются только более старые версии, можно заменить включаемые файлы и библиотеки на более новые, содержащие обновленные версии подсистем, взяв их из новой версии DirectX SDK.
Описания подсистем также имеются в поддерживающих их средах программирования. Более новые версии описаний распространяются Microsoft в составе DirectX SDK. Microsoft поддерживает в Internet справочную систему MSDN Online, где интерфейсы DirectX описаны в разделе http://msdn.microsoft.com/library/psdk/directx/dxstart_1x2d.htm, а сам DirectSound — в http://msdn.microsoft.com/library/psdk/directx/dsover_9dno.htm.
Основные черты и понятия DirectSound
Назначение и структура
Подсистема DirectSound обеспечивает приложениям практически непосредственный доступ к аппаратуре звукового адаптера. Этот факт вовсе не означает, что приложению приходится вникать в детали программирования того или иного адаптера — это остается прерогативой HAL. Вместо этого приложению предоставляется модель современного звукового адаптера, предельно приближенная к реальности, с минимальным уровнем абстракции. При таком подходе общение приложения с адаптером сопровождается минимальными накладными расходами, и в то же время избавляет приложение от излишних подробностей программирования аппаратуры.
Подсистема DirectSound построена по объектно-ориентированному принципу в соответствии с моделью COM (Component Object Model — модель объектов-компонентов, или составных объектов) и состоит из набора интерфейсов. Каждый интерфейс отвечает за объект определенного типа — устройство, буфер, службу уведомления и т.п. По сути, интерфейс представляет собой обычный набор управляющих функций, или методов, организованных в класс объектно-ориентированного языка.
DirectSound не поддерживает звуковые форматы, отличные от PCM. Назначение DirectSound — исключительно эффективный вывод звука, а операции по преобразованию форматов остаются в ведении приложений, которые могут использовать для этого подсистему сжатия звука (ACM).
Смешивание сигналов
Одно из наиболее неудобных ограничений MME/Wave — невозможность проигрывания нескольких звуков на одном устройстве одновременно без их программного смешивания самим приложением. DirectSound снимает это ограничение, позволяя приложению просто задавать несколько источников звука, которые будут проиграны одновременно. Количество таких источников ограничено только доступной памятью и быстродействием аппаратуры.
Объемный звук
Источники звука, работающие в базовой модели DirectSound, могут быть только моно- стереофоническими. Работа расширенной базовой модели, DirectSound3D, основана на другой концепции, позволяющей размещать монофонические источники звука в пространстве. Для каждого источника, а также для самого слушателя, задаются координаты в пространстве, ориентация, направление и скорость перемещения. DirectSound3D обрабатывает все источники и создает для слушателя объемную и реалистичную звуковую картину с учетом интерференции, затухания, направленности, эффекта Доплера и т.п.
В этой статье рассматривается только базовая модель DirectSound. Расширение DirectSound3D будет описано в следующих выпусках.
Использование аппаратных ускорителей
При наличии у используемого звукового адаптера средств аппаратного ускорения (hardware acceleration) — смешивания нескольких источников звука, обсчета трехмерной модели, создания звуковых эффектов и т.п. — DirectSound всю возможную работу старается переложить на аппаратуру адаптера. Использование аппаратного ускорения остается прозрачным для приложения — DirectSound использует возможности аппаратуры там, где это можно, а в остальных случаях выполняет нужную работу на программном уровне. Тем не менее приложениям, использующим большое количество одновременно звучащих источников или сложную трехмерную картину, имеет смысл упрощать свою модель при отсутствии средств аппаратного ускорения, иначе накладные расходы могут существенно снизить общую производительность системы.
Для реализации на аппаратном уровне смешивания и звуковых эффектов необязательно нужен современный адаптер с шиной PCI. Многие комбинированные адаптеры с шиной ISA — семейство Sound Blaster AWE, Turtle Beach Maui/Tropez/Pinnacle, Guillemot MaxiSound — имеют встроенные таблично-волновые синтезаторы с расширяемой оперативной памятью. Если синтезатор свободен и у него достаточно свободной памяти, DirectSound может загрузить туда некоторое количество источников звука и проигрывать их средствами синтезатора.
Конфигурация звукоизлучателей
Для создания реалистичной звуковой картины DirectSound нуждается в информации о расположении звукоизлучателей — громкоговорителей или наушников — относительно слушателя. Для достижения максимального эффекта звукоизлучатели должны быть установлены и настроены правильно, а приложение должно указать используемую конфигурацию подсистеме DireсtSound.
Звуковые буферы
Большинство существующих звуковых адаптеров использует для обмена звуком с центральным процессором звуковые буферы, представляющие собой участок памяти, в который заносятся звуковые данные. Обычно буфер является кольцевым, то есть указатель текущей позиции при достижении конца буфера автоматически перебрасывается на его начало, совершая внутри буфера круговое движение. Адаптер и его драйвер работают параллельно с разными частями буфера, стараясь следовать друг за другом и не создавать конфликтов; если их работа достаточно согласованна — получается непрерывное движение сколь угодно длительного звукового потока.
В отличие от концепции связанной цепочки программных буферов, принятой в MME, DirectSound предоставляет приложению почти прямой доступ к аппаратным буферам адаптера. В этой концепции просто смещены акценты: вывод коротких и повторяющихся звуков значительно упрощается, а вывод длительных непрерывных звучаний несколько усложняется относительно модели MME.
Размещение звуковых буферов
Различные адаптеры используют буферы разного типа. Классические адаптеры типа Sound Blaster, Windows Sound System и совместимые с ними используют буфер в основной памяти компьютера с доступом через DMA. Адаптеры архитектуры Hurricane (Turtle Beach Tahiti, Fiji и совместимые) используют буфер в собственной (on-board) памяти, который доступен в виде «окна» в диапазоне адресов внешних устройств. Существуют также адаптеры со встроенным буфером, доступ к которому осуществляется через порты ввода-вывода; обычно так работают таблично-волновые синтезаторы.
В зависимости от размещения и способа управления различают аппаратные (hardware) и программные (software) буферы. Аппаратным называют буфер, к которому адаптер имеет прямой доступ; такой буфер располагается либо в памяти самого адаптера, либо в основной памяти с обращением через DMA или Bus Mastering. Программные буферы всегда располагаются в основной памяти и управляются центральным процессором, адаптер к таким буферам прямого доступа не имеет.
В документации по DirectSound аппаратными называют только те буферы, которые находятся в памяти адаптера, и нередко путают термин «hardware» в отношении размещения буфера и способа смешивания звука. Я буду пользоваться выражением «аппаратный буфер» — для обозначения буфера в памяти адаптера и выражением «буфер с аппаратным смешиванием», когда речь будет идти о буфере, к которому адаптер имеет прямой доступ при извлечении звука.
Первичный и вторичные буферы
Если в архитектуре адаптера один из аппаратных буферов является основным, его называют первичным (primary). Остальные буферы, занимающие подчиненное положение, называются вторичными (secondary). Обычно звуки из вторичных буферов смешиваются воедино в первичном буфере, откуда и поступают на ЦАП адаптера.
Для адаптеров типа SB/WSS, работающих только с одним буфером, он и является первичным; вторичные буферы могут быть только программными и управляются самой подсистемой DirectSound. И наоборот, для современных многоканальных адаптеров PCI, имеющих несколько равноправных каналов вывода звука, первичный буфер недоступен, зато некоторое количество вторичных может быть аппаратными, и управление звуками в них осуществляет непосредственно сам адаптер.
Чаще всего приложению не требуется использовать первичный буфер. В типовой схеме взаимодействия для каждого источника звука создается свой вторичный буфер (в DirectSound часто отождествляются понятия «источник звука» и «вторичный звуковой буфер»). Впоследствии приложение в нужные моменты включает и выключает звучание источников, меняет текущую позицию в звуке, параметры звучания и т.п. Вторичные буферы могут иметь произвольные размеры, которые задаются приложением при их создании. Даже если смешивание выполняет DirectSound — оно осуществляется на уровне ядра (VxD или системно).
В исключительных случаях возможен прямой доступ к первичному буферу. При этом запрещается использование вторичных буферов — то есть приложение теряет возможность описывать независимые источники звука. Зато наличие доступа к первичному буферу гарантирует, что все изменения в звуковых данных будут услышаны максимально быстро (единицы миллисекунд). Однако первичный буфер имеет фиксированный размер, выбираемый драйвером DirectSound, и размер этот достаточно мал (несколько десятков миллисекунд звучания). Для того чтобы успевать вписывать звук в первичный буфер, приложение должно иметь высокий уровень приоритета. Но даже в этом случае Windows не гарантирует нужной скорости, не являясь системой реального времени.
Статические и потоковые буферы
Вторичный буфер может быть статическим (static) и потоковым (streaming). Статические буферы предназначены для постоянных звуков, цифровое представление которых не меняется либо меняется достаточно редко. Потоковые буферы ориентированы на часто изменяемые звуки, как правило — на представление длительного звукового потока, который по частям «прогоняется» через буфер.
Статические и потоковые буферы различаются только тем, что подсистема старается в первую очередь делать аппаратными статические буферы, загружая их в память адаптера. Таким образом, постоянные и короткие звуки оказываются в распоряжении адаптера, и достаточно лишь дать команду, чтобы они включились в общее звучание.
При желании приложение может явно указывать при создании буфера тип памяти для его размещения.
Порядок создания вторичных буферов
DirectSound оптимизирует использование вторичных буферов в порядке их создания приложением; источники звука, созданные в первую очередь, имеют приоритет в использовании аппаратных средств. Буферы, созданные первыми, подсистема старается по возможности загружать в память адаптера, предоставлять им каналы DMA, ресурсы Bus Mastering и т.п.; при исчерпании аппаратных ресурсов DirectSound переходит на самостоятельную, программную обработку оставшихся буферов.
Управление режимами вторичных буферов
Поскольку каждый вторичный буфер описывает независимый источник звука, подсистема предоставляет средства управления режимами звучания источника. Для базовых источников DirectSound доступно управление громкостью, панорамой и частотой дискретизации; для источников DirectSound3D еще и пространственными координатами, направленностью и скоростью движения.
Набор необходимых для источника методов управления задается при создании буфера и позволяет подсистеме оптимально связывать буферы с аппаратными ресурсами. Впоследствии доступны только заказанные методы управления; для изменения набора необходимо уничтожить буфер и создать его заново.
Позиции в буфере
DirectSound использует для адресации в звуковых буферах понятие текущих позиций, или курсоров. Различают позицию записи/воспроизведения, отслеживающую проигрывание звука из буфера в адаптер или запись звука из адаптера в буфер, и позицию доступа, отслеживающую чтение/запись (обмен данными) между приложением и буфером. В первичной англоязычной документации первая позиция называется Play/Capture Position, а вторая — Read/Write Position, поэтому отсутствуют коллизии между значениями термина «запись». Для обозначения ввода звука извне я также буду пользоваться термином «захват» (capture).
Позиция воспроизведения (play) следует за позицией записи (write) в буфер, а позиция чтения (read) — за позицией захвата (capture). Достижение позицией воспроизведения позиции записи означает полное проигрывание буфера воспроизведения, при этом начинают воспроизводиться «старые» данные, которые приложение не успело перезаписать. Достижение позицией захвата позиции чтения означает переполнение буфера захвата, и последующие данные накладываются на «старые», которые приложение не успело извлечь из буфера.