ITRC

1. 多目的な音声伝送システム MRAT の開発 岸田 崇志 † 河野 英太郎 †† 前田 香織 †† † 広島市立大学大学院情報科学研究科 †† 広島市立大学情報処理センター

2. はじめに 広域 LAN 等の広帯域ネットワークの普及 ― 音声を用いた通信も一般化 音声伝送を用いた様々な利用場面の増加 ― 遠隔講演，遠隔講義，遠隔合唱 etc. 一括りに音声伝送といっても利用場面は多岐にわたる それぞれの利用場面において 必要とされる条件も異なる

3. 目的 利用場面に応じた音声伝送ツールが必要 それぞれの利用場面で要求される条件についての検討 利用場面に対応できる多目的な音声伝送システムの開発

4. 音声伝送の利用場面 一方向が主，双方向での会話がほとんどない 遠隔講演 や 遠隔講義 議論が主，双方向の会話が多い 遠隔会議 や 会話 拠点間の音声のずれは許されず，双方向性が非常に高い 遠隔合唱 や 遠隔合奏 利用場面を大きく以下の 3 つに分類

5. 利用場面と要求条件 低い 高い 非常に高い 双方向性 確実に 音声を届けること 会話に支障がないこと 音声のタイミングを 同期させる こと 主な要求条件 高 中 低 パケット損失等の耐性（ ロバスト性 ） 任意 400ms 未満 ITU-T G.114 より 100ms 未満 片方向の許容遅延時間 一対多 多対多 多対多 通信形態 遠隔講演 遠隔講義 遠隔会議 （会話） 遠隔合唱 遠隔合奏 利用場面 ロバスト性 が高いほどパケット損失などに対する耐性が強いことを示す

6. MRAT（Multipurpose RAT) RAT （ Robust Audio Tool) を拡張し，多目的な音声伝送に利用できる MRAT （ Multipurpose RAT) の開発 利用場面ごとに 3 つのモードをもつ Chorus モード・・・遠隔合唱，遠隔合奏 Conversation モード・・・遠隔会議，会話 Broadcast モード・・・遠隔講義，遠隔講演 それぞれの利用場面に対応するため・・・

7. 各モードの位置づけ 遠隔合唱 遠隔講義・遠隔講演 遠隔会議・会話 100ms 400ms 遅延 ( 転送遅延、ジッタ、処理遅延 ) 低 高 0ms ロバスト性

8. 利用場面と各モードの対応 遠隔合唱 遠隔講義・遠隔講演 遠隔会議・会話 100ms 400ms 遅延 ( 転送遅延、ジッタ、処理遅延 ) 低 高 0ms ロバスト性 従来の RAT 低遅延化優先 ロバスト性優先 Chorus モード Conversation モード Broadcast モード この 2 モードを追加

9. Conversationモード 許容遅延時間は 400ms 未満 音声会議システムである RAT の機能を基本にパラメータ設定のみで対応 Min=0ms,max=1000ms 追加再生バッファ時間の制限 パターンマッチング方式 受信側のパケット損失回復機構 なし 送信側のパケット損失回復機構 モノラル チャンネル 32kHz サンプリングレート Linear-16 （無圧縮） エンコード方式 実験での設定値 設定項目

10. Chorusモード オーディオデバイス上でのバッファ処理のスケジューリングのパラメータを変更 -> 低遅延化 片方向の遅延時間 100ms 以内 低遅延化優先

11. オーディオバッファの処理の問題 データ量 経過時間 経過時間 他のプロセスに処理を奪われる 入力バッファ データ量 出力バッファ 遅延が生じる 読み込みに時間がかかる オーディオデータ 読み込み 出力バッファに渡す 出力バッファに渡すタイミングが遅れる

12. Cushion での解決 データ量 経過時間 経過時間 入力バッファ データ量 出力バッファ 遅延が生じる 読み込みに時間がかかる オーディオデータ 読み込み 出力バッファに渡す 閾値 を設定

