玩法開天辟地，體驗不留縫隙。K歌不遺余力，應(yīng)用解決效益。總是羨慕別人家的“歌房”苦嘆自家“茅草房”消除不了回音和混音？這次就將帶你實戰(zhàn)K歌功能，細(xì)分應(yīng)用場景，提升產(chǎn)品表現(xiàn)，為你在“造房“路上“添磚加瓦“，給你最實用的”武器“，讓你的”K歌房“擺脫尷尬的余音繞梁，從此高品質(zhì)翱翔。看淡K歌之王，用技術(shù)推你做”K歌王中王“！

本期騰訊云大學(xué)大咖分享課程邀請到騰訊云高級工程師，主要從三個方面說明如何搭建K歌應(yīng)用

1. K歌功能應(yīng)用場景和產(chǎn)品表現(xiàn)

2. K歌功能技術(shù)實現(xiàn)方案

3. K歌功能的開發(fā)實戰(zhàn)

K歌的種類分為本地錄制和在線歌房。

本地錄制主要分兩大模塊：跟隨伴奏唱歌錄制和調(diào)音臺。調(diào)音臺用來通過調(diào)整人聲位置來調(diào)整搶慢拍缺陷，調(diào)節(jié)人聲及伴奏音量，混響及變聲等音效。均衡器是對聲音的不同頻段進(jìn)行增強(qiáng)或降低。例如，唱吧和全民K歌應(yīng)用的都是本地錄制模式。

在線歌房是房主的聲音和伴奏通過網(wǎng)絡(luò)編碼發(fā)送給房間聽眾。例如，直播。

本地錄制流程

伴奏文件經(jīng)解碼轉(zhuǎn)入播放設(shè)備，人聲跟隨伴奏錄制后用采集設(shè)備進(jìn)行人聲伴奏的同步采集。通過回聲消除將伴奏聲音消除，留下人聲，并存為人聲臨時文件。另一分支的耳返的作用是將人聲送達(dá)至用戶的耳朵。整個錄制流程是人聲經(jīng)變聲等設(shè)置后與伴奏形成耳返混音一并轉(zhuǎn)入播放設(shè)備。錄制后進(jìn)行后期處理與伴奏最終生成音頻文件。

技術(shù)應(yīng)用

常見伴奏文件形式有mp3,ogg,acc,wav。大部分手機(jī)盡管支持MP3解碼，但安卓機(jī)型容錯能力較差，對異常MP3文件(MP3文件不完整或格式錯誤)通常無法播放。部分安卓系統(tǒng)支持ogg播放，但I(xiàn)OS系統(tǒng)全部不支持，這些情況都需要打包解碼庫。解碼庫的多樣化可能造成的問題：對于app而言，音樂文件格式僅一種，并不需要占安裝包的大小進(jìn)行無用打包

解決方式：動態(tài)加載。即每個解碼庫單獨操作為動態(tài)庫（SO，DLL等）播放音樂時先加載動態(tài)庫，可加載到就正常播放，加載不到就返回即庫不存在。用戶可靈活選擇打包數(shù)量?？芍С謩討B(tài)下載的動態(tài)庫，例如安卓和Windows，在APP運(yùn)行期間，根據(jù)文件格式選擇庫。

邊下邊播指的是邊下載伴奏文件邊播放，此時會出現(xiàn)卡頓問題。即便是本地文件，播放過程中也可能存在卡頓。

卡頓出現(xiàn)的原因：

1. 解碼線程和其他任務(wù)線程共用時，因其他任務(wù)過重導(dǎo)致編碼不及時產(chǎn)生卡頓。因此編碼需要使用單獨線程。

2. 設(shè)置緩存 單獨線程的卡頓，在如今的并發(fā)系統(tǒng)中線程的調(diào)度是通過時間片輪巡的，不使用Buffer時，當(dāng)設(shè)備需要數(shù)據(jù)，線程未被調(diào)度就會引起卡頓。

錄制

錄制部分需要回聲消除即播放的部分無需采集。通常為系統(tǒng)自帶功能，例如在通話時開通揚(yáng)聲器，對方的聲音不會被采集后轉(zhuǎn)發(fā)回去。系統(tǒng)回聲消除存在一定局限性，例如只支持在通話情況下開啟回聲消除，媒體音量開啟并無效果，有些設(shè)備顯示返回失敗。通話條件下開啟回聲消除時采樣率降低。因在高采樣率下，采集到的聲音頻段豐富，回聲消除操作對算法和設(shè)備性能要求高。K歌場景下，如果用16k，很難滿足用戶需求，所以采用采樣率為44.1k的自研回聲消除。

