Skype Forumの書き込みをのぞく(1)
Global IP Soundのcodecについて調べていたら、Skypeがどのcodecを使っているかに興味が湧いてきたのでそちらを調べていたところ、Skype Forumに気になる書き込みがありました。
In 1.2.0.48 the bandwith usage is 35kb/sec out and 30kb/sec in, and that from the beghining of the call using ISAC.
1.3.xxx tryes first to use more bandwith (approx 45-50kb/sec) and only after some time (as my connection only transmit up to 40 kb/sec) it slows down the codec quality of ISAC. As a result, sound quality is poor.
バージョンによってビットレートが異なるのか、マシン性能によってビットレートが異なるのか、回線状況によってビットレートが異なるのかははっきりしませんが、こういう事も報告されているようです。
同じ方からの書き込みをもう一つ。
Problem still very anoying in 1.3.0.57: it uses ISAC-quality of approx. 40-42kbits/sec. The Analogmodem can't handle so much bandwith. The result is increasing roundtrip and irregular Audio quality.
Downgrading back to 1.2.0.48 resolves the problem, ISAC uses approx 30-35kbits/sec and roundtrip between New Caledonia and Germany stays at 1000-1700
アナログモデム回線を使っていると、40〜42[kbps]で通信しようとしても実際はそんなに速度が出ないからきついよ、ということですかね。結果として、ラウンドトリップ*1の増加と不規則な音質が出ているらしいです。で、バージョンを1.3.0.57から1.2.0.48に落とすと、30〜35[kbps]で通信しようとするので、それだと大丈夫、ということらしいです。
別の書き込みをもう一件。
ここでは、Skypeで使われているという噂のGlobal IP Sound社のiLBC codecのソースコードが紹介されています。id:izariuo440:050828でも触れましたが、iLBC codecは浮動小数点版のソースコードが公開されています。しかし、この書き込みで紹介されているものは、書き込みを見る限り固定小数点版のようです。
本当なのかどうか、ソースコードを少し見てみました。
おそらく、iLBC_encodeという関数がエンコードする関数なんですが、エンコードした結果を入れるバッファの型がどちらもfloat、つまり浮動小数点の型でした。また、関数内のコードは完全に一致しています。じゃぁ何が固定小数点版なのかな？と思ったら、最後の方にencodeという関数がありました。これはエンコードした結果を入れるバッファの型が期待していた通りのshort型だったのですが、固定小数点での計算に最適化されたものではなく、iLBC_encode関数を手軽に呼び出すためのユーティリティ関数でした。残念。
Global IP Sound社について
こうしてみてみると、Global IP Sound社は、ベースとなるcodecに何らかの最適化を施し、音声通話用にエコーキャンセラなどのDSPを施し、劣悪な回線状態でも通話を可能にする技術を持った企業、という風に見えます（そのまんまですが）。codecを利用する側に見えますね。
*1:往復時間
