Извините, ничего не найдено.

Samodelkin · 01.03.2014, 23:47

Короче удалось более менее настроить - рывков нету, работает довольно плавно 40fps на одном ядре (без звука приложение 45fps дает).

Значит что я сделал:
* Размер вторичного буфера сократил до 100мс, то есть каждые 50мс он догружает новые данные.
* Микшер я сделал так что он обрабатывает данные порционно, например при 60fps (17мс на каждый кадр) блок в 50мс проигрывается в течении 3 кадров. Для блока в 50мс нужно обработать ( 44100 * 2канала / 20 ) семплов и это кол-во делиться на 3 и в каждый кадр вызывается функция микшера которая обрабатывает 1/3 от этого блока, и на третий раз она вызывает запись в буфер устройства.
* Таким образом теперь лучше заточено под вызов обработки микшера в каждом кадре.

На что следует обратить внимание:
* Во первых основная проблема - латентность. Возникает из-за того что микшер находится до самого устройства вывода. То есть мы не можем сначала загрузить звук в буферы, а затем в любое время смикшировать и вывести. И если например в случае музыки всё предсказуемо, то например нельзя наперёд знать когда игрок выстрелит или сделает другое действие требующее звукового сопровождения. С другой стороны создание слишком маленького буфера требует очень частого его обновления и получается что сама пересылка данных и потери в интервалах между вызовами функции обновления (в каждом кадре) занимает больше времени чем проигрывание этого мелкого буфера. Я примерно подобрал оптимальное значение - 100мс. При низком fps (< 30)всё равно начинаются проблемы, но это можно исправить вынеся звук в отдельный поток.
* Второе это собственно многопоточность - как ни крути она должна здесь быть, потому что даже мелкомягкие так рекомендуют делать. Воспроизведение звука в отличии например от вывода графики рассматривается как внешнее действие, а значит должен существовать поток который должен его контролировать (также как это делают для сети или когда хотят сделать нелагающий курсор мыши).
* Третье это собственно скорость микшера. Потому что имхо: раз у нас софтварный микшер значит нам доступен весь объем рамы, а это значит что мы не связаны ограниченным набором звуков которые можно воспроизвести без подгрузки в буфер, и как следствие преимущество должно быть в богатом и разнообразном звуковом сопровождении, но для этого нужен быстрый микшер. Вот.

mr.DIMAS · 02.03.2014, 00:09

В аттаче исходники последней версии с попыткой сделать реверберацию "в лоб" ( давно это было ). При воспроизведении звука создаются дополнительные источники. Из источника звука кидаются лучи в рандомном направлении. Вычисляется задержка для каждого дополнительного источника = расстояние_до_точки_пересечения / скорость_звука. Вот тут основной косяк как и с физикой в буллете( из-за него объекты как невесомые ) - нужно иметь меши с размерами в метрах - разумные размеры то есть. Метод "в лоб" работает - но довольно медленно естественно. Еще в движке косяк с амплитудой складываемых звуков - при куче вопроизводимых звуков появляется хрип - амплитуда завышена и обрезается.

Samodelkin · 02.03.2014, 21:32

Ок.

Я в общем то на mingw собираю поэтому мне приходится код переписывать местами, но я заодно его подробно разбираю.

Перенес микшер новый с потоками - намного лучше. fps по моему совсем не падает, и второй поток особо на нагружается.

Еще в движке косяк с амплитудой складываемых звуков - при куче вопроизводимых звуков появляется хрип - амплитуда завышена и обрезается.

Думаю как раз HDR нужен: амплитуды можно в 4 байтах int или даже float обрабатывать, а перед записью масштабировать (не обрезать) в 2 байтный семпл. Ну я сам это и попробую тогда.

Так вот там в кодах инициализируется первичный буфер dsound - он вроде нигде не нужен.

Есть код где не освобождены некоторые интерфейсы и кое-где пропущены delete на соответствующие new.

ExitThread для С++ вроде не нужен - он для С.

С 3д и реверберацией пока не разбирался - мне нужно своё приложение доделать чтобы была возможность получать доступ к мешам, чтобы было на чем проверять.

mr.DIMAS · 03.03.2014, 23:58

С 3д и реверберацией пока не разбирался

Как начнешь - дай знать. Это самая интересная часть звукового движка. Я тут уже давал ссылку на GSound - и дам еще раз - ибо двиг просто шикарен. GSOUND

Но код слиииишком сложный и навороченный, хотя может ты и разберешься.

К читабельному виду его можно привести только этой тулзой - AStyle

Samodelkin · 04.03.2014, 02:28

Я пока разбираю твои коды, ничего нового не добавлял - мне нужно понять то что уже есть. Я думаю еще 1-2 дня нужно.

Так вот там в кодах инициализируется первичный буфер dsound - он вроде нигде не нужен.

Я первичный буфер убрал.

