2010-02-01 90 views
1

我正在研究如何實現n對n音頻聊天(因此,可以說4人互相聽到對方)。這是使用Flash或Wowza媒體服務器相當微不足道。 real問題是延遲,因爲聊天中的4個人必須儘可能地同步(例如,像唱歌一樣)。每毫秒都很重要。如何實現低延遲的n對n音頻聊天

您對超低延遲音頻聊天有什麼經驗?

  • 可實現的最低延遲是多少?
  • 你如何實現它(哪個軟件,協議,媒體服務器,比特率)?

非常感謝!

+1

你曾經使用電話,參加過電話會議,還是看過CNN?除非你在本地網絡上這樣做,否則你沒有禱告。 – 2010-02-01 13:18:20

+0

我知道在1秒以下的延遲可能是不可能的......但也許有人已經嘗試過類似的東西,可以分享他的經驗...... – 2010-02-01 13:47:49

+0

嗯,至少你是現實的:)...當你說「唱歌, 「這對我來說意味着表演者正在使用聲音來確定他們什麼時候需要唱歌,以及要唱什麼音符等等。對於這種類型的場景,您確實需要實時感受,所以我沒有看到這種情況如前所述,除非是本地網絡,否則就是現有技術的一種選擇。 – 2010-02-01 13:50:49

回答

0

可實現的最低延遲取決於您的代碼無法控制的許多因素,主要涉及您的網絡。

現在,如果我是做這個項目的人,我會看到什麼算法和協議可用於時鐘同步。一旦你這樣做,每個主機應該只是發送時間戳包到服務器。在服務器端,您可以以某種方式組合這些數據包(可能是每個機器的某個時隙的位或全部字節),然後通過多播將它們再次發送出去。

問題是,即使你的代碼有問題......你沒有辦法可靠地將這些數據包實時地發送到服務器。 UDP將丟棄數據包,並且你必須建立一個寬容的接受遲到或不顯示。 TCP在這方面並不好。當然,這些數據包保證按順序到達,但時間是多少?另外,爲了壓縮每個主機的聲音,然後在服務器上解壓縮,進行合併並重新壓縮,同時保持實時聲音非常雄偉的感覺。

我並不意味着被認爲是一個專家,也沒有任何經驗做這種事情,但它只是聲音艱難。

+0

感謝您的意見 - 雖然只是說明顯而易見,但看起來您是對的 - 現在1秒內的延遲似乎是不可能的。似乎我的客戶需要另一個商業理念。謝謝! – 2010-02-02 19:39:29