что такое api аудио в играх

Библиотека Oboe для высокопроизводительного аудио в играх и приложениях

Мы добавили в Android Game SDK библиотеку Oboe C++ для работы со звуком. Она позволяет разрабатывать высокопроизводительные аудиоприложения с низкой задержкой для максимального спектра устройств Android. Эта библиотека также отлично подойдет большинству разработчиков игр. О ней и о том как с ней работать в Android Game SDK мы и хотим рассказать в этой статье.

Один API

Библиотека Oboe использует усовершенствованный интерфейс AAudio с расширенными функциями на устройствах под управлением Android 8.1 (API уровня 27) или более поздней версии, а также обеспечивает обратную совместимость (через OpenSL ES) с Android 4.1 (API уровня 16) или более поздней версии. В дополнение к API платформы библиотека Oboe предлагает разработчикам аудиоприложений ключевые функции для комфортной работы, такие как ресемплинг, преобразование форматов и динамическая корректировка задержек. При необходимости она позволяет преобразовывать аудиоданные, например конвертировать число каналов, чтобы повышать производительность выбранных устройств. Также библиотека предлагает обходные решения для других особенностей работы конкретных устройств, что повышает эффективность кода для обработки звука. В двух словах, теперь библиотека Oboe считается рекомендуемым решением при написании кода для работы со звуком на C/C++ для платформы Android.

Интеграция Oboe

Встроить элементы кода на базе Oboe в проект можно двумя основными способами. Если вы используете плагин Android Gradle 4.1.0 или более поздней версии вместе с CMake, а также используете (или можете подключить) общую библиотеку STL, для включения библиотеки Oboe достаточно добавить ее в список зависимостей Gradle, включить объекты prefab и добавить несколько строк кода в файл CMakeLists.

Интегрировать Oboe также можно с помощью статического связывания при помощи Android Game SDK. Сначала скачайте библиотеку и зарегистрируйте ее в системе управления версиями. Работать нужно с minSdkVersion 16 или более поздней версии, а также с NDK 18 или более поздней версии. Затем укажите версию игрового SDK для привязки, которая скомпилирована для заданной комбинации ABI, уровня API, NDK и STL, добавив путь к компилятору в следующем формате:

Основы Oboe

Для воспроизведения звука нужно создать поток с необходимыми свойствами, такими как обратный вызов, который используется, когда потоку требуются новые данные.

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

Подробные сведения об использовании Oboe см. в документации, примерах кода и документации по API. Вы также можете ознакомиться с практической работой, в которой показано создание простой ритмической игры.

Обратная связь

Если вы столкнулись с проблемами, сообщите нам о них через GitHub.

Источник

Пробуем Audio API на примере написания визуализатора

Web Audio API для меня является одной из тех новинок, которыми сейчас напичканы браузеры и с которой хотелось подружиться поближе и хоть как-то проникнуться тем, что же можно с помощью этого натворить. Что бы проникнуться, я решил написать простенький визуализатор аудио.

Но прежде чем начать разбираться непосредственно с Audio API, нам необходимо набросать заготовку нашего визуализатора и делать мы будем это при помощи canvas.

Создание заготовки

Итак создаем холст:

Отлично, холст у нас есть и далее нам надо создать элементы, которые и будут отвечать за визуализацию звукового сигнала. В нашем случае это будут обычные круги:

Функция draw, которая будет рисовать наши круги, выглядит следующим образом:

Собственно, наша заготовка практически готова, остался только конструктор частицы Particle.

Создаем анализатор

Итак, у нас есть все, чтобы начать писать визуализатор. Главную роль будет играть понятие AudioContext. У одной страницы может быть только один контекст, но этого вполне достаточно, чтобы реализовать все, что вашей душе угодно. Практически все методы для создания модулей являются методами AudioContext. Полный их список можно посмотреть тут. Так как спецификация AudioContext до конца еще не одобрена, то создавать мы его будет вот таким образом:

Этого достаточно, чтобы создать AudioContext в Opera, Chrome и Firefox. От созданного нами контекста нам понадобятся следующие методы:

Итак, используя то, что мы выяснили по поводу AudioContext, набросаем конструктор нашего анализатора:

