有哪些國內的遊戲使用了音頻引擎來做音頻部分的開發？比如FMOD和wwise?
個人理解，使用音頻引擎並不只是像以前遊戲的一般做法，將音效和音樂簡單地放入遊戲中，而是可以有針對性地進行程序化的設計。鑒於國內遊戲的水平越來越高，所以想了解一下國內遊戲的音頻部分的情況。
我的回答分幾個部分，先回答題主，再澄清其它答主回答中的一些問題。
=======================
第一部分：回答題主
=======================
採用 Wwise 的已面世遊戲一般在 Audiokinetic 官網上有：
Customers | Audiokinetic
以下是部分截至 2016 年底已面世的採用 Wwise 的中國遊戲（首字拼音升序排列）：
《崩壞3rd》《崩壞3》官方網站 - 為世界上所有的美好而戰
《滄翼幻想》滄翼幻想_滄翼幻想官網_滄翼幻想禮包_下載_攻略_當樂網
《赤潮》赤潮 官方網站 Red Tides Game Science
《刀鋒鐵騎》刀鋒鐵騎官方網站-騰訊遊戲
《火炬之光》移動版 《火炬之光》移動版官網--火炬不熄 冒險不止
《劍俠情緣手游》劍俠情緣手游烏鎮年度江湖盛典-劍俠情緣手游―官方網站―翠煙少林全新門派現世
《劍俠世界手游》劍俠世界手游-遊戲官網-劍俠情緣系列最新大作
《夢想召喚王》夢想召喚王
《全民斗戰神》全民斗戰神-官方網站-騰訊遊戲-騰訊首款變身戰鬥手游
《天魔幻想》天魔幻想- 騰訊遊戲
《天天酷跑 3D》天天酷跑3D - 官方網站 - 騰訊遊戲 - 史詩級3D跑酷手游，即將盛大開測！
《王者榮耀》王者榮耀-王者榮耀官方網站-騰訊遊戲
《御龍在天》御龍在天官方網站-騰訊第一國戰網遊-騰訊遊戲
《主公不可以》主公不可以_主公不可以攻略_官網_禮包_武將_下載-4399手機遊戲
===============================================
第二部分：關於 Wwise 從遊戲程序中實時輸出 CPU 監測信息
===============================================
無意介入關於 Wwise 和 FMOD 的「優劣」爭論，但要澄清一下， @薛喬 對 Wwise 監測完整信號鏈的指控是錯誤的。在 Wwise 通過程序輸出 CPU 監測的問題上，另一位答主 @我是鉛筆盒說的是對的，感謝這位答主。
如 @我是鉛筆盒所說，Wwise SDK 中有 API 可以直接輸出所有性能分析信息，引用 @我是鉛筆盒 的回答：
「AK::SoundEngine::StartProfilerCapture, profile的所有結果都能輸出，包括CPU。」
現在分析一下 @薛喬 的指控：
「還監測完整信號鏈呢，A級授權的wwise你讓程序給你實時遊戲裡面輸出一個CPU佔用試試？」
翻譯一下也就是說他覺得「A 級授權下，Wwise 不能在遊戲程序里實時輸出 CPU 佔用」。並且他引用了 Audiokinetic 社區問答的一篇帖子來佐證「從程序不能輸出 CPU 佔用」的指控，但實際上他曲解了帖子的意思，被引用的帖子如下：
來源：Audiokinetic的社區問答
Is there an API to get CPU profile and usage information in real-time?
0 投票
My programmer would like to be able to get CPU usage metrics on the WWise engine with more resolution than watching the GUI"s graph. I"ve scoured the API docs, but can"t seem to find something appropriate.
最新提問 7月 16， 2014 用戶: Brian S. (100 分)
It"s possible, it requires a Level B license with the Sound Engine source code access. If you have this type of license, you can write to us in support, and we will share the implementation details.
最新回答 7月 16， 2014 用戶: Bernard R. (Audiokinetic)
事實上，Wwise 可以通過 API 從遊戲程序輸出 CPU 在內的全部性能分析結果（在可以實時聯機觀測這些信息基礎之上的另一項功能）。但此用戶關心的不是「能不能」輸出 CPU 佔用信息，而是能不能「按自己的 metrics（度量）」來輸出結果，也就是對測量解析度做用戶定製。這是一個高級需求，要改變引擎源碼來實現；而 Wwise 的引擎源碼目前只對 B 級授權及以上提供。所以大家可以看出，這個跟所謂「非要 B 級以上授權才能輸出 CPU 佔用」是兩回事。
再貼一遍正確的回答， @我是鉛筆盒的回答：
「AK::SoundEngine::StartProfilerCapture, profile的所有結果都能輸出，包括CPU。」
以上說法都可以在對應的 Wwise API 文檔里得到驗證：
（參考：StartProfilerCapture）
AKRESULT __cdecl AK::SoundEngine::StartProfilerCapture ( const AkOSChar * in_CaptureFileName )
Start recording the sound engine profiling information into a file. This file can be read by Wwise Authoring.
Remarks:
This function is provided as a utility tool only. It does nothing if it is called in the release configuration and returns AK_NotCompatible.
Parameters:
in_CaptureFileName Name of the output profiler file (.prof extension recommended)
也就是說只要不是遊戲的發布版本（Release 版，你不希望玩家都能 profile 你的遊戲），那麼你就可以用這個 API 輸出所有的「Profiling information」（性能分析數據），接著這些數據可以拿到 Wwise 設計工具裡面去解讀和圖示。這些和授權沒有任何關係。
希望本人的拙答能幫大家進一步理解 Wwise 性能分析功能，澄清之前的爭論所帶來的誤解。
項目做中間件評估，結果隊友給我發了這個問答貼（-_-!!）我用了挺多年中間件，以前項目里用fmod，後來wwise比較多。首先得說如果沒有中間件，程序和聲音設計師基本很難合作，設計師的要求絕對超出一般遊戲程序員的能力範疇了。我以前寫程序，畫面的事情已經夠忙活的了，要寫聲音底層光filter里一個傅里葉分析演算法就得評估半天。
然後看了這裡的討論，覺得幾個問題得說得不太明白，補充一下，免得誤導。只說事實，無意爭論，有誤請海涵，有不同意見請輕拍。
------------------------------------------
「枚舉那句話我第一次看你寫是真沒看見，就算你寫了這一句。說的跟你在wwise裡面就不需要約定state和rtpc對應值似的，回頭你們的程序要索引，呵呵你還要來一遍，更不要優化用法到底用變數查表還是用字元串好了。
你用的值和你用的字元串請問是你定義的還是你跟你們項目組統一的？如果你用的是grass字元串而你們項目用的是savanna是不是別人還要對一遍？說的跟你定了grass你們項目組的所有草地都叫grass似的，回頭來你們的策劃表還是用整形變數記錄數據，然後他們又來跟你對一遍，那麼是不是白做工？最後要不要回到枚舉類型上？回到枚舉類型上到底約不約？」
用fmod的枚舉字元名和你的值是你手寫的吧？wwise是工具自動輸出的。是，改名無論怎樣都得兩邊說好，但手動約定枚舉類型名稱的話，得程序那邊自己定義，開發改來改去出錯可能性比較大。
Wwise的
Event整型id 和 game sync 枚舉變數，只要你選了generate header file，定義就會在soundbank打包的時候自動生成，映射是唯一的，絕對不會出人為錯誤。你能保證整個團隊都嚴謹到很少出現溝通錯誤？不太現實吧，Wwise
直接給了一個規範化的枚舉操作，能保證不出這類手誤，這流程多科學。
------------------------------------------
「還監測完整信號鏈呢，A級授權的wwise你讓程序給你實時遊戲裡面輸出一個CPU佔用試試？你該不會不知道fmod有sandbox而且已經為了一些蠢比集成到Studio界面了把？還不說可以用JS自己寫界面。
#「Profiler-Performance Monitor-Audio Thread CPU不夠用？需要極其精準的CPU佔用，還不願意通過網路埠通信監測，License A，照您這需求為啥Wwise不直接扔到Github上去呢？至於FMOD Studio的sandbox，以及FMOD SoundSystemFMOD Studio API
WindowsinFMOD Profiler.exe，您自個想想吧，怎麼通信的，本身佔用又怎樣」
我倒是想請教你一下，wwise都有Profiler，而FMOD不僅可以在事件級profile，還有lowlevel的profile，還可以API直接出開銷。我為什麼要用非得在扔Github或者買B級以上授權才能解決的Wwise？錢多燒的還是事兒少閑的？
FMOD的配置文件結構都是XML，你自製工具自製界面上天都可以。」
我用過wwise
A級和C級，還有免費版，安裝文件都一樣，功能也是一樣的，包括 profiler。你說wwiseA級授權不能在 Profiler 裡面網路通信輸出CPU佔用，有具體例子么？另外Wwise所有工程內容一早就都在work
unit文件里，,wwu也是XML文件，自己寫界面足夠用了。去看看視頻講座，很多遊戲公司都這麼用的。以前Fmod designer工程是二進位的就不行。而且Wwise
的 profiler 也有API 支持啊，你用AK::SoundEngine::StartProfilerCapture, profile的所有結果都能輸出，包括CPU。
------------------------------------------
「還完整廠商技術支持呢，這麼多年了終於在15年的版本裡面wwise加入了可憐的batch功能，就這都讓無數音頻設計師要面對100
200個Wwise裡面的參數設置需求——你知不知道FMOD可以批量拖放批量調整100個改音量的需求可以在10次滑鼠操作以內搞定啊？
#那就，這屆程序員不行？？？又可以管觸發，又可以設數值，又可以側鏈，又可以觸發ADSR，那能10次滑鼠操作以內搞定batch 100個參數的取值範圍嗎？
為什麼不可以？
fmod 內操作
1、批量選中100個事件——按住shift滑鼠點第一個事件，按住shift滑鼠點第最後一個事件：兩下
2、添加一個參數，設定取值範圍——滑鼠右鍵點出菜單，選擇add
parameter，輸入取值範圍：滑鼠兩下，鍵盤刪除鍵兩下，輸入數值若干
總計滑鼠4下，鍵盤2~6下？
關於你一再強調的dsp channel
fader的性能開銷的問題，我不說FMOD，我就想問Wwise的容器音量音高低通高通你用不用，調不調，調的多還是調的少。就算你調的少，為什麼wwise在content editor裡面還要專門把這幾個屬性顯示列出來——大概他們是為了方便對比這幾個值看著都是0而不是為了快速調節是吧？
很可惜wwise的開發者也知道大部分設計師要的工作模式，再不斷往這方面改進，不管是加入批量編輯功能，還是在content editor顯示需要快速調節編輯的屬性。」
Wwise一直都有multi-edit，批量改數值很方便啊，還有list-view，你說的batch是去加上的批量重命名（其實之前也可以直接在.wwu里批量改）。那個音量就按你說的情況，wwise也可以用5下操作完成，你例子裡面那200個對象是連在一起的所以可以按shift來選，Wwise
裡面同樣批量選中，右鍵要麼Ctrl Shift+F選list view，再ctrl A全選就可以批量改任何數值了，總共四個點擊加快捷鍵，5下操作。不是連在一起的話分批拖進來就成。list
view的數值列還能自定義，還有增量修改，音量輸入」6-」就能批量拉掉6dB。批量隨機化用multi-edit也可以。你說的Content
editor，任何層級上有需要調整的東西，Wwise 都允許批量改，而且一次修改多少屬性都行，根本不用到界面上去找。
要說批量修改最好的還是wwise里的屬性繼承加積累，改一個上層對象就把下面的都改了（不明白可以看它自帶的Limbo工程），如果你隔了一陣想起來要給這100個對象改一個值，按你的方法非要選中100個對象吧，過會兒再來n次，累計起來就是N
x M次滑鼠點擊了，還不算滾上滾下找末尾文件費多少時間。在wwise里用繼承的話始終是N x 1。
------------------------------------------
「所有與遊戲內有參數傳遞的行為FMOD只有一個set parameter介面，Wwise則有set RTPC與set
switch兩個介面」
多少程序員哭著喊著希望功能行為可以歸一化，亂七八糟的api能少一個是一個。FMOD一個parameter又可以當爹又可以當媽，又可以管觸發，又可以設數值，又可以側鏈，又可以觸發ADSR，在這裡成了缺點。深刻懷疑你跟了多少項目。」
Fmod里parameter數值不區分離散和連續，只能按連續的浮點型考慮。設計師明明腦子裡想用的是「輸了贏了」這樣的狀態，為什麼要把這種離散概念換成一個數值，或者連續的範圍？而且只有parameter的話所有情況下都關心連續數值，不管變數離散還是連續，跑遊戲的時候效率會成問題啊（-_-!!!）。區分連續和離散的參數還有配套的api的話引擎內部就可以直接針對優化了。Wwise裡面的state只關心全局，switch還關心對象，RTPC只在需要聲音連續變化的時候用，優化直觀效率也比較高。
還有一個程序可讀性問題，你可以追求api少，那在fmod只有一個setparameter
api類型情況下，你程序的可讀性就全依賴參數命名了，如果工作交接後來的人要看清楚哪幾句是切選項，哪幾句要傳連續數值，如果沒有api類型提示，命名再不清楚的話，你就只能問給參數起名的人了吧？回來看wwise的setswitch就不會，哪怕設計師switch名字沒起好（雖然有自動枚舉其實不太可能）我也看得出來是在幹嘛。
wwise這種設計我覺得概念和性能意圖都很清楚，不是只有一個「參數」，也沒有走極端給你100個參數型。跟遊戲通信的時候離散的概念用switch和state，連續數值的東西交給rtpc，都給設計師包圓兒了。api的數量和介面，Wwise一直只有上面說的那3-4個，很穩定，程序員要懶得用setter還可以讓設計師事件封裝一下，程序員只知道postEvent()就可以了。
------------------------------------------
「可別提wwise實例查找問題了。最開始我接觸wwise的時候覺得這東西真厲害，可以智能管理自己體系下的實例，後來一用就發現被騙了。如果你希望智能的搜索一下實例，那麼你必須向Wwise傳遞GameObject的信息，然後按照他給的編程規範來，而有GameObject這一級概念的引擎——比如說U3D，自己已經有強大到不行的對象智能搜索功能了，再用wwise裡面自帶的多此一舉。結果又回到起跑線上了。」
不知道你要的「智能」搜索是什麼？第一隻要是搜索就總得有「搜索關鍵信息」，不管GameObject.Find樹查找用文本關鍵字，還是GameObject.FindGameObjectsWithTag要給標籤。第二隻要程序員關心實時性能，你說「搜索」他肯定皺眉頭，你說的搜索指的是前者？看看u3d對這個的官方性能說明：「You should avoid calling this
function every frame eg. MonoBehaviour.Update for performance reasons. A common
pattern is to assign a game object to a variable inside MonoBehaviour.Start.」。再看這個Unity Devs, stop using GameObject.Find!，能明白嗎？所以除了性能差還有耦合性問題。那改用後面那個tag的api吧？再看看U3d官網說明：Tags
must be declared in the tag manager before using them，你要自己去定義這些tag的，所以不明白你如果不「按照他給的編程規範來」的話是想怎麼個智能法？Wwise這樣一一對應的註冊方法比u3d早多少年，都不用你自己去手動定義tag，直接傳你遊戲引擎里的對象地址就行，性能和概念上都很清楚，也就是一種「tag」，拿到id就拿到發聲體對象了，還不用你手工輸入定義tag，何來「回到」起跑線？什麼是「起跑線」？
u3d也不是唯一的遊戲引擎，你感興趣的
wwise的 game object實際上就是發聲體，是跟所有遊戲引擎里相應的概念都能掛上的。不管你引擎里對象是什麼系統，wwise離開u3d照樣轉，所以u3d誕生之前多少年開始到現在各種商用自研引擎里都有用中間件。這個是遊戲引擎和音頻中間件功能方面比較典型的問題。
Wwise分game
object和global範圍，設計師可以控制得更準確，要是沒有的話就沒法做3D 定位，事件也沒那麼靈活了（u3d是沒有事件系統的）。其次正因為U3d沒給音頻畫好你所說的聲音設計和整合的「起跑線」才給了wwise這樣的中間件用武之地。前面說了wwise的u3d整合里game
object可以自動掛到u3d的game object上，不用編程，所以gameobject上沒看出你說的「起跑線」問題，如果非要脫離實用性來爭誰先誰後（完全沒必要吧），前面已經說了。
------------------------------------------
「1. 你以為批量就只要批量改改音量。所以批量添加事件，批量設置隨機化，批量2D3D切換批量其他參數修改就無所謂了——我先跟你說wwise要批量改這些都麻煩的要死，反正我是沒找到好辦法，歡迎哪位大大教我一下，花錢學謝謝！
2. 是不是音效按照響度表導出來然後放到遊戲里就萬事大吉了啊？那你讓動作遊戲怎麼辦啊？那這一批大怪全部變小怪我是不是要瘋啊？對當然是流程不對了，策劃怎
么砍需求呢，老闆怎麼能發瘋說這批怪不行全部重做呢對不對？甩到遊戲里哪兒用微調啊不都應該在DAW裡面把該做的全部做好么是不是」
wwise批量剛看清楚了吧，你列的這幾個批量都在裡頭吧？批量事件還可以直接導excel表，他們有個101教程針對新手的你可以看看（不用謝~）然後Wwise支持任何層級音量微調，支持用響度設計替代電平表，動態混音也夠全吧，ducking旁鏈、snapshot,
HDR 。。你還需要啥別的？
------------------------------------------
「對一個event instance設置pause 和 post一個pause event，前者暫停行為與暫停對象的耦合關係都在遊戲的代碼里，後者在音頻引擎里"
請不要用這麼文縐縐的語言鬼扯，好像pause event不要程序看情況來觸發一樣。我想說的很簡單，你要用程序觸發，不管你觸發的是pause event還是把這個pause event掛在某一個event作為post event，都是需要遊戲裡面的代碼來走的，只要要走，請告訴我setpause和你做一個event來post event的本質區別。
其實回到起跑線上沒關係，無非就是pause的wwise某一具體實例這個事情辦不了，要pause就會查找到全局所有的同名實例一起pause。然而在不那麼好的編程下，會出現wwise裡面能pause，到了遊戲里卻pause（這個pause可以是你的event行為裡面的任何一種）不了，這種情況我遇到了不止一次了。於是又要寫代碼，改代碼。
好了我知道你的重點是，不管怎麼說我，wwise可以在脫離程序員的情況下。pause我的音頻呀？那麼我再把我的結論跟你理順一下
1、pause一定是一個動態觸發的行為，就是要遊戲來確定什麼時候pause。固定條件的那就不叫pause了。
2、既然要動態觸發，那就不是你在wwise裡面寫的腳本可以管理的，或者說這個管理沒有意義。甚至可能會因為你在wwise對某一具體實例進行pause操作但是跟你遊戲的代碼衝突而無法執行。
3、恭喜你又回到原點了」
你說的「pause的wwise某一具體實例這個事情辦不了，要pause就會查找到全局所有的同名實例一起pause」 不明白是什麼意思？這麼基本的功能，Wwise里肯定能pause具體實例的，pause
event 可以選global還是game object，postEvent也給了gameobjID參數。id顧名思義就是一一對應的，在事件action里pause後面選game
object，程序就可以暫停任意實例了。「在不那麼好的編程下」是說「程序員沒寫對程序」嗎？看不懂。你遇到了「不止一次」的問題，給個具體例子看看？
Fmod的setpause
調用和 wwise的post 一個「只做 pause」 的 event 是沒有本質區別，但實用性上還是差多了，Wwise的事件還可以干好多事兒，各種pause，resume了再pause再resume都可以，或者其它的set
RTPC，volume還能post 其它 event，所以只要是event整合好了，加上sync，之後程序就不需要重新編譯，程序員也不太需要干別的了。問題不在pause這個原點，而是在設計師可以走得更遠。
順便，要有比wwise更好用的我們肯定也會用的。
先聲明沒用過wwise，只用過FMOD studio以及microsoft xact，所以不對Wwise做任何評價。
作為一個不接觸程序、策劃腳本設計，純粹只管音頻文件製作、封裝以及音效配置，而且是跟著公司持續的線性做項目的人（我呆過的幾家公司都不是做換皮頁游和手游真是對不起，單個項目音頻文件數大於5000，bank體積基本3G以上），聽了下各位大佬的描述，wwise聽起來怎麼跟xact很像，xact裝配起來簡直噩夢，耗費工作量很多，而且靈活度實在不敢恭維。【具體什麼項目不便透露】
因為是生產音頻資源的人，FMOD的界面和主流DAW非常接近，完全沒有任何上手門檻，跳槽到新公司因為是用的FMOD Studio，花了1天時間看了下演示工程就摸懂了絕大多數功能【不只是3d panner，其中各種效果器、parameter控制、snapshot控制與交互音樂都有設計和製作】，真心方便。尤其是一個根event裡面載入多重event合成新音效事件這個簡直好用的不行，時間軸以及效果的控制靈活度簡直拔群，省掉了很多得從wav開始重新製作資源的情況。
還有個就是語音以及cutscene的音頻配置，直接新建一條event，往對應時間軸位置放聲音文件就行了，語音甚至都不用經過daw直接在fmod裡面進行輕量剪輯【好像是1.08的新功能】，直接在想要剪開的地方右鍵-split-拖動到你想要的位置（或者刪掉）-搞定。用過daw的是不是都覺得很眼熟，就差把快捷鍵弄出來了（笑）。
從製作工序的效率上來講，我是覺得xact和fmod studio完全沒法比，畢竟xact很很多很多年前的老玩意了，微軟大概也沒有繼續更新了，操作方式對於錄音師或者音頻製作的人員而言非常不人性化，易用性與效率實在是有點頭疼。
--更新--剛剛才看到貌似有人說支持kontakt的話打算用fmod編曲，我是覺得沒必要。不過我做交互音樂的時候感覺跟編曲也差不多了，反正都是四軌wav然後用parameter來切換軌道音量以及段落躍進。你用fmod編曲那不是還得讓玩家安裝相應的軟體音色。先不考慮版權問題，單說體積，總不能用GM音色庫或者羅蘭管弦之類的吧~也不說好萊塢弦樂組那種開工程要等七八分鐘的龐然大物了，就放個噴火管弦套件隨便一組，遊戲體積要突破天際了吧……但是如果不是我想的這種編曲用法的話，那用fmod編曲的意義在哪裡呢……沒有引戰的意思，科學分析。
（並不是說我音樂只有四軌樂器，但是交互需要分開的軌道也就那麼多了，幾十軌都拆開我還得考慮運行效率不是，畢竟你還得考慮佔用體積以及內存不是，不能單音樂就用了1個多G的內存嘛，美術內容要怎麼辦，有的玩家內存空間不多的）
為了防止Wwise吹由於200個免費音效可憐誘惑刷出來，我先留個結論
就我純自己經手的7個FMOD Studio項目 2個FMOD Designer，2個Wwise項目（每個音效至少150個）來看
易用性 FMOD Studio &>&> FMOD Ex &> Wwise
功能性 FMOD Studio &> Wwise &> FMOD Ex
bug數量 api層仨一樣，但是FMOD Ex 已退市，音頻設計師界面 Studio略多，但不致命
哦 差點兒忘了這個問題是那些遊戲用了音頻引擎了。
這個問題我覺得應該收束一下，應該是哪些國內的遊戲用了第三方音頻中間件做音頻部分的開發。不然所有U3D，UE，T3D的遊戲都多多少少有FMOD的代碼，那你這個怎麼算？
網易的遊戲大部分都用，騰訊的也大部分的都用，你叫得出名字的大廠，不是開發的flash頁游的也都用。
——————————
專門針對性回答那個叫鉛筆盒的程序員同志
一樣一樣來啊程序員同志
我這個半罐水程序查了給你回一下，平時挺忙的。
關於CPU監控
有誤，更正
//來源：Audiokinetic的社區問答
//Is there an API to get CPU profile and usage information in real-time?
//0 投票
//My
programmer would like to be able to get CPU usage metrics on the WWise
engine with //more resolution than watching the GUI"s graph. I"ve scoured
the API docs, but can"t seem to find //something appropriate.
//最新提問 7月 16， 2014 用戶: Brian S. (100 分)
//It"s
possible, it requires a Level B license with the Sound Engine source
code access. If //you have this type of license, you can write to us in
support, and we will share the //implementation details.
//最新回答 7月 16， 2014 用戶: Bernard R. (Audiokinetic)
有誤，更正
————————————
「FMOD你得手寫吧？WWise可以自動blablabla，只要你...就可以..多科學」
FMOD也自動化出頭文件，不過確實不包含枚舉量。不過你可以寫在事件的note裡面，現在也可以JS自動出了，如果你願意。
先干點活兒，剩下的再說
____________________
難得手上正在弄fmod的東西又正好有點空。就正好補充一下。這裡就針對性的對比Wwise來看FMOD
首先看一再強調的操作便捷度。
#快速簡單事件建立
FMOD：拖拽音頻到程序及生成可用同名事件。
Wwise：拖拽音頻生成單音頻容器，批量選中右鍵生成批量event。《=一個步驟 不算大問題。
#建立一個3採樣隨機的事件
FMOD：右鍵new event或者拖拽生成事件-&>復用則從Audio bin中，新加則從explore任重複選中拽三個採樣進去/添加multi-sound，再把採樣拽進去
WWise：audio tab右鍵添加random容器-&>如果你復用已有採樣啟用list view找到已添加的單獨容器或者，拖拽添加/不復用從瀏覽器拖拽-&>右鍵生成事件 《=也沒有太大差別，熟悉了list view的話也不算特別繁瑣。
——這裡是分水嶺
#建立一個whoosh（單）+shot（三）的可變音效事件
FMOD：拖一採樣到時間線A處，拖三個採樣到到時間線B處，完。
WWise：首先做一遍#快速簡單事件建立，可不建立事件-》執行一遍#建立一個3採樣隨機的事件，可不建立時間-》這時候你要考慮一下是用序列容器，還是用事件來實現這個東西。由於我們發現whoosh和shot必須有一定疊加，序列容器無法做到。於是改用事件-》右鍵建立一個事件，拖拽剛才建立好的兩個容器-》手工設置delay值使其出在正確的時間線位置
#給上面那個剛才那個事件疊個爆炸
FMOD：右鍵開個track-》拖一個爆炸
Wwise：用#快速#建一個爆炸的單容器 -》拖到剛才那個事件上面
#我覺得那個whoosh加爆炸效果不錯，想用到另外一個事件裡面。
FMOD：點開這個事件，選中兩個track-》複製，粘貼。|| 複製這個事件，刪除後面的3隨機-》拖拽到另一個事件內應用。
Wwise：由於事件內的內容不能複製，你可以複製這個事件本身-》改名-》去掉你不想要的-》把另外一個事件裡面的東西又拖過來。但是這樣很不經濟，這些工作都是一次性的，想復用，你必須回到#疊個爆炸#裡面把單容器拖拽換成用blend，然後用blend容器的規範，把音效疊在一起，在把這個blend容器拖拽到你要用的事件裡面。
好了後面工序方面我就不想打字了，我給WWise打字介紹工序真的累得慌。注意，上述對時間線結構的修改，FMOD可以聯調實現，wwise也可以。不過便捷程度嗎，請自己想像
————————————————————今天又有點時間，加上又有一個朋友選擇wwise的原因又是「大工作室和3A大作現在都用wwise」「wwise看起來夠複雜」
導致我來又來回這個問題。
上面對比了在製作一個帶有一定複雜度的音效時，FMOD和Wwise的區別。這裡來對比一下使用
首先，國內使用音頻引擎的公司越來越多，甚至幾乎趕上標配了，甚至很多家有專門招聘音頻部門的公司，最基礎的要求就是會使用音頻引擎。
哪怕不談內有音頻部門負責產出的公司，許多外包現在也推薦使用聲音引擎，畢竟稱得上是引擎那就對很多遊戲內可能發生的多多少少的問題做過優化：比如說聲音數量上限、觸發條件、效果、交互、音量統一等等各種操作和修改、設計。
但是引擎再怎麼好，假如公司內部沒有客戶端底層程序相關人員來寫埠，沒有相應的設計人員來配置東西，其實跟不用差不多沒區別，相當於原始人拿著步槍用槍托打架，可能某種程度上還不如不用（這句當然是誇張說的）。
至於那麼多音頻引擎和中間件哪個比較好用，我非常非常討厭一棒子打死的言論，什麼XXX引擎比OOO引擎音質好、設計好、交互性好之流，我很好奇幾個問題：1，說這句話的人用的是什麼版本的xxx引擎；2，您深入研究過了？3，敢問最終輸出您的比特率和解碼率或者壓縮比率是多少？4，您在引擎功能是使用方面又到底下了多少功夫？5，您的客戶端程序員給您寫過專門介面實現了該有的功能么？如果貴樣只是單純產出了或者直接從[X0000個音效素材庫]複製粘貼進音頻引擎然後打包使用，不更改和設計功能實現，那您這就是來扯犢子的了。
某F引擎和某W引擎基本上是聲名遠揚~各有千秋，而且還有一些比較小眾的聲音引擎和中間件在市場上也是大殺四方。只不過國內這方面以前不是特別重視，老一輩遊戲人和音頻從業者很多年都只接觸其中某個固定版本的引擎，所以不太清楚目前的情況。現在越來越多從業者從小玩各種3A也好精品也好，口味慢慢被養刁了，開始比以前更重視音頻這塊兒了，這是好事，但是不能只會死啃教科書和老人的經驗。記住一條：科技是在進步的。
國內的公司就真沒什麼人在用么？——不啊，有很多。
這玩意真的有用么？——有用啊，就看你會不會用，肯不肯找會的人來用。
這玩意性價比高嗎？對我的遊戲項目有用嗎？——3A項目用了這玩意的那麼多，你自己衡量吧#(滑稽)
W***e音質比F**d好——水電站的音質比火電站的好，聽蔡琴的歌能表達出她那種很有磁性的嗓音。聽電子和金屬樂必須用核電站，不然表達不出那種乾燥但是衝擊力爆炸的感覺。
寫了8年程序，用了6年FMOD，用fmod從designer到fmod studio，從端遊戲到unity手遊戲，發現fmod非常好用，和音效師配合也順暢。說fmod音質不好那個腦殘了吧！你要拿紅米手機來聽hifi嗎？
我最近開始搞fmod，我可以負責的告訴你，很多。幾乎每個音效外包公司都開始向用戶推薦fmod。多數大型工作室也專門有sfx組全面專用fmod。
但這玩意還是有學習成本的，就算拿到處理過的sfx，還是有一堆流程要走。
用過一段時間的wwise，做以下幾個具體功能的時候比較方便：
1.當策劃需求一個聲音需要隨機播放多個隨機音源的其中一個時，例如腳步聲、普通攻擊聲，當這類聲音一直播放的都是同一個音源的時候，人會產生聽覺疲勞。如果使用wwise，客戶端只需要觸發事件就可以了，至於一個事件怎樣去隨機一個音效，就是策劃管的事了。
2.根據材質播放不同的聲音，例如挖掘土地和挖掘金屬、挖掘石塊要產生不同的音效，這個功能可以讓策劃配置不同材料的switch名，客戶端根據導表信息，自動設置switch，就會播放對應的音效。
3.聲音曲線RTPC（real time parameter control），x軸可以是距離、時間等，y軸可以是音量、音調等，曲線是可以拖動調整的，這就產生了一個可以可視化調節的對應關係，而這種對應關係就不需要程序去管了。
4.對全部聲音的狀態處理，例如在陸地上和水下，聽到的聲音效果應該是不同的，這個在wwise里可以進行比較簡單的設置。
5.對音源文件的內存優化，例如一段較長的背景音樂，可以設置只載入正在播放的那一小片段。
6.互動式音樂，類似dota那種，當戰鬥的時候播放戰鬥音樂，戰鬥結束切換為一般BGM，這是通過觸發器trigger實現的，客戶端只需要判斷切換戰鬥音樂的時機並觸發，wwise會自動根據策劃配置平滑過渡。
7.音效播放的各種效果，例如淡入淡出，播放之後停頓幾秒繼續播放，聲音播放幾秒之後慢慢變小等，都可以交由策劃配置，客戶端不用多寫代碼支持這些功能。
8.多平台支持，多語言支持。wwise支持多個平台，會根據平台不同輸出不同的bank文件（一類音源的打包小集合），並做相關優化。當遊戲的語音有多個國家語言版本的時候，wwise也能輕鬆設置。
9.性能監視。
10.動態混響，例如吃雞這樣的遊戲，在房間里打狙擊槍和在平地上打狙擊槍，由於房間內聲音會來回反射，所以混響效果應該是不同的。通過遊戲過程中，對RTPC實時變數的控制，可以達到此效果。
當下國內一線遊戲公司，幾乎沒有項目會不使用聲音引擎的。大部分用fmod，不過用Wwise的也越來越多。至於選擇用哪個聲音引擎，得先看你遊戲引擎是否支持你想用的聲音引擎。單這兩個聲音引擎對比，不管從音樂的交互性，還是設計理念來說，Wwise都要勝一籌，建議能用Wwise就別用fmod。還有很重要的一點，fmod音質不是很好
推薦閱讀：
※人耳 20kHz 封頂，為什麼數字音頻都要記錄和解析到更高的頻率上去？
※為什麼喇叭或者揚聲器能還原出各種聲音（尤其音色）呢？
※如果將「音頻毒品（I-Doser）」混入普通音樂，是否能被識別？
※頻響曲線能多大程度上代表音質？