13. Cushion での解決 データ量 経過時間 経過時間 入力バッファ データ量 出力バッファ 過剰な入力バッファのデータ量を制限 RAT 開発時 (1997 ）の SUN SPARC 10 ワークステーション（ 30MHz ～ 80MHz ）から算出されたもの 読み込み時間の減少 オーディオデータ 読み込み 出力バッファに渡す 閾値 を設定 遅延時間の減少 出力バッファに渡すタイミングが遅れない 現在の CPU に基づいた閾値を設定

14. Chorus モードでの改良 データ量 経過時間 経過時間 入力バッファ データ量 出力バッファ オーディオデータ 読み込み 出力バッファに渡す 現在の CPU に基づいた閾値を設定

15. Chorus モードでの改良 データ量 経過時間 経過時間 入力バッファ データ量 出力バッファ オーディオデータ 読み込み 出力バッファに渡す 現在の CPU に基づいた閾値を設定 さらに低遅延に

16. Chorusモードの弱点 このようにしてコーラスモードでは低遅延を果たしている バッファ時間を少なくしたためにジッタ耐性などが低下 ロバスト性の低下

17. Broadcastモード ロバスト性を最大限に重視 Reed-Solomon 符号を用いた FEC を実装 FEC （ Forward Error Correction ） 送信側で訂正用データを追加して送信 受信側で訂正 Reed-Solomon 符号方式 複数ビット（シンボル）単位でのエラー検出・訂正 バースト誤りに強い

18. パケットフォーマット RTP 拡張ヘッダを付加し，それを FEC ヘッダとして定義 IP UDP RTP RTP ext DATA 12 8 12 8 (Bytes) extn_type extn_len CS DS FEC sequence reserved (bits) 0 8 16 24 32 CS: code symbol size DS: the number of data symbols

19. 実装 実装状況 -> 実装済み Conversationモード Chorusモード Broadcastモード RATに装備されているほぼ全ての音声CODECに対応 動作確認を行った環境 完成 SoundBlaster Live! Value Soundcard Vine Linux 2.1,Vine Linux2.1.5,Vine Linux2.5 OS PentiumⅢ 1.0GHz ～ PentiumⅡ300MHz CPU

20. MRAT の評価 各モードでの遅延時間の測定 Broadcast モード エラー回復能力を理論値と実測値との比較 パケット損失が生じたネットワーク上での実際の効果 既存の RAT の FEC との比較 RAT と MRAT の音質比較 Broadcast モードを用いた実践 Chorus モード 遠隔合唱での実践実験

21. 遅延時間測定の実験環境 Ethernet 100Mbps Host A Host B 録音用 PC メトロノーム CPU PentiumⅢ 600MHz OS Vine Linux2.5 CPU PentiumⅢ 1GHz OS Vine Linux2.1 送信 録音 録音 元の音と HostB 経由の音の時間軸の差を測定

22. 遅延時間測定結果 この値は十分に速くトラフィックの少ないネットワークで測定しており実際の MRAT の処理遅延に近い 実際はこの値に転送遅延が加算されたものになる ７２ [ms] １３２ [ms] １３８ [ms] １３８ [ms] １４３ [ms] 片側の遅延時間 100ms 未満 400ms 未満 任意 任意 任意 許容遅延時間 Chorus Conversation Broadcast (15,13) Broadcast (15,12) Broadcast (15,11) モード

23. Broadcast モードのエラー回復 Ethernet 100Mbps パケットロス発生器 Host A Host B CPU PentiumⅢ 600MHz OS Vine Linux2.5 CPU PentiumⅢ 1GHz OS Vine Linux2.1 CPU PentiumⅡ 300MHz OS Vine Linux2.1 1,2,4,6,8,10% の確率でパケット損失発生！ FEC デコード後のパケット損失率を測定

24. 測定結果 (15 ， 13) (15 ， 12) (15 ， 11) パケット損失 10 ％ FEC なし FEC あり (15,11) 符号 10 12 ～ ～ ～ ～

25. Media Specific FECとの比較 RAT には Media Specific FEC （ RFC2198) が実装されている 音声データパケットを複製 次のパケットにくっつけて送信 欠落したパケットがあれば一つ後のパケットにくっついていたものから復元 送信ホスト 受信ホスト Linear-16(PCM) PCMμ-law primary secondary エンコード方式を個々に選択できる

26. Media Specific FECとの比較 RAT に実装されている Media Specific FEC と今回新たに実装した Reed-Solomon FEC との比較を行った ※ secondary encoding に linear-16 を用いた場合 エンコード方式 Linear-16 ， サンプリング周波数 32kHz ， モノラルの場合 パケット損失 20% 下でのそれぞれの FEC の音質の比較 FEC の種類 使用帯域 帯域増加量 なし 512 [kbps] (1.0 倍 ) Reed-Solomon FEC (15,13) 591 [kbps] 1.15 倍 (15,12) 640 [kbps] 1.25 倍 (15,11) 698 [kbps] 1.36 倍 (15,8) 960 [kbps] 1.88 倍 Media Specific FEC linear-16 ※ 1024 [kbps] 2.0 倍 パケット損失 20% の時 MediaSpecificFEC Reed-Solomon(15,8)