Эта ф-я при вызове создаст нам аудио контекст и интерфейс для анализа данных. Тут видно, что при создании анализатора мы устанавливаем значения для параметров smoothingTimeConstant — частота опроса с которой анализатор будет требовать данные и fftSize — размерность преобразования Фурье (грубо говоря, этот параметр указывает, сколько данных мы хотим получить в результате частотного анализа сигнала, это кол-во будет равно fftSize/2). Функцию Uint8Array мы используем для создания массива с четким указанием границ, в нашем случае его длина будет равна 256.

Пока в массиве у нас шаром покати, но это и не удивительно, ведь нет источника сигнала, который надо анализировать. Добавим в наш конструктор создание audio — элемента, а заодно и подпишемся на событие canplay для него, которое возникает, когда браузер считает, что получил достаточно данных для того, чтобы начать воспроизведение. С учетом этого наш конструктор примет вид:

Нам осталось отправить наш созданный аудио поток в AudioContext и связать анализатор с источником и приемником. Сделать это довольно легко, ведь умные люди, которые создавали Web Audio API, позаботились об этом и благодаря им у каждого audio — модуля есть метод connect, который в качестве параметра принимает значение, к которому и надо присоединиться. Итого, конечный вид будет таким:

Тут стоит упомянуть о AudioContext.destination — это системный звуковой выход по умолчанию (обычно это колонки). Метод getByteFrequencyData — этот метод получает данные от анализатора и копирует их в переданный массив, который мы в итоге и возвращаем, благодаря великой магии замыканий.

Допишем в нашу функцию createParticles создание анализатора, в итоге получим:

Вот и все, мы получили свой простенький визуализатор и немного приоткрыли завесу над Web Audio API. Вся эта прелесть будет работать в Chrome, Opera, Firefox. IE, как и всегда, остается за бортом.
Немного более навороченная демка, в которой использовался данный код: demo
Код демки на github: Analyser
Код на codepen: Analyser

Источник

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

Именно о трехмерном звуке, движках, производителях мы поговорим в данной обзорной статье.

3D-звук подразумевает расположение источников звука вокруг слушателя.

Схематическое изображение того, как эффекты реверберации позволяют на слух определять параметры помещения

Для усиления ощущения при восприятии звука слушателем применяются различные технологии. Именно их качественное воплощение заставляет окружающий игрока мир не просто источать яркие краски, но и превращает его в действительно трёхмерное пространство.

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

Актуальные звуковые API

OpenAL (Open Audio Library)

Этот API использует эффекты EAX. Данный интерфейс задействован в движках id Tech 3 и 4 (DOOM 3, Enemy Territory: Quake Wars, Prey, Quake 4, Wolfenstein), некоторых играх, основанных на Unreal Engine 3, а также в ряде множества других проектов (Battlefield 2, S.T.A.L.K.E.R., F.E.A.R., FarCry, Time Shift и прочие).

Интересно, что компания Creative позволила использовать свою запатентованную технологию обработки теней студии id Software только в обмен на поддержку OpenAL в DOOM 3

OpenAL развивался исключительно программистами Creative. Полноценная реализация наиболее значимых функций и возможностей OpenAL существует только для карт Creative под Windows. Для прочих карт и ОС реализация очень упрощенная, базовая. Всё потому, что это требует наличие аппаратной поддержки, а аппаратный процессор есть только у карт Creative.

Таким образом, если игра использует OpenAL, то звучание на интегрированном звуке на звуковой карте Creative будет разительно отличаться. Разумеется, в пользу последнего. Если же у звуковой карты Creative нет аппаратного процессора, то там используется программная эмуляция до EAX 4.0, не доступная картам других производителей. Хотя данную технологию эмуляции можно лицензировать за деньги даже для интегрированного звука. В то же время EAX 5.0 без аппаратной поддержки не существует. Развитие OpenAL остановилось в 2005 году.

DirectSound

Программный интерфейс, являющийся частью DirectX. Самый старый и распространенный API. Данный API позволяет имеет слабую и ресурсоемкую программную реализацию 3D-звука, которую в играх никто не использует, но зато позволяет задействовать аппаратную реализацию имеющихся эффектов. Таким образом, звучание разных DirectSound звуковых карт отличается.