在t0時刻，伴奏經(jīng)解碼后播放，從播放到用戶接受到伴奏存在的時間間隔稱為播放延遲。IOS系統(tǒng)，播放延時小。安卓系統(tǒng)相對較大，一般播放延時為幾百毫秒。從用戶開始唱歌到t1時刻人聲伴奏采集到內(nèi)存稱為采集延遲。采集延遲和播放延遲時間相似，安卓設(shè)備的兩個延遲一般是100~200ms。在t1時刻下采集到t0時刻的伴奏，為實現(xiàn)人聲伴奏對齊需要計算出t0和t1的時間間隔。通過計算播放延遲和采集延遲或一并計算總延遲。例如，計算總延遲，先播放一段測試聲音，采集后對比兩個信號的偏移情況得出結(jié)果。計算總延遲的方法相對精確，實驗室常用此方法，但此方法并不適合線上環(huán)境，很難實現(xiàn)在唱歌前播放一段測試音樂，這種情況下采用分段計算即可。播放延遲分為兩部分，獲取數(shù)據(jù)時的buffer最小值為mini buffer，可根據(jù)碼率聲噪等計算出時長。獲取mini buffer后，對100款主流機(jī)型進(jìn)行測試得出播放延遲大約為mini buffer的二倍。同理可得采集延遲。人聲伴奏對齊主要關(guān)注開始播放時，按播放采集延時計算，暫停后重新對齊。

混響

混響是聲源發(fā)出聲音后被反射物反射，反射后的聲音與聲源聲音相結(jié)合出的聲音。

混響的影響因素：反射物的遠(yuǎn)近，多少和材質(zhì)。反射物的遠(yuǎn)近決定反射聲音的到達(dá)時間，例如房間里回聲快速到達(dá)，山谷回音經(jīng)久不息。反射物的多少決定反射信號的多少，例如山谷里的回聲清晰可辨，房間里回聲難以分辨。反射物的材質(zhì)決定混響時間，反射物多，信號被吸收的多，聲音持續(xù)時間短。