27. MRATとRATの音質比較 RAT では、プツプツというノイズが目立っていた、そのノイズに関しての評価を行う 評価は RAT,RAT(MediaSpecificFEC),MRAT(broadcast モード ) の 3 つに関して 46 秒の音楽を 5 回ずつ流して評価を行った 実験ネットワークのネットワークの状況 0.5ms RTT 5 % 最大パケット損失率 0.76% 平均パケット損失率 6 ～ 7ms ジッタ

28. MRATとRATの音質比較（続き） ノイズの検出は、ノイズが感じられる際高周波数帯に大きな変動がみられることから、録音した音声に高速フーリエ変換を行いその FFT スペクトルを元に観測を行った。 46 秒の音楽をそれぞれ 5 回ずつ流した平均値である。 16.4 RAT(Media Specific FEC) 36.4 RAT 3.4 MRAT(Broadcast モード ) 検出されたノイズ数 ( 個 )

29. Broadcastモード での実践 広島市立大学 広島大学 佐賀大学 JGN （通信放送機構： TAO ） ジッタ： 4ms 平均パケット損失率： 0.0004% RTT ： 14.8ms 広島市大－佐賀大 間 ジッタ： 6ms 平均パケット損失率： 0.01% RTT ： 8.5ms 広島市大－広大 間 音声： MRAT(160Kbps) 映像： Mpeg2ts(5Mbps) 各拠点で送信に使用する帯域

30. Chorusモードでの実践実験 広島市立南観音小学校と広島市立白島小学校で「マメ de がんすプロジェクト」の実証実験ネットワーク（ 10Mbps 広域 LAN) を用いて 遠隔合唱 を行った 各地点間はマルチキャストで伝送し、 MRAT （ Chorus モード ) で送信に使用した帯域は 512Kbps 両校の映像は MPEG2 伝送システムの MPEG2TS を用いた

31. 実験構成図 広島市立大学 白島小学校（ソプラノ） 南観音小学校 ( アルト） マメ de がんす ネットワーク 10Mbps Multicast 伴奏 伴奏 伴奏 伴奏＋ソプラノ 伴奏＋アルト アルト ソプラノ アルト＋ソプラノ 70 ～ 75ms 7 ms ジッター 2.1 ms 転送遅延 モノラル チャンネル 32kHz サンプリングレート Linear-16 （無圧縮） エンコード方式

32. 実際の合唱のスタイル 伴奏地点 合唱地点 合唱地点 合唱として許容できる 70ms 140ms

33. おわりに 利用場面ごとに音声伝送に要求される条件の検討 それに基づいたシステムの実装，及び各項目ごとの評価 MRATを用いて遠隔ゼミや遠隔合唱の実践実験

34. 今後の課題（予定） さらにChorusモード，Broadcastモードを用い実践実験に使用 予定表 11 月 19 日：基町高ー南観音小の 2 拠点で遠隔 合奏 12 月中旬：基町高ー南観音小遠隔合唱 1 月中旬：白島小ー南観音小ー佐賀大付属中遠隔合唱 2 月 26 日：りんけんバンドと白島小セッション？

35. 参考文献 “ Robust Audio Tool, ”http://www-mice.cs.ucl.ucl.ac.uk/multimedia/software/rat/index.html I.Kouvelas and V.Hardman,”Overcoming Workstation Scheduling Problems in a RealTime Audio Tool”, in Proceedings of Usenix Annual Technical Conference, Anaheim, California. Pp.235-242(1997) 岸田崇志，河野英太郎，前田香織，天野橘太郎，“多目的な音声伝送システムの設計”，情報処理学会研究報告， 2002-DSM-26-3,, pp.13-18(2002) マメ de がんすプロジェクト， http://www.csi.ad.jp/activity/MAMEdeGansu 近堂徹，大塚玉記，西村浩二，相原玲二，“ MPEG2 over IP 伝送システム mpeg2ts の開発と性能評価” ,DICOMO2002 シンポジウム論文， pp.157-160(2002)

36. 参考資料

37. RATの音質 -> FM 放送程度といった回答が多い RAT の音質に関して 15 名による主観評価を行った

38. パケットロスによる ノイズの主観評価結果 通常の RAT と MRAT （ Chorus モード）では， Chorus モードではジッタ等に対する耐性が若干減っていると想定されるが，主観評価によるとほぼ同程度の音質と考えられる 非常に気になる 全く気にならない

39. CODECと使用帯域 66 ○ 52.8 GSM 160 × 128 VDVI 160 ○ 128 DVI 80 ○ 64 G726-40 120 ○ 96 G726-40 160 ○ 128 G726-40 200 ○ 160 G726-40 320 ○ 256 A-law 320 ○ 256 μ-law 640 ○ 512 Linear-16 RS エンコード後の使用帯域 [kbps] RS エンコード 使用帯域 [kpbs] エンコード方式

40. 遠隔合唱の限界 70msという遅延時間は、光の速さ（30万km/s）で2100km進む距離 これらの制限より遠隔合唱は世界的な規模では現実的ではない ２００~３００km以内のメトロポリタンネットワーク内が現実的

41. Chorusモードの遅延時間 70msという遅延時間は，音の速さ（340m/s）で24m進む距離 オーケストラなどは大きなステージ上で演奏を行っている ->物理的にも24m離れることがある 70ms という値は十分実用的な値である 音は 1m 進むのに約 3ms かかる（音は遅い） -> スピーカと合唱者の距離なども重要

42. Reed-Solomon符号 リードソロモン（ 15,12 ）ブロック符号 ・・・ 15 パケット 12 パケット 情報パケット 3 パケット 冗長パケット ヘッダ データ

43. MSFECのインターリーブについての考察 パケットの損失割合は減らないが，知覚的に落ちているのを和らげるもの 使用帯域を増やすことがないので有効 インタラクティブな使用用途には向かない -> 幾つかのパケットをバッファするため

44. ITU-T G.114 ITU-T G.114では片方向の遅延限界の基準を次のように定めている 0 から 150ms 大部分のユーザで受け入れ可能 150 から 400ms 管理者が品質に対する遅延の影響を把握している場合、受け入れ可能 400ms 以上 例外を除き受け入れ不可能

45. ITU-T G.114 片方向の遅延限界の基準を定めている ・ IP-Phone でもこの値を参考に片方向の遅延時間を設定している例が多い ・会話などでは片方向の遅延時間が 150ms 未満であることが理想 -> Conversation モードでは 132ms

46. Broadcastモードでの実践 現在、広島市立大学・広島大学・佐賀大学の三拠点で遠隔ゼミを行っている 各地点間はマルチキャストで伝送 MRAT（Broadcastモード)で送信に使用する帯域は160Kbps 各拠点の映像はMPEG2伝送システムのMPEG2TSを用いている Reed-Solomon(15,12) 符号