Интересно, что «аппаратные» вызовы у многих карт реализованы программно. Таким образом, интегрированный звук часто имеет «аппаратный» 3D-звук, реализованный в драйверах. Эта реализация по качеству и возможностям сильно отличается от настоящей аппаратной.

C выходом Windows Vista и значительными изменениями в её архитектуре DirectSound лишился поддержки 3D-звука. Тут возникла одна проблема: многие игры, вышедшие до релиза новой операционной системы, остались без звуковых эффектов. В 2007 году компания Creative разработала технологию Creative ALchemy для X-Fi и Audigy, перехватывающую вызовы DirectSound и транслирующие их в аналогичные команды OpenAL. Благодаря этому старые игры имеют поддержку 3D-звука и EAX в операционных системах Windows Vista и Windows 7. Кроме того компания ASUS предлагает Xonar GX2.5, также позволяющий эмулировать DirectSound в несовременных проектах. Эмуляция ASUS предсказуемо уступает из-за отсутствия аппаратных возможностей в картах этого производителя, кроме того, менее стабильно работает.

В свое время покупатели Windows Vista были сильно озадачены отсутствием 3D-звука в играх. Одна из многих причин, почему хардкорные игроки не спешили переходить на новую тогда операционную систему

Кроме звуковых API существуют ещё и звуковые движки. Это примерно как графические движки, которые отвечают за внешний вид игр. Они представляют собой высокоуровневые функции, сильно упрощающие жизнь программистам. На низком уровне звуковые движки используют базовые функции DirectSound или какого-то другого API по выводу звука.

Наиболее популярные звуковые движки

Ещё семь лет назад FMOD считался «молодым и перспективным», а сейчас активно набирает обороты. Одной из особенностей является мультиплаформерность (поддержка Xbox 360, Playstation 3 и Nintendo Wii) и возможность работать с различными форматами на разных платформах. Уже вышло немало проектов использующих FMOD, в том числе такие хиты как World of Warcraft, Bioshock 1 и 2, Starcraft 2: Wings of Liberty, Mafia 2 и прочие. Также заявлены Crysis 2, Deus Ex: Human Revolution, The Witcher 2: Assassins of Kings.

MilesSS

EAX (Environmental Audio Extensions)

Наконец, остановимся на системе EAX (Environmental Audio Extensions). Сейчас разработчикам доступна EAX 5.0, поддерживающая многие возможности. В частности, именно эта система есть в самом распространённом на сегодняшний день движке Unreal Engine 3. Помимо этого EAX разных версий можно встретить во множестве игр. Грамотное использование потенциала этой технологии позволяет создавать потрясающие звуковые эффекты.

Именно EAX оказал значительное влияние на развитие звуковых карт, способствовал внедрению многих эффектов для создания неповторимой атмосферы. Знатоки помнят, что одной из ключевых особенностей теперь уже культового проекта Thief была не только уникальная игровая механика, но и потрясающий звук. Именно звуковое сопровождение позволяло позиционировать каждый шорох, грамотно оценивать ситуацию, с головой погружаться в мир воришки Гаррета. По меркам того времени это стало настоящим прорывом. Thief: The Dark Project стал одной из первых игр, показавших, что у 3D-звука и технологии EAX есть будущее.

Благодаря технологичному звуку Thief обладал потрясающей атмосферой и был одним их главных поводов покупки звуковых карт Creative

Спецификации разных версий EAX стоит рассмотреть отдельно.

EAX 1.0

Функции по отношению к предыдущей версии

Звуковые карты Creative поддерживающие технологию

Примеры игр, поддерживавших технологию

EAX 2.0

Функции по отношению к предыдущей версии

Звуковые карты Creative поддерживающие технологию

Примеры игр, поддерживавших технологию

EAX Advanced HD 3.0

Функции по отношению к предыдущей версии

Звуковые карты Creative поддерживающие технологию

Примеры игр, поддерживавших технологию

EAX Advanced HD 4.0

Функции по отношению к предыдущей версии

Звуковые карты Creative поддерживающие технологию

Примеры игр, поддерживавших технологию

EAX Advanced HD 5.0

Функции по отношению к предыдущей версии

Звуковые карты Creative поддерживающие технологию

Примеры игр, поддерживавших технологию