以下為原聲和空靈兩模式的對比圖?？侦`模式下，直達(dá)聲和反射聲距離長，所謂山谷回音。

原聲是在房間里的說話狀態(tài)，左邊的長線段為直達(dá)聲，反射聲隨之到達(dá)，很難進(jìn)行區(qū)分。房間內(nèi)物體多，吸收聲音效果強(qiáng)，混響時間短。第一個反射聲到達(dá)時間，反射聲多少，混響持續(xù)時間決定混響程度。通過8種混響模式對以上三種因素進(jìn)行調(diào)節(jié)，下文demo操作時會具體呈現(xiàn)。

均衡器

均衡器是對不同頻率的聲音進(jìn)行縮放。下圖是一段錄音經(jīng)傅里葉變換后發(fā)現(xiàn)一個聲音由很多頻率的聲音構(gòu)成。此錄音在1000Hz之前相對較大，隨之縮小，16000Hz之后能量幾乎為零。根據(jù)頻率圖，我們可以對不同頻段的聲音進(jìn)行放大或縮小。低頻聲音若飽滿，則說明低頻信號較合適，若低頻信號小，聲音較為單薄。低頻信號高，信號較厚重。高頻信號較為明快。一般來說均衡器支持以下10級。下方的數(shù)字說明的是一個區(qū)間值，例如31，是均衡31~61這段區(qū)間的區(qū)間值。

變聲

變聲支持12類型：蘿莉，大叔，熊孩子，感冒，困獸，空靈肥仔，重金屬，外國人，重機(jī)械，強(qiáng)電流，土話。根據(jù)以上聲音特點使用的技術(shù)方法并非單一，例如蘿莉和大叔兩種，通過升降頻率實現(xiàn)，空靈通過混響來實現(xiàn)。

以下是原聲和蘿莉的語譜圖，橫坐標(biāo)為時間，縱坐標(biāo)為頻率。顏色代表特定時間點下，某頻率的聲音強(qiáng)度。原聲的聲音頻率較窄，為16000Hz以下。蘿莉音頻率被拉長，一些低頻音被放大為高頻，頻率為14000Hz左右。可以用QQ語音消息進(jìn)行體驗，和GME的K歌功能一樣，都是音視頻實驗室研發(fā)的。

在線K歌

在線K歌發(fā)送端和穩(wěn)定錄制相似，增加了編碼這一項。根據(jù)流程圖所示，編碼后發(fā)包，收包等，最后解碼播放。

K歌房考慮因素：伴奏，人聲，歌詞同步。和上述伴奏人聲同步不同的是，雖然本地伴奏與人聲同步，但發(fā)送期間由于網(wǎng)絡(luò)延遲不固定，接收端收到后，伴奏和人聲還是會有偏移。因此伴奏和人聲需要混音發(fā)送。歌詞同步就是時間戳的同步，根據(jù)當(dāng)前收到的聲音所在時間

來展示歌詞。展示歌詞分逐字展示和逐句展示，逐字對時延要求較高。

同步時間戳的兩種方式：

1開始時發(fā)送信令，然后暫?；蚪Y(jié)束再次發(fā)送信令，對方根據(jù)接收時間，通過計時器的累加決定伴奏的時間。這種方式的好處不需要改變音頻幀的格式，如果音頻幀的擴(kuò)展性不好，可采用此方式。

2 如果音頻幀的擴(kuò)展性較好，對時間戳精度要求高，則需要把當(dāng)前伴奏的時間戳放在音頻幀的頭或尾，與音頻幀一同傳送。此種方式實施效果好，目前我們采用此方式。

延遲控制

延遲控制主要控制直播場景中，說話者的聲音經(jīng)網(wǎng)絡(luò)發(fā)送到聽者的時間。這個時間可細(xì)分為播放和采集延時，設(shè)備相關(guān)問題可控范圍小。另一個原因是網(wǎng)絡(luò)傳輸，可通過增加后臺服務(wù)器，使每個用戶就近連接，通過最近通路傳輸。

延遲的另一個類型是由網(wǎng)絡(luò)收發(fā)包buffer引起的延遲。音頻數(shù)據(jù)通過UDT形式傳輸，而UDT不能保證持續(xù)性。例如有三個音頻包，可能接受順序是混亂的，部分音頻包會被丟棄，導(dǎo)致聲音斷斷續(xù)續(xù)并不完整。因此，延遲也并非越小越好。我們需要對不同場景進(jìn)行優(yōu)化，比如直播模式無交互，聽眾不會和直播者互動，只需保證直播人的聲音和畫面是同步的，即使晚幾秒傳輸，聽眾是無法明顯察覺的。在這種情況下先保證避免卡頓，延時可略微增加。

連麥模式是在直播的過程中實現(xiàn)聽眾與直播者的互動，這種情況下對實時性要求較高。因此連麥模式需要低延時，卡頓可略微存在。不同模式的側(cè)重點不同，需根據(jù)具體場景調(diào)整參數(shù)。

錄制過程中，只有一位錄制者時，錄制并上傳即可。如果多人參與錄制，則采取后臺錄制，即后臺統(tǒng)一解碼多人聲音，生成文件，錄制結(jié)束時，返回服務(wù)器地址，即可進(jìn)行觀看。

以下是實現(xiàn)一個簡單的本地錄制功能的實戰(zhàn)演練環(huán)節(jié)。

1、初始化 
   ITMGContext.GetInstance(this).Init(String.valueOf(mAppId), mUserId);//初始化sdk，用來登錄
   ITMGContext.GetInstance(this).SetTMGDelegate(new MyDelegate());//設(shè)置代理類，用來接受各種回調(diào)和事件
   EnginePollHelper.createEnginePollHelper();//定時去調(diào)用Poll函數(shù)，可以用這個輔助類，也可以在某個周期函數(shù)中調(diào)用
2、進(jìn)房
        byte[] authbuff = AuthBuffer.getInstance().genAuthBuffer(mAppId, mRoomId, mUserId,mAppKey);//獲得鑒權(quán)信息，最好放在server
    ITMGContext.GetInstance(this).EnterRoom(mRoomId, 2, authbuff);//進(jìn)入房間
3、K歌相關(guān)接口

        /*功能：開始錄制
        **參數(shù)：
        **type：K歌場景傳ITMG_AUDIO_RECORDING_KTV
        **dstFile：目標(biāo)文件路徑，用于保存錄制完成的音樂
        **accMixFile：一般是沒有原聲的伴奏，用來和人聲合成音樂文件
        **accPlayFile：用于播放的音樂文件，正常情況下和accMixFile是同一個文件。但在用戶不熟悉歌曲的時候，可以是帶原唱的音樂文件
        */
    int StartRecord(int type, String dstFile, String accMixFile, String accPlayFile);
        
        /*功能：停止錄制*/
    int StopRecord();
        
        /*功能：暫停錄制*/
    int PauseRecord();
        
        /*功能：繼續(xù)錄制*/
    int ResumeRecord();
        
        /*功能：設(shè)置播放用的音樂文件，一般用于在原唱和純音伴奏之間切換
        **參數(shù)：accPlayFile，用于播放的音樂文件
        */
    int SetAccompanyFile(String accPlayFile);
        
        /*功能：獲取伴奏文件的長度*/
    int GetAccompanyTotalTimeByMs();
        
        /*功能：獲取當(dāng)前錄制了多長時間*/
    int GetRecordTimeByMs();
        
        /*功能：將錄制時間跳轉(zhuǎn)到指定時刻。如果參數(shù)比當(dāng)前時間靠前，則重復(fù)的地方重新錄制；比當(dāng)前時間靠后，則用靜音數(shù)據(jù)填充沒有錄制的部分
        **參數(shù)：timeMs，跳轉(zhuǎn)的時刻，單位ms
        */
    int SetRecordTimeByMs(int timeMs);
        
        /*功能：設(shè)置音效
        **參數(shù)：type音效類型，參見ITMG_KaraokeType
        */
    int SetRecordKaraokeType(int type);
        
        /*功能：獲得錄制文件的長度*/
    int GetRecordFileDurationByMs();

        /*功能：開始預(yù)覽錄制文件*/
    int StartPreview();
        
        /*功能：停止預(yù)覽錄制文件*/
    int StopPreview();
        
        /*功能：暫停預(yù)覽錄制文件*/
    int PausePreview();
        
        /*功能：繼續(xù)預(yù)覽錄制文件*/
    int ResumePreview();
        
        /*功能：設(shè)置當(dāng)前預(yù)覽的時間點
        **參數(shù)：time，預(yù)覽文件的時間點單位ms
        */
    int SetPreviewTimeByMs(int time);
        
        /*功能：獲取當(dāng)前預(yù)覽的時間點*/
    int GetPreviewTimeByMs();

        /*功能：設(shè)置人聲和伴奏的縮放比例
        **參數(shù)：
        **mic：人聲的縮放比例，1.0為原來音量，小于1.0為縮小，大于1.0為放大
        **acc：伴奏的縮放比例，1.0為原來音量，小于1.0為縮小，大于1.0為放大
        */
    int SetMixWieghts(float mic, float acc);
        
        /*功能：設(shè)置人聲相對于伴奏的偏移，一般用于調(diào)整聲音跟不上節(jié)拍的問題
        **參數(shù)：time，人聲相對于伴奏的偏移時間，單位ms。大于0為向后移動，小于0為向前移動
        */
    int AdjustAudioTimeByMs(int time);
        
        /*功能：將錄制好的人聲和伴奏合并成一個文件*/
    int MixRecordFile();
        
        /*功能：取消合并操作*/
    int CancelMixRecordFile();
        
        
        需要監(jiān)聽的事件：
        /*功能：錄制完成的回調(diào)。伴奏播放結(jié)束或者調(diào)用StopRecord觸發(fā)
        **參數(shù)：
        **result：錄制結(jié)果錯誤碼，0為成功
        **filepath：目標(biāo)文件的路徑，StartRecord傳入的
        **duration：錄制文件的長度，單位ms
        */
        ITMG_MAIN_EVENT_TYPE_RECORD_COMPLETED        

        /*功能：預(yù)覽完成的回調(diào)。預(yù)覽文件播放結(jié)束或者調(diào)用StopPreview觸發(fā)
        **參數(shù)：result，播放結(jié)果錯誤碼
        */
    ITMG_MAIN_EVENT_TYPE_RECORD_PREVIEW_COMPLETED
        
        /*功能：合成文件完成的回調(diào)。合成文件完成觸發(fā)，完成之前調(diào)用CancelMixRecordFile則沒有回調(diào)
        **參數(shù)：
        **result：合成結(jié)果錯誤碼，0為成功
        **filepath：目標(biāo)文件的路徑，StartRecord傳入的
        **duration：錄制文件的長度，單位ms
        */        
    ITMG_MAIN_EVENT_TYPE_RECORD_MIX_COMPLETED(32)    

接口詳細(xì)說明參見：https://cloud.tencent.com/doc...