47. FEC (Forward Error Correction) 送信側で訂正用データを追加して送信 受信側で訂正 リード・ソロモン符号方式 複数ビット（シンボル）単位でのエラー検出・訂正 バースト誤りに強い 複雑な演算を多用 本システムの FEC の実装 `` Forward Error Correcting Codes’’ ― Phil Karn http://www.eccpage.com/ http://people.qualcomm.com/karn/code/fec/

48. 理論値 理論値 P は次のようになる．各パケット数の組み合わせを（ N,K) とし，個々のパケットの損失率を p とする． I はデータパケット K 個中 FEC デコード後に損失しているパケット数である．

49. Cushionについて i バッファ時間 bi バッファ時間 i [ms] かかるブロック数 ｔ 単位時間内に処理するブロックの個数 Cushion は、 (1) 式をみたす最小となる x [ms] となる (1) Cushion は、 (1) 式のように定義される

50. Cushionについて ｔ は History サイズを 25 とすると、 23 となる バッファ時間が小さいほうから 出現頻度の個数を 23 個カバーする範囲で Cushion を設定する 26ms 23 個

51. Cushionについて ｔ は History サイズを 25 とすると、 23 となる バッファ時間が小さいほうから 出現頻度の個数を 23 個カバーする範囲で Cushion を設定する 26ms 23 個

52. Byte － ms 換算 サンプリング周波数３２ｋ Hz ->一秒間32000回標本化 ->1msで32回標本化 16bit で量子化 1サンプル２byte ブロック (byte)÷2÷32 となる 1 ブロックでバッファリングに必要な時間 (ms) は

53. 転送遅延 Ping でパケットサイズを 100byte ずつ増やしていった時のグラフの切片を 2 で割ったものを転送遅延とした

54. RAT(Robust Audio Tool) Mbone の音声会議システム RAT(Robust Audio Tool) 品質の悪いネットワークでも高品質な音声 多地点同時に複数の人数で会議に参加できる（マルチキャスト対応） 数々のエンコード方式を選択できる（使用帯域を選択）

55. FECシーケンスはユニット内でのパケット順序 CSはビット単位のシンボルの長さ（FEC処理ユニットに含まれるパケット数は ） DSはデータシンボルの長さ（データパケットの個数） 本システムでの実装 Reed-Solomon FEC は，複数パケットを 1 ユニットとしユニット毎に RS 演算を行う