А также ещё пачка репортов:
* Макросы IS_SHORT_EVEN и IS_SHORT_NOT_EVEN по моему ты местами перепутал, ведь num & 1 даёт true для нечёта.
* Также ты используешь abs в расчётах с float, но abs округляет до целого числа - нужно использовать fabs из cmath.
* Еще я заметил что в Sound::getSamples теперь currentSample сначала преобразовывается к целому числу и затем определяется чёт/нечёт, это я так понял сделано специально для того чтобы плавающий pitch не сдвигал выборку на один семпл в противоположные каналы?

В общем будет неплохо если поделишься статьями и материалами (кроме msdn), которыми ты руководствовался когда все это делал, чтобы у меня был примерно такой же ход мыслей для лучшего понимания.

Но код слиииишком сложный и навороченный, хотя может ты и разберешься.

Да помню этот двиг, я его даже хотел вместо твоего заюзать

Коды глянул - как будто чел прогал на шарпе, эти методы размером больше экрана прямо инлайном вбивались. Оформление отвратительное.
Тут конечно каждому свое, может кто то любит чтобы за него всякие AStyle'ы делали.
Я же привык все сам форматировать.

То что касается твоего двига: целесообразно уже С++11 использовать, а также std - в 11 там всё отлично. И поменьше юзать расширения msvs - ведь потом проблемы с переносом будут (но и не делать всё универсально - в msvs есть свои плюшки). Я взял за основу конвенцию кодирования idSoftware и доработал под свои требования - стараюсь её придерживаться - вот она (ru/en, en - обычно свежее).

Посмотрим как дальше пойдет, если двиг будет перспективный (какие у тебя планы то? блиц3д в том числе?) то можно в репозиторий залить.

mr.DIMAS · 04.03.2014, 14:16

* Макросы IS_SHORT_EVEN и IS_SHORT_NOT_EVEN по моему ты местами перепутал, ведь num & 1 даёт true для нечёта.

Блин, так и есть.

* Еще я заметил что в Sound::getSamples теперь currentSample сначала преобразовывается к целому числу и затем определяется чёт/нечёт, это я так понял сделано специально для того чтобы плавающий pitch не сдвигал выборку на один семпл в противоположные каналы?

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

В общем будет неплохо если поделишься статьями и материалами (кроме msdn), которыми ты руководствовался когда все это делал, чтобы у меня был примерно такой же ход мыслей для лучшего понимания.

DSP for braindead

Посмотрим как дальше пойдет, если двиг будет перспективный (какие у тебя планы то? блиц3д в том числе?) то можно в репозиторий залить.

Можно продолжить писать двиг, просто останавливает то, что инфу по реверберации\дифракции сложно раздобыть .

Samodelkin · 05.03.2014, 22:46

С твоими кодами более-менее разобрался.
Реверберация работает.
Однако, мне кажется архитектура не удачна (видимо делалось в спешке) - например класс Sound я щитаю не должен отвечать за свои копии звуков в эхо,
должен быть какой то общий класс (например сцена) который создает/управляет/перемещает звуки в зависимости от ситуации и событий в сцене.

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

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

DSP for braindead по ходу читаю.

Кстати мелкомягкие уже забили на dsound - рекомендуется например xaudio2 - я думаю нужно посмотреть, может там тоже можно без оверхеда делать.

mr.DIMAS · 06.03.2014, 22:16

Однако, мне кажется архитектура не удачна (видимо делалось в спешке) - например класс Sound я щитаю не должен отвечать за свои копии звуков в эхо,
должен быть какой то общий класс (например сцена) который создает/управляет/перемещает звуки в зависимости от ситуации и событий в сцене.

Просто для меня эта дорога - дикий лес. Никогда доселе не делал звуковые движки и уж тем более реверберацию. Архитектуру поправил бы если бы не забил на двиг.

mr.DIMAS · 11.03.2014, 00:02

Решил поискать литературу по обработке звука( в т.ч. реверберации ) и нашел довольно годный учебник

PHYSICAL AUDIO SIGNAL PROCESSING

Samodelkin · 11.03.2014, 02:41

Почти уверен, что чел, делающий GSound, понятия не имел обо всём этом что в книге.
Можно использовать как справочник.

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

В целом такой алгоритм вроде должен работать, при условии что размеры трисов несколько меньше чем длины лучей и размеров препятствий;
В случае больших трисов будут проблемы:
* например препятствие загораживает только центр триса, однако он сам такой большой что звук должен проходить - тут нужно кидать дополнительные лучи (рэндомно или по краям триса);
* если слушатель и источник находятся рядом друг к другу и близко к очень большому трису, например длинной стене, понятно что отражаться будет только от той части триса которая рядом, а не от всего триса;

Так что в таких случаях придется искать другие алгоритмы или тесселировать геометрию.

ЗЫЖ готовлю демку, пока в ней ничего нового по части звука нет - будет проверяться просто работоспособность моего игрового движка и интеграции звука в него (с игровым куда больше проблем чем со звуковым

).

mr.DIMAS · 13.03.2014, 01:18