Вывод из представленного выше материала напрашивается сам собой, а именно: кроссплатформерность и простота в использовании являются необходимыми условиями для успеха. Всё-таки в нынешней ситуации, когда все издатели (кроме Microsoft, Sony и Nintendo) предпочитают выпускать свои игры сразу на трёх (минимум на двух) платформах одновременно, возможность с лёгкостью применить функции и на PC, и на консолях выходит на первый план. Набравший популярность FMOD тому ярчайшие доказательство.

Производители

Creative

Разумеется, когда заходит разговор о звуковых картах игровой направленности, многим на ум сразу приходит именно компания Creative. За почти три десятка лет своего существования производитель неоднократно преподносил любителям звука приятные сюрпризы, хотя и ценовая политика компании вызывала неоднозначную реакцию. Сейчас в ассортименте компании достаточно продуктов серии X-Fi с привычным PCI Express интерфейсом и с USB, от бюджетной ценовой категории до карт премиум класса.

Auzentech

Корейская компания Auzentech выпускает игровые звуковые карты на чипе Creative X-Fi. Эти продукты обладают интересными характеристиками и подходят и для аудиофилов и для игр, но, к сожалению, у нас про эту компанию мало кто знает и данную продукцию не так-то просто найти в магазинах.

Не так давно на рынке звуковых карт появился ещё один игрок, которого трудно не заметить. Речь идет о компании ASUS, имя которой ассоциировалось с материнскими платами, видеокартами, ноутбуками, оптическими приводами.

Эти звуковые карты разрабатывает и производит дружественная тайваньская компания C-Media. ASUS выступает только OEM-заказчиком и спонсором разработки. С этим связана зачастую нестабильная работа карт ASUS и скромные возможности, что нетипично для других продуктов этого производителя.

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

Источник

Улучшаем звук в играх и возвращаем EAX

Если вам кажется, что звук в современных видеоиграх ужасен и сильно отличается от того, который вы когда-то слышали во времена Windows XP, то, возможно, вам вовсе не кажется и синдром утёнка здесь ни причём. В этом материале мы постараемся разобраться, куда пропал один из важнейших аспектов влияющих на погружение, а также постараемся исправить всё то, что компания Microsoft успела натворить в плане ухудшения звука за 15 лет.

Внимание!

Гайд рассчитан на уверенного пользователя и автор не несёт никакой ответственности, если вы что-то сломаете. Все выполняемые действия лишь на вашей совести.

Содержание

В чём проблема современного звука

Когда-то звук был одним из важнейших аспектов, влияющих на погружение в играх, но современные способы вывод звука сильно отличаются от того, что когда-то считалось незыблемой нормой. Если во времена Windows XP звуковой поток передавался напрямую к аппаратной части через интерфейсы с низкой задержкой, то начиная с Windows Vista ситуация приняла печальный оборот и качество звуковых эффектов начало отходить на второй план. Компания Microsoft, под предлогом обеспечения лучшей совместимости и удешевления консолей, переработала привычную схему вывода звука и добавила весьма длинную цепочку программных вмешательств.

Такие изменения в звуковой подсистеме небыли вынужденными, ибо проблемы с микшером или принудительным изменением всего до 48 кГц не были критичными и спокойно исправлялись в пару кликов пользователем или производителями звуковых карт. Все изменения были лишь желанием Microsoft, которое привело к потерям многих звуковых эффектов (EAX), задержкам, искажениям и смерти рынка игровых звуковых карт. Мы получили реальность, где разработчики просто забили на качественный хардварный звук и переложили всю обработку на программную часть ресурсами процессора, превратив звук в плоское подобие прекрасного, а также лишив множество игр былого шарма.

Что мы потеряли

Одной из важнейших потерь, о которой всё ещё плачут геймеры за 30, является технология EAX. Чтобы не быть многословным и не грузить вас лишней информацией, здесь стоит лишь отметить, что технология EAX работала по принципу современного Ray tracing, но только в плане звука. Каждый звук мог отражаться от объекта окружающего мира и звучать исходя из размера помещения, способности материала передавать и поглощать звук, удалённости объекта и т.п.

EAX использовался во многих популярных видеоиграх — это Half-life, Counter-Strike, Grand Theft Auto San Andreas, Grand Theft Auto IV, S.T.A.L.K.E.R., Doom 3 и т.п. Список игр с поддержкой технологии можно найти здесь.