56. 本システムでの実装（続き） Reed-Solomon符号 処理に複雑な演算を多用するため処理速度がネック 処理速度，処理遅延，処理の簡単化を考慮 1 シンボル 4 ビット (CS=4) ->パケット 15 個 ( ) が 1 ユニット

57. Reed-Solomon符号 リードソロモン（ 15,12 ）ブロック符号 ・・・ 15 パケット 12 パケット 情報パケット 3 パケット 冗長パケット ヘッダ データ

58. Media Specific FEC Media Specific FEC は、 RFC2198(RTP Payload for Redundant Audio Data) で規定 一つの送信パケットを次のパケットにくっつけて送信するというものである。パケットロスが生じるとその冗長パケットから損失回復をする

59. Media Specific FEC Linear-16(PCM) Linear-16(PCM) Linear-16(PCM) PCMμ-law Primary encoding Secondary encoding Linear-16(PCM) LPC

60. 各種FECの方式 FEC Media Independent FEC Reed-Solomon,parityなどデータ部から演算を行いあらたな冗長パケットを生成する方式 Media Specific FEC RATに実装されているものでデータ部から演算をおこなわず単純に次の送信パケットの末尾にピギーバックして送信する方式

61. RATでの処理 RAT では、マシンの負荷状況に応じてオーディオデバイスのバッファリング時間を調節する スケジューリング を行っている 一定期間オーディオデータを保持し、それをもとに出力バッファで遅延が生じないようバッファリング時間を設定する 調節されたバッファリング時間を Cushion と呼ぶ

62. Cushionを決定するパラメータ Cushion のとりうる範囲（固定値） ― 大きくとりぎると遅延が大きくなり、小さすぎると音質を損なう可能性がある History サイズ（固定値） ― オーディオデータの保持数、この数をもとに負荷計算を行う できる限り cushion のサイズを安定させ、小さい値であるものが望ましい

63. 各パラメータの概略 入力バッファ データ量 経過時間 History サイズ Cushion の範囲 Cushion

64. 各パラメータの概略 経過時間 入力バッファ データ量 History サイズ Cushion の範囲 Cushion 過剰な入力バッファのデータ量を制限

65. Cushionの最適化 Cushion のパラメータが現在の CPU では適切なものではない Cushion のパラメータは、 RAT 開発時 (1997 ）の SUN Sparc 10 ワークステーション（ 30MHz ～ 80MHz ）から算出 現在の CPU に適応するように見直す必要がある

66. オーディオデバイスのバッファ時間の推移 120ms

67. オーディオデバイスのバッファ時間の推移 25ms

68. オーディオデバイスのバッファ時間の分布

69. パラメータの変更 以下のようにパラメータの変更を行った 25 250 History サイズ 0ms ～ 40ms 40ms ～ 500ms Cushion の範囲 RAT-SD RAT

70. Historyサイズ

71. Cushionの変化 (b) (a)

72. Cushion での解決 データ量 経過時間 経過時間 入力バッファ データ量 出力バッファ 閾値 を設定 遅延は最小限に 読み込み時間の減少 オーディオデータ 読み込み 出力バッファに渡すタイミングが遅れない

73. Cushion での解決 データ量 経過時間 経過時間 入力バッファ データ量 出力バッファ 閾値 を設定 遅延は最小限に 読み込み時間の減少 オーディオデータ 読み込み 出力バッファに渡すタイミングが遅れない

74. リードソロモン符号 リードソロモン（ 15,11 ）ブロック符号 15 パケット 4 パケット 11 パケット 情報パケット 冗長パケット ヘッダ データ

75. パケットロスによる ノイズの主観評価結果 RAT と RAT-SD の評価値はほぼ同じ RAT-SD の改訂による音質の劣化はみられない 非常に気になる 全く気にならない

76. 遅延の主観評価結果 RAT-SD では評価値 3.3 と気にならないといった回答が多い 遅延は十分に減らすことができている 非常に気になる 全く気にならない

77. 利用場面と各モードの対応 Broadcast モード Chorus モード Conversation モード 100ms 400ms 遅延 ( 転送遅延、ジッタ、処理遅延 ) 低 高 0ms 従来の RAT ロバスト性 低遅延化優先 ロバスト性優先 このモードを追加

78. 実験構成図 広島市立大学 白島小学校（ソプラノ） 南観音小学校 ( アルト） マメ de がんす ネットワーク 10Mbps Multicast 伴奏 伴奏 伴奏 伴奏＋ソプラノ 伴奏＋アルト アルト ソプラノ アルト＋ソプラノ 70 ～ 75ms 7 ms ジッター 2.1 ms 転送遅延 モノラル チャンネル 32kHz サンプリングレート Linear-16 （無圧縮） エンコード方式 実際の合唱