Linphone改變電話通話採樣率由8000變爲16000處理遇到的問題

採用linphone 進行語音通話，獲取語音數據進行識別的時候發現效果不是很好，由於通話採用的採樣率是8000，我想將linphone的通話採樣率變爲16000，看看實際效果如何：

默認採用的是PCMA的格式，由於語音識別接口只接受PCM或者wav這種不壓縮的格式，所以我沒有想修改linphone通話的payload類型，直接去將pcma的採樣率變成16000,使用代碼管理，到時候不需要了也能直接回退。

具體修改的地方：
1.將alaw.c 文件中獲取sample的方法返回值由8000變爲16000；
2.將ortp中avprofile.c文件中 PCMA格式的clock_rate 由8000變爲16000；

這2個是在獲取和設置採樣率的時候會用到的，但是在配置這2個後，發現
只是resample 這個filter 將採樣率由48000變爲了16000， 但是打log 發現 PCMA格式的clock_rate 還是8000，比較困惑 ，重新看了下linphone 接電話的流程。
Linphone 有讀配置文件，然後我將配置文件中的PCMA格式改爲了16000，發現linphone通話payload不再使用PCMA，改爲PCMU了。

我從 linphone_core_invite_address_with_params 開始查看到payload選擇的整個過程。
一個比較關鍵的函數是：linphone_call_start_audio_stream 這個函數是通話流開始也就是接通前會調用的，裏面調用了audio_stream_from_io這個方法，這個方法中和payload相關的函數是make_profile函數，這個函數關鍵的參數是call->resultdesc，所以找到這個在哪賦值的就知道哪出問題了。

查看發現reslutdesc的賦值和local_payload以及remote_payload相關
linphone 關於payload處理，會匹配local 和remote 情況，具體方法
在：sdp_process
在 offer_answer_initiate_incoming
在 initiate_incoming
在 match_payloads

添加payload時會對local_payloads 以及remote_payloads 進行比較；
函數是
static PayloadType * find_payload_type_best_match(MSFactory *factory, const bctbx_list_t *local_payloads, const PayloadType *refpt,
const bctbx_list_t *remote_payloads, bool_t reading_response){
PayloadType *ret = NULL;
MSOfferAnswerContext *ctx = NULL;

// When a stream is inactive, refpt->mime_type might be null
if (refpt->mime_type && (ctx = ms_factory_create_offer_answer_context(factory, refpt->mime_type))) {
    ms_message("Doing offer/answer processing with specific provider for codec [%s]", refpt->mime_type); 
    ret = ms_offer_answer_context_match_payload(ctx, local_payloads, refpt, remote_payloads, reading_response);
    ms_offer_answer_context_destroy(ctx);
    ms_warning("entered into this. mimetype: %s, ctx->mimetype",refpt->mime_type);
    return ret;
}
ms_warning("just generic_match.");
return generic_match(local_payloads, refpt, remote_payloads);

}

一般類型會直接進入generic_match 就行判斷對應類型各項是否相等

Local_payloads 設置是在方法： sal_call_set_local_media_description
Remote_payloads 設置是在方法： sdp_to_media_description

也就是linphone 爲了保證通話雙方能夠在一個頻道（音頻編解碼相同），所以會選擇一個雙方都使用的clock_rate相同的編碼格式，這個從log打印的sip通信過程也可以看出來，如下：

相當於在正常通話之前，2端要確定好傳輸數據的編解碼類型和採樣率，當然採樣位數都是16

搞到這也算是知道原因了…