Хотя сжатие ютуба и влияет на качество передачи, но разницу можно отчётливо уловить, особенно это становится заметно в Doom 3 и Halo: Combat Evolved в определении источников звука.

Как исправить звук в Windows

Существует множество способов исправить ошибки Microsoft и пустить звук напрямую к оборудованию в обход программного вмешательства Windows, но универсальным средством являются только утилиты Alchemy и ASIOALL.

ALchemy Universall — это приложение для восстановления функциональности DirectSound 3D (EAX) на картах от Creative, но в последующем модифицированное для работы с любыми звуковыми картами. Программа работает по принципу ретранслятора, минуя вмешательства со стороны Windows и переводя запросы в OpenAL напрямую.

В основном ALchemy необходим для старых игрушек, но я советую включать приложение для всех игр, ибо если игра даже не поддерживает EAX, то вы всё равно заметите некоторое улучшение играх при использовании ALchemy.
Возможно, лучше всего добавить все игры в ALchemy; если вы не заметите никаких преимуществ или испытываете отрицательные эффекты от использования ALchemy, то просто удалите игру из программы.

Многие встроенные звуковые чипы имеет поддержку технологии Asio, но умышленно или в силу иных причин не задействуют её в своих драйверах. Бесплатная утилита ASIOALL призвана исправить эту проблему.

ASIOALL — это универсальный драйвер разработанный музыкантами для уменьшения задержки ввода и вывода при игре на гитаре. Если вы хотите быть быстрее всех в соревновательных игрушках или вы замечаете, что звук иногда опаздывает за мимикой рта персонажа в игре, то ASIOALL вам просто необходим.

В основном достаточно ALchemy для возвращения качественно звука, но если вас интересуют только задержки ввода и вывода, то достаточно использовать ASIOALL.

Есть ли смысл в EAX сейчас

Несмотря на появление новейших технологий объёмного звучания и 7.1 канального звука, смысл в EAX ещё остаётся, ибо многие проекты, благодаря своим звуковым движкам, имеют скрытую поддержку технологии и только ждут пока вы её активируете. Возможность же современных встроенных кодеков поддерживать-эмулировать версии EAX, позволяет без каких-либо затрат окунуться в настоящее объёмное звучание и обеспечить незабываемый эффект присутствия. Посмотреть список игр по звуковым движкам на наличие скрытой технологии можно здесь.

Выводы

Конечно, обидно, что что-то настолько хорошее, по прихоти IT-гиганта, так бесславно волочит своё существование, но пока остаётся возможность активации настоящего хардварного звука без программных вмешательств и разработчики продолжают использовать EAX в новых проект (Killing Floor 2 [2017]), то надежда, о возвращении хорошего звука продолжит жить.

Источник

Руководство по работе с OpenAL на C++. Часть 1: воспроизводим звук

Вашей игре нужен звук! Наверно, вы уже использовали OpenGL для рисования на экране. Вы разобрались с его API, и поэтому обратились к OpenAL, потому что название кажется знакомым.

Что же, хорошие новости — OpenAL тоже имеет очень знакомый API. Он изначально задумывался для имитации API спецификации OpenGL. Именно поэтому я выбрал его среди множества звуковых систем для игр; к тому же он кроссплатформенный.

В этой статье я подробно расскажу о том, какой код нужен для использования OpenAL в игре, написанной на C++. Мы обсудим звуки, музыку и позиционирование звука в 3D-пространстве с примерами кода.

История OpenAL

Постараюсь быть кратким. Как говорилось выше, он намеренно разрабатывался как имитация OpenGL API, и на то есть причина. Это удобный API, который многим известен, и если графика — одна сторона игрового движка, то звук должен быть другой. Изначально OpenAL должен был стать open-source, но потом кое-что произошло…

Людей не так сильно интересует звук, как графика, поэтому в конечном итоге Creative сделала OpenAL своей собственностью, а эталонная реализация теперь проприетарна и небесплатна. Но! Спецификация OpenAL по-прежнему является «открытым» стандартом, то есть она публикуется.

Время от времени в спецификацию вносятся изменения, но их не так много. Звук меняется не так быстро, как графика, ведь особой нужды к этому нет.

