兩個終端撥打volte存在語音時延的問題。其中，乙個終端為4g volte，位於smc站下，另外乙個終端為2/3g，位於巨集站下。在此場景下，隨著呼叫時間變長，極大概率出現4g終端接收到的語音延遲，時間為秒級，但是2/3g終端依然正常。
嘗試了其他場景，包括兩路volte（乙個終端在smc下，乙個終端在巨集站下以及兩個終端都在巨集站/smc下），巨集站下一路volte一路2/3g，均未出現時延問題。首先，需要定位時延點是在核心網還是在基站裝置。在出現問題的場景下，拔掉smc的wan口網線後，終端在幾秒內仍然能夠接收到語音，說明語音包已經到達了基站裝置，快取在了基站裝置或終端中。
在實驗室進行復現，同時抓包，對比了交換機的映象抓包以及基站內部tcpdump抓包，發現交換機的映象抓包中，下行語音包以20ms的間隔均勻到達，在基站內部的tcpdump抓包中，存在攢包的現象，即較長一段時間內（幾百毫秒級別），基站沒有接收到任何網口資料，隨後基站以極小的間隔收到了這一段的所有語音包。懷疑是由於網口的攢包現象，造成了語音時延。
做了乙個測試版本，在frwk接收udp報文的**中，手動增加時延。在出現問題的場景下，手動構造收包時延。發現構造時延後，終端果然出現語音延遲，至此，已經基本確認了產生語音延遲的直接原因。
下一步，需要確認發生攢包現象的原因。又做了乙個測試版本，可以手動建立乙個指定優先順序的任務，該任務持續執行死迴圈若干秒。在終端建立呼叫後，建立各個優先順序任務進行測試，發現當建立的任務的優先順序大於等於50時，終端出現時延，因此懷疑網口收包任務的優先順序為50，在出現問題的場景下，存在高於這個優先順序的任務持續執行的情況，隨著時間積累，逐步到達影響通話的程度。
諮詢博通技術支援，得到網口接收任務的任務名irq/12-timer1。博通的網口驅動同樣採取中斷+輪詢的方式，博通使用定時器去觸**詢任務執行。在初始化指令碼中提高該任務優先順序至66後，手動建立優先順序為65的任務執行死迴圈，不再出現語音時延的情況，確認修改有效。由於該任務優先順序會影響到所有網口收包，因此技術支援並不建議將此調的過高。使用該版本公升級後，呼叫保持2個半小時，終端語音時延不到1s。
如何減少IP語音網路傳輸時延
網路傳輸時延表示通過ip網路的單向時延。如果經過internet，很多因素可以影響資料流而且不受控制，這些因素包括語音資料報傳輸過程中必經路由器的流量狀況 每個路由器的處理能力 連線路由器線路的頻寬 網路進入點和輸出點之間路由器的數目等。isp可能會提供端到端的服務等級協議 sla 保證,但不管有沒...
語音識別學習記錄 TDNN時延神經網路
最近了解了卷積神經網路 cnn cnn是受語音頻號處理中時延神經網路 tdnn 影響而發明的。本篇的大部分內容都來自關於tdnn原始文獻waibel a,hanazawa t,hinton g,et al.phoneme recognition using time delay neural net...
語音通訊中終端上的時延 latency 及減小方法
時延是語音通訊中的乙個重要指標，當端到端 end2end 的時延 即one way delay,單向時延 低於150ms時人感覺不到，當端到端的時延超過150ms且小於450ms時人能感受到但能忍受不影響通話交流，當端到端的時延大於1000ms時嚴重影響通話交流，使用者體驗很差。同時時延也是語音方案...