Сдул пыль с движка и пофиксил те баги, которые ты указал + оптимизации мелкие. В общем продолжил его писать.
Если оставить расчет реверберации в движке как есть( именно принцип ), то сразу возникает вопрос - а не слишком ли накладно создавать копии источника звука в местах пересечения лучей с геометрией( именно так сейчас и сделано ). Сейчас в двиге на каждый пространственный источник приходится максимум 32 источника отраженного звука. Даже если сделать искусственное ограничение на количество звуков - например 256, то получается что в микшере будет находиться аж 32 * 256 = 8192 источника и если посмотреть на функцию GetSamples то ситуация кажется унылой - просто дохерища расчетов. Может это и лечится SIMD и распараллеливанием, но мне кажется такой подход слишком избыточным, хотя и правдивым с точки зрения физики. Так же сей метод позволит учитывать дифракцию( огибание препятствий ). В итоге ситуация либо либо.

Насчет GSound. Таки этот двиг - дипломный проект этого чувака.

Samodelkin · 13.03.2014, 02:44

Еще один баг здесь:

ulong leftSampleIndex = IS_SHORT_NOT_EVEN( sampleNumber ) ? sampleNumber  : sampleNumber + 1;
sample16 leftSample = buffer->getShort( leftSampleIndex );
ulong rightSampleIndex = IS_SHORT_EVEN( sampleNumber + 1 ) ? sampleNumber + 1 : sampleNumber;
sample16 rightSample = buffer->getShort( rightSampleIndex );

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

Вот как у меня:

const uint32_t leftSampleIndex = ( sampleNumber & 1 ) ? sampleNumber + 1 : sampleNumber;
const int16_t leftSample = bfr->getShort( leftSampleIndex );
const uint32_t rightSampleIndex = ( ( sampleNumber + 1 ) & 1 ) ? sampleNumber + 1 : sampleNumber + 2;
const int16_t rightSample = bfr->getShort( rightSampleIndex );

Обрати внимание что если левый семпл берется sampleNumber+1 то правый должен быть sampleNumber+2, а не sampleNumber+0.

//====================================

8192 звучит пугающе. Особенно если учесть что дискретизация 44кГц, а не 60fps как если бы графику считали. Однако 256 источников это чересчур, в игре в среднем 8-16 одновременно работающих в пространстве. Может быть в стратегиях или каких-нибудь arma их больше, но там нету такой качественной обработки. Получается 16 * 32 * 44100 = 22,579,200 вызовов микшера за секунду. Если бы обсчёт был на шейдерах то вполне потянуло бы, на цпу (без интегрированного гпу) скорей всего нет.

Однако нужно прежде всего сделать демку чтобы было от чего отталкиваться и примерно понимать насколько надо ускорить вычисления.

С другой стороны у меня же работал 1 источник с 32 кратным эхо и это грузило одно ядро меньше чем на половину, simd теоретически дает 4х в 32битном и 8х в 64битном приложении, на практике скорей будет в 3 и 6 раз быстрей. Так что вроде как в одно ядро может с десяток источников влезть.

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

mr.DIMAS · 16.03.2014, 14:29

Очень хорошее подспорье - исходники OpenAL.

http://rghost.ru/53096581 - для винды
http://rghost.ru/53096728 - софтварный рендеринг - там есть alcReverb.c - просто подарок

там есть и функция микширования программного - alu.c

Samodelkin · 17.03.2014, 02:57

___rayine_sound_demo___

//==========================================

А внутри:
build_echo - демо с одним 3д источником в центре комнаты и случайной реверберацией;
build_music - демо со стерео музыкой;
source - исходники rayine;

//==========================================

Короче ничего нового тут нет!

У меня с игровым движком неисчерпаемые траблы - там надо делать, переделывать и доделывать.
Это не быстро.
Так что звук меня немного подождет - пока подумай как дальше.
Например мы можем каждый свою версию делать обмениваясь логикой алгоритмов, а затем смотреть что у кого лучше и объединять, или мы можем сразу делать общий код, но тогда давай создавай репозиторий и конвенцию кодирования (можешь ту что я кидал раньше, если устраивает).

Думаю когда зачищю баги то соберу тест с 32 источниками звука и реверберацией.

mr.DIMAS · 23.03.2014, 14:22

Суть такова. PHYSICAL AUDIO SIGNAL PROCESSING - потратил 5 дней на чтение. И получил очень хорошие результаты. Использовать в движке нужно обычный программный ревербератор + эхо. С ревербератором разобрался - благо есть STK, а там очень понятный код. STK опять же от той же конторы что и книга выше.

В EAX используется три вида ревербераторов - для ранних отражений, для поздних, и для эхо + модулятор выходного сигнала. У меня пока один - для ранних отражений.

А вот raycasting нужен для определения параметров ревербераторов + генератора эхо. Кидаем лучи во все стороны от источника - определяем объем помещения, подкручиваем параметры ревербератора и вуаля, звук просто персик.

В итоге материала по реверберации оказалось предостаточно - как обычно плохо искал

Код пока выкладывать не буду. И демку тоже. Нужно допилить интерфейсы ко всем компонентам и собрать технодемку.