Открытая спецификация позволила другим людям создать open-source-реализацию спецификации. Одной из таких реализаций является OpenAL Soft, и, честно говоря, нет никакого смысла искать любые другие. Это та реализация, которую буду использовать я, и рекомендую вам использовать её же.

Она кроссплатформенная. Реализована она достаточно любопытно — по сути, внутри библиотека использует другие звуковые API, присутствующие в вашей системе. В Windows она использует DirectSound, в Unix — OSS. Благодаря этому она и смогла стать кроссплатформенной; в сущности, это громкое название для обёртки API.

Возможно, вас беспокоит скорость этого API. Но не стоит волноваться. Это же звук, а он не создаёт большой нагрузки, поэтому ему не требуется больших оптимизаций, необходимых графическим API.

Но хватит истории, давайте перейдём к технологиям.

Что нужно, чтобы писать код на OpenAL?

Нужно собрать OpenAL Soft в выбранном вами тулчейне. Это очень простой процесс, который можно выполнить в соответствии с инструкциями в разделе Source Install. У меня никогда не возникало с этим проблем, но если появятся затруднения, то напишите комментарий под оригиналом статьи или напишите в список рассылки OpenAL Soft.

Далее вам понадобится несколько звуковых файлов и способ их загрузки. Загрузка аудиоданных в буферы и тонкие подробности различных аудиоформатов находятся за пределами тематики этой статьи, но вы можете почитать о загрузке и потоковом воспроизведении файлов Ogg/Vorbis. Загрузка файлов WAV очень проста, об этом уже есть сотни статей в Интернете.

Задачу поиска аудиофайлов вам придётся решать самим. В Интернете есть множество шумов и взрывов, которые можно скачать. Если у вас есть слух, то можете попробовать написать собственную чиптюн-музыку [перевод на Хабре].

Кроме того, держите под рукой Programmers Guide from OpenALSoft. Эта документация гораздо лучше pdf с «официальной» специализацией.

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

Обзор OpenAL API

Как я уже несколько раз говорил, он похож на OpenGL API. Схожесть заключается в том, что он основан на состояниях и вы взаимодействуете с дескрипторами/идентификаторами, а не с самими объектами напрямую.

Существуют расхождения между условными обозначениями API в OpenGL и OpenAL, но они незначительны. В OpenGL для генерации контекста рендеринга нужно выполнять специальные вызовы ОС. Эти вызовы для разных ОС различны и на самом деле не являются частью спецификации OpenGL. В OpenAL всё иначе — функции создания контекста являются частью спецификации и одинаковы вне зависимости от операционной системы.

При взаимодействии с API существуют три основных типа объектов, с которыми вы взаимодействуете. Listeners («слушатели») — это местонахождение «ушей», расположенных в 3D-пространстве (всегда существует только один listener). Sources («источники») — это «динамики», издающие звук, опять-таки в 3D-пространстве. Listener и sources можно перемещать в пространстве и в зависимости от этого изменяется то, что вы слышите через динамики в игре.

Последние объекты — это buffers («буферы»). В них хранятся сэмплы звуков, которые sources будут воспроизводить для listeners.

Существуют также modes («режимы»), которые игра использует для изменения способа обработки звука через OpenAL.

Sources

Как говорилось выше, эти объекты являются источниками звуков. Им можно задать положение и направление и они связаны с буфером воспроизводимых аудиоданных.

Listener

Единственный комплект «ушей» в игре. То, что слышит listener, воспроизводится через динамики компьютера. Он тоже имеет положение.

Buffers

В OpenGL их аналогом является Texture2D. По сути, это аудиоданные, которые воспроизводит source.

Типы данных

Чтобы иметь возможность поддержки кроссплатформенного кода, OpenAL выполняет определённую последовательность действий и задаёт некоторые типы данных. На самом деле, он так точно следует OpenGL, что мы даже можем напрямую преобразовывать типы OpenAL в типы OpenGL. В таблице ниже перечислены они и их эквиваленты.

Распознавание ошибок OpenAL

Есть статья о том, как упростить распознавание ошибок OpenAL, но ради полноты руководства я повторю её здесь. Существует два типа вызовов OpenAL API: обычные и контекстные.

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

