音頻數據包類型

我開始着手一個項目，該項目通過以太網傳輸G.711音頻，用C（而不是C++）編寫，並在Fedora 15上運行。而不是做聰明的事情並使用RTP，我使用UDP傳輸音頻數據。爲了稍微克服我已經決定在每個數據包的身體，看起來使用結構的數據包重新排序的問題有點像這樣：音頻數據包類型

struct payload { 
    char cc; 
    char audio_data[160]; 
};

變量「CC」是運行連續性計數器從0到15，當數據包到達接收者時，根據cc的值將它放入這些結構的數組中。音頻輸出例程然後遍歷該數組並播放數據。

我的問題是，這是打包音頻的最佳方式嗎？輸出數組最終會變成二維的，肯定會通過每個成員慢讀並將其寫入輸出？有沒有一種方法可以定義160字節寬的類型，我只能寫入另一端的音頻接口？

任何建議，將不勝感激，正如有用資源的鏈接上ALSA（這似乎是非常罕見的！）

喬希

來源

2011-12-10 aktungmak

我不確定我是否理解你的問題。你試圖避免/優化的是什麼？ –

你擔心緩存優化？我希望你在把它變得複雜之前簡單介紹一下這個簡單的方法。如果緩存未命中是一個真正的問題，我會建議使用ring (circular) buffer。這也將是你的jitter buffer。這爲您提供固定的內存佔用空間和連續內存，以加快訪問速度。

由於G.711是恆定比特率編解碼器，您可以以時間爲單位選擇緩衝區大小（會話時爲200毫秒）。您始終播放緩衝區中的最後一個數據包。例如，您收到的最後一個數據包有cc = n，那麼您將收到cc = m（>n）。因此，您將n和m之間的所有數據包標記爲丟失，並在稍後收到它們時將其替換。

來源

2011-12-10 22:29:05

我希望我的循環陣列想法可以作爲環形緩衝區工作！我所關心的主要問題是需要循環訪問char數組，並將每個字節逐個寫入聲卡，而當我更願意寫的是180字節的塊時，硬件可以在它自己的比率。我可以定義180字節寬的類型嗎？ – aktungmak

當然，'char [180]'if sizeof（char）== 1' on your target platform –

aha，so 'typedef char [180] audio_data_chunk; audio_data_chunk adata; snd_pcm_read（手柄，ADATA，的sizeof（ADATA）;' 然後 'snd_pcm_writei（手柄，ADATA，的sizeof（ADATA）;' 三江源非常感謝！ – aktungmak

音頻數據包類型

回答

相關問題