Возможных ошибок не так много. Объяснения, которые я написал в коде — это единственная информация, которую вы будете получать об этих ошибках, но в спецификации объяснено, почему конкретная функция может возвращать конкретную ошибку.

Затем мы реализуем две разные шаблонные функции, которые будут «оборачивать» все наши вызовы OpenGL.

А теперь то же самое для вызовов alc :

Вот и всё. Обычно вызов OpenAL на C++ выглядит как один из следующих вариантов:

Но теперь мы можем делать это вот так:

Возможно, это выглядит для вас странно, но мне так удобнее. Разумеется, вы можете выбрать другую структуру.

Я не буду объяснять код, потому что это не совсем в тематике нашей статьи; но он очень очевиден, если читать его параллельно со спецификацией файла WAV.

Инициализация и уничтожение

ALCdevice аналогично выбору графической карты. на которой ваша OpenGL-игра будет выполнять рендеринг. ALCcontext аналогичен контексту рендеринга, который нужно создать (уникальным для операционной системы образом) для OpenGL.

ALCdevice

OpenAL Device — это то, через что выполняется вывод звука, будь то звуковая карта или чип, но теоретически это может быть и множеством различных вещей. Аналогично тому, как стандартный вывод iostream может быть вместо экрана принтером, устройство может быть файлом или даже потоком данных.

Тем не менее, для программирования игр это будет звуковое устройство, и обычно мы хотим, чтобы это было стандартное устройство вывода звука в системе.

Для получения списка доступных в системе устройств можно запросить их такой функцией:

В зависимости от того, выполнили ли вы перечисление или нет, ошибка может остановить выполнение программы на дорожках. Нет устройства = нет OpenAL; нет OpenAL = нет звука; нет звука = нет игры.

Последнее, что мы делаем при закрытии программы — правильно её завершаем.

Возможно, вы заметили, что вызовы с alcCall отправляют две копии устройства. Так получилось из-за того, как работает шаблонная функция — одна ей нужна для проверки ошибок, а вторая используется как параметр функции.

Теоретически, я могу улучшить шаблонную функцию так, чтобы она передавала первый параметр на проверку ошибок и всё равно пересылала его функции; но мне лениво это делать. Оставлю это вам в качестве домашнего задания.

Наш ALCcontext

Вторая часть инициализации — это контекст. Как и ранее, он аналогичен контексту рендеринга из OpenGL. В одной программе может быть несколько контекстов и мы можем переключаться между ними, но нам это не понадобится. Каждый контекст имеет собственные listener и sources, и их нельзя передавать между контекстами.

Возможно, это полезно в ПО обработки звука. Однако для игр в 99.9% случаев достаточно только одного контекста.

Создать новый контекст очень просто:

Честно говоря, я даже не знаю, в какой ситуации пригождается передача атрибутов. Ваша игра будет работать на обычном компьютере с обычными звуковыми функциями. Атрибуты имеют значения по умолчанию, зависящие от компьютера, поэтому это не особо важно. Но на случай, если вам это всё-таки важно:

Создания контекста недостаточно. Нам ещё нужно сделать его текущим — выглядит похоже на Windows OpenGL Rendering Context, правда? Это то же самое.

Завершив с контекстом, т.е. при выходе из программы, нужно, чтобы контекст больше не был текущим, а затем уничтожить его.

Единственная возможная ошибка от alcDestroyContext такая же, как и у alcMakeContextCurrent — ALC_INVALID_CONTEXT ; если вы всё делаете правильно, то не получите её, а если получаете, то с этим ничего нельзя поделать.

Зачем проверять наличие ошибок, с которыми ничего нельзя сделать?

Воспроизводим наш первый звук

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

I am the protector of this system!

Итак, откроем IDE и используем следующий код. Не забудьте подключить OpenAL Soft и добавить показанный выше код загрузки файла и код проверки ошибок.

Компилируем! Компонуем! Запускаем! I am the prrrootector of this system. Если вы не слышите звука, то снова всё проверьте. Если в окне консоли что-то написано, то это должен быть стандартный вывод потока ошибок, и он важен. Наши функции сообщений об ошибках должны подсказать нам строку исходного кода, сгенерировавшую ошибку.

Найдя ошибку, изучите Programmers Guide и в спецификацию, чтобы понять, при каких условиях эта ошибка может быть сгенерирована функцией. Это поможет вам разобраться. Если не удастся, то оставьте комментарий под оригиналом статьи, и я попробую помочь.

Загрузка данных RIFF WAVE

Это относится к коду загрузки wave. Важно то, что мы получаем данные, или как указатель, или собранные в вектор: количество каналов, частота дискретизации и количество битов на сэмпл.

Генерация буфера

Вероятно, это выглядит для вас знакомым, если вы когда-нибудь генерировали буферы текстурных данных в OpenGL. По сути, мы генерируем буфер и притворяемся, что он будет существовать только в звуковой карте. На самом же деле он скорее всего будет храниться в обычной ОЗУ, но спецификация OpenAL абстрагирует все эти операции.

Итак, значение ALuint является дескриптором нашего буфера. Помните, что buffer в сущности является звуковыми данными в памяти звуковой карты. У нас больше нет прямого доступа к этим данным, поскольку мы забрали их из программы (из обычной ОЗУ) и переместили в звуковую карту/чип и т.п. Аналогичным образом работает OpenGL, перемещая текстурные данные из ОЗУ во VRAM.

Определяем формат звуковых данных

Звуковые данные работают так: существует несколько каналов и есть величина битов на сэмпл. Данные состоят из множества сэмплов.

Для определения количества сэмплов в аудиоданных мы делаем следующее:

Что удобным образом можно преобразовать в вычисление длительности звуковых данных:

Вернёмся к format — нам нужно сообщить OpenAL формат звуковых данных. Это кажется очевидным, правда? Аналогично тому, как мы заполняет буфер текстур OpenGL, сообщая, что данные находятся в последовательности BGRA и составлены из 8-битных значений, нам нужно сделать подобное и в OpenAL.

Чтобы сообщить OpenAL о том, как интерпретировать данные, на которые указывает тот указатель, который мы передадим позже, нам нужно определить формат данных. Под форматом подразумевается то, как его понимает OpenAL. Существует всего четыре возможных значения. Есть два возможных значения для количества каналов: один для моно, два для стерео.

Заполнение буфера

В конце мы просто удаляем данные, которые получил загрузчик wave. Зачем же? Потому что мы уже скопировали их в звуковую карту. Нам нет необходимости хранить их в двух местах и расходовать драгоценные ресурсы. Если звуковая карта потеряет данные, то мы просто снова загрузим их с диска и нам не нужно будет копировать их для ЦП или ещё кого-то.

Настройка Source

Вспомним, что OpenAL по сути является listener, слушающим звуки, издаваемые одним или несколькими sources. Ну, теперь настало время создать источник звука.

Честно говоря, некоторые из этих параметров задавать необязательно, потому что из значения по умолчанию вполне нам подходят. Но это показывает нам некоторые аспекты, с которыми можно поэкспериментировать и посмотреть, что они делают (можно даже поступить хитро и изменять их со временем).

Сначала мы генерируем source — помните, это снова дескриптор чего-то внутри OpenAL API. Мы задаём pitch (тон) так, чтобы он не изменился, gain (громкость) делаем равным исходному значению звуковых данных, позицию и скорость обнуляем; мы не зацикливаем звук, потому что в противном случае наша программа никогда не завершится, и указываем буфер.

Помните, что разные источники могут использовать один буфер. Например, враги, стреляющие в игрока из разных мест, могут воспроизводить одинаковый звук выстрела, поэтому нам не нужно множество копий звуковых данных, а только несколько мест в 3D-пространстве, из которых издаётся звук.

Воспроизведение звука

Очистка

Так как мы просто воспроизводим звуковые данные один раз и выполняем выход, то удалим ранее созданные source и buffer.

Остальная часть кода понятна без объяснений.

Куда двигаться дальше?

Зная всё описанное в данной статье, уже можно создать небольшую игру! Попробуйте создать Pong или какую-нибудь другую классическую игру, для них большего и не требуется.

Но помните! Эти буферы подходят только для коротких звуков, скорее всего, длительностью несколько секунд. Если вам нужна музыка или озвучка, то потребуется потоковая передача аудиоданных в OpenAL. Об этом мы расскажем в одной из следующих частей серии туториалов.

Источник