多目的な音声伝送システム

MRAT の開
発

岸田　崇志† 　河野　英太郎††　前田　
香織††　　
†
広島市立大学大学院情報科学研究科
††
広島市立大学情報処理センター
 はじめに
広域 LAN 等の広帯域ネットワークの普
―及
音声を用いた通信も一般化

音声伝送を用いた様々な利用場面の増加
― 遠隔講演，遠隔講義，遠隔合唱
etc.
一括りに音声伝送といっても利用場面は多岐にわた
る
それぞれの利用場面において必要とされる条件も異
なる
2002/11/14 第12回ITRC研究会 2
 目的

利用場面に応じた音声伝送ツールが必要

•それぞれの利用場面で要求される条件に
ついての検討
•利用場面に対応できる多目的な音声伝送
システムの開発

2002/11/14 第12回ITRC研究会 3
 音声伝送の利用場面
利用場面を大きく以下の 3 つに分類
 一方向が主，双方向での会話がほとんどない
　　　遠隔講演や遠隔講義
 議論が主，双方向の会話が多い
　　　遠隔会議や会話
 拠点間の音声のずれは許されず，双方向性が
非常に高い
　　　遠隔合唱や遠隔合奏
2002/11/14 第12回ITRC研究会 4
 利用場面と要求条件
　　　　 利用 遠隔合唱 遠隔会議 遠隔講演
場面 遠隔合奏 （会話） 遠隔講義
通信形態 多対多 多対多 一対多

双方向性 非常に高い 高い 低い

片方向の許 100ms 未満 400ms 未満 任意

容遅延時間 ITU-T G.114
より
パケット損失 低　 中 高
等の耐性（ロ
バスト性）
主な要求条件 音声のタイミ 会話に支障が 確実に音声を
ングを同期さ ないこと 届けること
せること

ロバスト性が高いほどパケット損失などに対する耐性が強い
2002/11/14 第12回ITRC研究会 5
 MRAT （ Multipurpose RAT)
それぞれの利用場面に対応するた
め・・・
 RAT （ Robust Audio Tool) を拡張し

，多目的な音声伝送に利用できる
MRAT （ Multipurpose RAT) の開発
 利用場面ごとに 3 つのモードをもつ
 Chorus モード・・・遠隔合唱，遠隔合奏
 Conversation モード・・・遠隔会議，会

話
 Broadcast モード・・・遠隔講義，遠隔講

2002/11/14
演 第12回ITRC研究会 6
 各モードの位置づけ
遅延 　 ( 転送遅延、 ジッタ、処 理遅延
)
遠隔講義・遠隔講演
400ms

遠隔会議・会話

100ms

遠隔合唱

0ms 低 高
ロバスト性
2002/11/14 第12回ITRC研究会 7
 利用場面と各モードの対応
遅延 　( 転送遅延、ジッタ、処理遅延 )

Broadcast モ
遠隔講義・遠隔講演
400ms ード
ロバスト性優先

遠隔会議・会話
Conversation モ
ード 従来の RAT
100ms

Chorus モー 遠隔合唱 この 2 モードを追

ド 加
低遅延化優先
0ms 低 高
ロバスト性
2002/11/14 第12回ITRC研究会 8
 Conversation モード
 許容遅延時間は 400ms 未満
 音声会議システムである RAT の機能を基本
にパラメータ設定のみで対応
設定項目 実験での設定値
エンコード方式 Linear-16 （無圧縮）
サンプリングレート 32kHz
チャンネル モノラル
送信側のパケット損失回復機 なし
構
受信側のパケット損失回復機 パターンマッチング方式
構
追加再生バッファ時間の制限 Min=0ms,max=1000m
2002/11/14
s
第12回ITRC研究会 9
 Chorus モード
 片方向の遅延時間 100ms 以内
 低遅延化優先

 オーディオデバイス上でのバッファ処
理のスケジューリングのパラメータを
変更　
→ 　低遅延化
2002/11/14 第12回ITRC研究会 10
 オーディオバッファの処理の問題
入力バッファ 他のプロセスに処
理を奪われる
データ量

オーディオデータ

読み込み 読み込みに時間がかかる 経過時間

出力バッファ
出力バッファに渡すタイミングが遅れ
る
データ量

出力バッファに渡
す

遅延が生じる
2002/11/14 第12回ITRC研究会 経過時間11
 Cushion での解決
入力バッファ

閾値を設
データ量

オーディオデータ 定

読み込み 読み込みに時間がかかる 経過時間

出力バッファ
データ量

出力バッファに渡
す

遅延が生じる
2002/11/14 第12回ITRC研究会 経過時間12
 Cushion での解決
RAT 開発時 (1997 ）の SUN
SPARC 10 ワークステーション
（ 30MHz ～ 80MHz ）から算出
入力バッファ
過剰な入力バッファのデータ量を制
されたもの
限
閾値を設
現在の CPU に基づいた閾値を設
データ量

オーディオデータ 定
定

読み込み 読み込み時間の減少 経過時間

出力バッファ
出力バッファに渡すタイミ
ングが遅れない
データ量

出力バッファに渡
す

2002/11/14 遅延時間の減少
第12回ITRC研究会 経過時間13
 Chorus モードでの改良
入力バッファ

現在の CPU に基づいた閾値を設

データ量

オーディオデータ
定

読み込み 経過時間
出力バッファ
データ量

出力バッファに渡
す

2002/11/14 第12回ITRC研究会 経過時間14

 Chorus モードでの改良
入力バッファ

現在の CPU に基づいた閾値を設

データ量

オーディオデータ
定

読み込み 経過時間
出力バッファ
データ量

出力バッファに渡
す

2002/11/14 さらに低遅延に
第12回ITRC研究会 経過時間15
 Chorus モードの弱点
 このようにしてコーラスモードでは低
遅延を果たしている

バッファ時間を少なくしたためにジッ
タ耐性などが低下　 ロバスト性の低下

2002/11/14 第12回ITRC研究会 16
 Broadcast モード
 ロバスト性を最大限に重視
 Reed-Solomon 符号を用いた FEC を実装

FEC （ Forward Error Correction ）

 送信側で訂正用データを追加して送信

 受信側で訂正

 Reed-Solomon 符号方式

 複数ビット（シンボル）単位でのエラー検出・訂
正
 バースト誤りに強い
2002/11/14 第12回ITRC研究会 17
 パケットフォーマット
 RTP 拡張ヘッダを付加し，それを FEC ヘッダとして
定義
　 12 　 8 　 12 　 8 　　　　　　
　　　 (Bytes)
IP UDP RTP RTP DATA
ext

　　　　　　　　　　
(bits)
0 　　　　　 8 　　　　　 16 　　　 24
　 32 extn_type extn_len
CS DS FEC sequence reserved

CS: code symbol size DS: the number of data symbols

2002/11/14 第12回ITRC研究会 18
 実装
 実装状況　→　実装済み
 Conversation モード
 Chorus モード 完成
 Broadcast モード

RAT に装備されているほぼ全ての音声 CODEC に
対応
 動作確認を行った環境
CPU PentiumⅢ 1.0GHz ～ PentiumⅡ300MHz
OS Vine Linux 2.1,Vine Linux2.1.5,Vine
Soundcard Linux2.5
SoundBlaster Live! Value

2002/11/14 第12回ITRC研究会 19
 MRAT の評価
 各モードでの遅延時間の測定
 Broadcast モード
 エラー回復能力を理論値と実測値との比較
 パケット損失が生じたネットワーク上での実際の
効果
 既存の RAT の FEC との比較
 RAT と MRAT の音質比較
 Broadcast モードを用いた実践
 Chorus モード
 遠隔合唱での実践実験
2002/11/14 第12回ITRC研究会 20
 遅延時間測定の実験環境
録音用 PC
元の音と HostB 経由の
音の時間軸の差を測定

録音 録音

メトロノー Host A Host B

ム
送信

Ethernet
CPU PentiumⅢ CPU PentiumⅢ 　
600MHz
100Mbps 1GHz
2002/11/14 第12回ITRC研究会 21
 遅延時間測定結果

モード 片側の遅延時間 許容遅延時間

Broadcast
１４３ [ms] 任意
(15,11)
Broadcast
１３８ [ms] 任意
(15,12)
Broadcast
１３８ [ms] 任意
(15,13)
Conversatio
１３２ [ms] 400ms 未満
n
Chorus ７２ [ms] 100ms 未満
この値は十分に速くトラフィックの少ないネットワークで測
定しており実際の MRAT の処理遅延に近い
実際はこの値に転送遅延が加算されたものになる
2002/11/14 第12回ITRC研究会 22
 Broadcast モードのエラー回復
パケットロス発生器 CPU PentiumⅡ 　
1,2,4,6,8,10 300MHz
% の確率でパ
OS Vine Linux2.1
ケット損失発
生！

Ethernet
100Mbps
FEC デコード
後のパケット損
失率を測定
Host A Host B
CPU PentiumⅢ 　 CPU PentiumⅢ 　
600MHz 1GHz
OS2002/11/14
Vine Linux2.5 第12回ITRC研究会OS Vine Linux2.1 23
 12
パケット損失 10 ％ FEC
10 なし
測定結果
～
～ ～
～
5
(15,13)実測値
(15 ，
(15,13)理論値
FEC復元後のパケット損失率 (%)

4
(15,12)実測値
13)
(15,12)理論値
3 (15,11)実測値
(15,11)理論値

2
(15 ，
12)
1

FEC あり (15,11) (15 ，

0 符号 11)
0 2 4 6 8 10 12
FEC復元前のパケット損失率 (%)
2002/11/14 第12回ITRC研究会 24
 Media Specific FEC との比
較
 RAT には Media Specific FEC （ RFC2198) が実装され
ている
primar secondar
エンコード方式を個々に選択でき y y
Linear-16(PCM) PCMμ-law
る
音声データパケットを複
製
送信ホス
ト
次のパケットにくっつけて送
信

欠落したパケットがあれば一
つ後のパケットにくっついて 受信ホス
いたものから復元 ト

2002/11/14 第12回ITRC研究会 25
 Media Specific FEC との比
較
 RAT に実装されている Media Specific FEC と今回新た
に実装した Reed-Solomon FEC との比較を行った
エンコード方式 Linear-16 ，サンプリング周波数 32kHz ，モノラルの場
合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 2.0 倍
※secondary encoding に linear-16 を用いた場合[kbps]

パケット損失 20% 下でのそれぞれの FEC の音質の比較

パケット損失 20%
Reed-
MediaSpecificFEC
2002/11/14 第12回ITRC研究会 Solomon(15,8)
の時 26
 MRAT と RAT の音質比較
　 RAT では、プツプツというノイズが目立
っていた、そのノイズに関しての評価を行う
 評価は

RAT,RAT(MediaSpecificFEC),MRAT(broad
cast モード ) の 3 つに関して 46 秒の音楽を
5 回ずつ流して評価を行った
 実験ネットワークのネットワークの状況

ジッタ 6 ～ 7ms
平均パケット損失率 0.76%
最大パケット損失率 5%
RTT 0.5ms
2002/11/14 第12回ITRC研究会 27
 MRAT と RAT の音質比較（続
き）
検出されたノイズ数
(個)
MRAT(Broadcast モー 3.4
ド)
RAT 36.4
RAT(Media Specific 16.4
FEC)
ノイズの検出は、ノイズが感じられる際高周波数帯に
大きな変動がみられることから、録音した音声に高速
フーリエ変換を行いその FFT スペクトルを元に観測を
行った。
46 秒の音楽をそれぞれ 5 回ずつ流した平均値である。
2002/11/14 第12回ITRC研究会 28
 Broadcast モード
での実践
佐賀大
学
広島市大－佐賀大　間
ジッタ： 4ms
JGN 平均パケット損失率：
（通信放送機 0.0004%
構： TAO ） RTT ： 14.8ms

広島市立大学

各拠点で送信に使用する帯域
音声：　 広島市大－広大　
間
ジッタ： 6ms
MRAT(160Kbps)
平均パケット損失率：
映像：　 0.01%
広島大学
Mpeg2ts(5Mbps)
2002/11/14 第12回ITRC研究会 29
 Chorus モードでの実践実験
 広島市立南観音小学校と広島市立白島
小学校で「マメ de がんすプロジェクト
」の実証実験ネットワーク（ 10Mbps
広域 LAN) を用いて遠隔合唱を行った
 各地点間はマルチキャストで伝送し、
MRAT （ Chorus モード ) で送信に使
用した帯域は 512Kbps
 両校の映像は MPEG2 伝送システムの
MPEG2TS を用いた

2002/11/14 第12回ITRC研究会 30
 実験構成図
白島小学校（ソプラノ）

伴奏
伴奏＋アル
広島市立大学
ト
ソプラ マメ de がんす 伴奏
ノ ネットワーク
70 ～ 10Mbps Multicast
75ms アルト＋ソプ
アル ラノ
ト エンコード方式 Linear-16 （無圧
伴奏
伴奏＋ソプラ サンプリングレー 縮）
32kHz
ト
ノ チャンネル モノラル
転送遅延 2.1 ms
南観音小学校 ( アルト）
2002/11/14 ジッター
第12回ITRC研究会 7 ms 31
 実際の合唱のスタイル
140ms

伴奏地
点
合唱として許容できる
70ms
合唱地
点

合唱地
点
2002/11/14 第12回ITRC研究会 32
 おわりに
 利用場面ごとに音声伝送に要求される
条件の検討
 それに基づいたシステムの実装，及び
各項目ごとの評価
 MRAT を用いて遠隔ゼミや遠隔合唱の
実践実験

2002/11/14 第12回ITRC研究会 33
 今後の課題（予定）
 さらに Chorus モード， Broadcast
モードを用い実践実験に使用
予定表
11 月 19 日：基町高ー南観音小の 2 拠点で遠隔合
奏
12 月中旬：基町高ー南観音小遠隔合唱

1 月中旬：白島小ー南観音小ー佐賀大付属中遠隔合
唱
2 月 26 日：りんけんバンドと白島小セッション？

2002/11/14 第12回ITRC研究会 34
 参考文献
 “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)

2002/11/14 第12回ITRC研究会 35
参考資料
 RAT の音質
RAT の音質に関して 15 名による主観評価を行った

15
12
9
人数

6
3
0
アナログ電話 AM放送 FM放送 音楽CD

音質

→ 　 FM 放送程度といった回答が多い
2002/11/14 第12回ITRC研究会 37
 パケットロスによる
ノイズの主観評価結果

全く気にならな 4
い
RAT
3 Chorus
評価値

非常に気にな
1
る
0 1 3 5
パケットロス (%)

通常の RAT と MRAT （ Chorus モード）では， Chorus

モードではジッタ等に対する耐性が若干減っていると想
定されるが，主観評価によるとほぼ同程度の音質と考え
られる
2002/11/14 第12回ITRC研究会 38
 CODEC と使用帯域
エンコード方式 使用帯域 RS エンコー RS エンコード後
[kpbs] の使用帯域
ド [kbps]
Linear-16 512 ○ 640
μ-law 256 ○ 320
A-law 256 ○ 320
G726-40 160 ○ 200
G726-40 128 ○ 160
G726-40 96 ○ 120
G726-40 64 ○ 80
DVI 128 ○ 160
VDVI 128 × 160
GSM
2002/11/14
52.8 ○
第12回ITRC研究会
66 39
 遠隔合唱の限界
 70ms という遅延時間は、光の速さ
（ 30 万 km/s ）で 2100km 進む距離
 これらの制限より遠隔合唱は世界的な
規模では現実的ではない
 ２００ ~ ３００ km 以内のメトロポリ
タンネットワーク内が現実的

2002/11/14 第12回ITRC研究会 40
 Chorus モードの遅延時間
 70ms という遅延時間は，音の速さ
（ 340m/s ）で 24m 進む距離
 オーケストラなどは大きなステージ上

で演奏を行っている
　→物理的にも 24m 離れることがある

70ms という値は十分実用的な値である
音は 1m 進むのに約 3ms かかる（音は遅い）
→ スピーカと合唱者の距離なども重
2002/11/14 第12回ITRC研究会 41
要
 Reed-Solomon 符号
 リードソロモン（ 15,12 ）ブロック符号

情報パケッ
ト
・・・ 12 パケッ
ト

15 パケッ
ト
冗長パケッ
ト
3 パケッ
ト

ヘッ
2002/11/14
デー 第12回ITRC研究会 42
 MSFEC のインターリーブに
ついての考察
 パケットの損失割合は減らないが，知覚的に落ちて
いるのを和らげるもの
 使用帯域を増やすことがないので有効
 インタラクティブな使用用途には向かない
→ 　幾つかのパケットをバッファするため

2002/11/14 第12回ITRC研究会 43
 ITU-T 　 G.114
 ITU-T G.114 では片方向の遅延限界の
基準を次のように定めている

 0 から 150ms 　
 大部分のユーザで受け入れ可能
 150 から 400ms
 管理者が品質に対する遅延の影響を把握している
場合、受け入れ可能
 400ms 以上
 例外を除き受け入れ不可能

2002/11/14 第12回ITRC研究会 44
 ITU-T 　 G.114
 片方向の遅延限界の基準を定めている

・ IP-Phone でもこの値を参考に片方向の遅延時
間を設定している例が多い
・会話などでは片方向の遅延時間が 150ms 未満
であることが理想
→Conversation モードでは 132ms

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

2002/11/14 第12回ITRC研究会 46
 FEC (Forward Error
Correction)
 送信側で訂正用データを追加して送信
 受信側で訂正
 リード・ソロモン符号方式
 複数ビット（シンボル）単位でのエラー検出・訂
正
 バースト誤りに強い
 複雑な演算を多用
 本システムの FEC の実装
 ``Forward Error Correcting Codes’’ ― Phil Karn
 http://www.eccpage.com/
 http://people.qualcomm.com/karn/code/fec/
2002/11/14 第12回ITRC研究会 47
 理論値
理論値 P は次のようになる．各パケット数の
組み合わせを（ N,K) とし，個々のパケットの
損失率を p とする． I はデータパケット K 個
中 FEC デコード後に損失しているパケット数
である．1 K
P= ∑ K Ci
i
K i =0
p i
(1 − p ) K −i

N −K
∑ N −K Cj p j (1 − p) N − K − j
J =t
0 if N − K < i ≤ K
t=
N − K − i + 1 if 0 ≤ i ≤ N − K

2002/11/14 第12回ITRC研究会 48
 Cushion について
Cushion は、 (1) 式のように定義される
x

∑ bi > t
i =1
(1)

i 　バッファ時間
bi 　バッファ時間 i[ms] かかるブロック数
ｔ　単位時間内に処理するブロックの個数
Cushion は、 (1) 式をみたす最小となる x[ms] と
なる
2002/11/14 第12回ITRC研究会 49
 Cushion について
ｔ は History サイズを 25 とすると、 23 となる
バッファ時間が小さいほうから
出現頻度の個数を 23 個カバーする範囲で Cushion を設定する
6

5 23 個
出現頻度

0
26ms
0 5 10 15 20 25 30 35 40

オーディオデバイスのバッファ時間 (ms)
2002/11/14 第12回ITRC研究会 50
 Cushion について
ｔ は History サイズを 25 とすると、 23 となる
バッファ時間が小さいほうから
出現頻度の個数を 23 個カバーする範囲で Cushion を設定する
6

5 23 個
出現頻度

0
0 5 10 15 20
26ms 30
25 35 40

オーディオデバイスのバッファ時間 (ms)
2002/11/14 第12回ITRC研究会 51
 Byte － ms 換算
 サンプリング周波数３２ｋ Hz
→ 一秒間 32000 回標本化
→1ms で 32 回標本化
 16bit で量子化
1 サンプル２ byte

1 ブロックでバッファリングに必要な時間
(ms) は
ブロック (byte)÷2÷32 　となる

2002/11/14 第12回ITRC研究会 52
 転送遅延
18

16

14

12

10
RTT(ms)

0
0 200 400 600 800 1000 1200 1400 1600
パケットサイズ(byte)

Ping でパケットサイズを 100byte ずつ増やしていっ

た時のグラフの切片を 2 で割ったものを転送遅延とし
2002/11/14 第12回ITRC研究会 53
た
 RAT(Robust Audio Tool)

Mbone の音声会議システ
ム RAT(Robust Audio
Tool)

•品質の悪いネットワークでも高品質な音声
•多地点同時に複数の人数で会議に参加できる（マル
チキャスト対応）
•数々のエンコード方式を選択できる（使用帯域を選
択）
2002/11/14 第12回ITRC研究会 54
 本システムでの実装
Reed-Solomon FEC は，複数パケッ
トを 1 ユニットとしユニット毎に RS
演算を行う
 FEC シーケンスはユニット内でのパケット

順序
cs
 CS はビット単位のシンボルの長さ（ 2 −1 FEC
処理ユニットに含まれるパケット数は　　
　　）
 DS はデータシンボルの長さ（データパ

ケットの個数） 第12回ITRC研究会
2002/11/14 55
 本システムでの実装（続き）
 Reed-Solomon 符号
 処理に複雑な演算を多用するため処理速度が
ネック

処理速度，処理遅延，処理の簡単化を考慮
1 シンボル 4 ビット (CS=4)
2 cs( −　　　　　
　→パケット 15 個 1 ) が 1 ユニット

2002/11/14 第12回ITRC研究会 56
 Reed-Solomon 符号
 リードソロモン（ 15,12 ）ブロック符号

情報パケッ
ト
・・・ 12 パケッ
ト

15 パケッ
ト
冗長パケッ
ト
3 パケッ
ト

ヘッ
2002/11/14
デー 第12回ITRC研究会 57
 Media Specific FEC
 Media Specific FEC は、 RFC2198(RTP Payload for
Redundant Audio Data) で規定

一つの送信パケットを次のパケットにくっつけて送信するというもので
ある。パケットロスが生じるとその冗長パケットから損失回復をする
2002/11/14 第12回ITRC研究会 58
 Media Specific FEC
Primary encoding Secondary
encoding
Linear-16(PCM) Linear-16(PCM)

Linear-16(PCM) PCMμ-law

Linear-16(PCM) LPC

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

2002/11/14 第12回ITRC研究会 60
 RAT での処理

RAT では、マシンの負荷状況に応じてオーディオデバイ
スのバッファリング時間を調節するスケジューリングを
行っている

一定期間オーディオデータを保持し、それをもとに出
力バッファで遅延が生じないようバッファリング時間
を設定する
調節されたバッファリング時間を Cushion と呼ぶ

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

2002/11/14 第12回ITRC研究会 62
 各パラメータの概略
入力バッファ
データ量 History サイズ

Cushion

Cushion の範囲 経過時間

2002/11/14 第12回ITRC研究会 63
 各パラメータの概略
入力バッファ
データ量 History サイズ

Cushion

Cushion の範囲 経過時間

過剰な入力バッファのデータ量を制限
2002/11/14 第12回ITRC研究会 64
 Cushion の最適化
 Cushion のパラメータが現在の CPU で
は適切なものではない
 Cushion のパラメータは、 RAT 開発時
(1997 ）の SUN Sparc 10 ワークステ
ーション（ 30MHz ～ 80MHz ）から算
出
 現在の CPU に適応するように見直す必
要がある

2002/11/14 第12回ITRC研究会 65
 オーディオデバイスのバッファ時間の推
移
オーディオデバイスのバッファ時間

140
120

100
80
(ms)

120m
60
s
40
20
0
0 20 40 60 80 100 120
経過時間 (sec)
2002/11/14 第12回ITRC研究会 66
 オーディオデバイスのバッファ時間の推
移
オーディオデバイスのバッファ時間

140
120

100
80
(ms)

60
40
20
2
0 5ms
0 20 40 60 80 100 120
経過時間 (sec)
2002/11/14 第12回ITRC研究会 67
 オーディオデバイスのバッファ時間の分
布

1.E+08
1.E+07
1.E+06
1.E+05
出現頻度

1.E+04
1.E+03
1.E+02
1.E+01
1.E+00
0 5 10 15 20 25 30 35 40
オーディオデバイスのバッファ時間 (ms)
2002/11/14 第12回ITRC研究会 68
 パラメータの変更

以下のようにパラメータの変更を行った

RAT RAT-SD
Cushion の範 40ms ～ 0ms ～ 40ms
囲 500ms
History サイ 250 25
ズ

2002/11/14 第12回ITRC研究会 69
 History サイズ
60
バッファリング時間の平均値 (ms)

RAT- SD
50
RAT
40

30

20

10

0
0 20 40 60 80 100 120
経過時間 (sec)

2002/11/14 第12回ITRC研究会 70
 Cushion の変化
100
90
(b)
80
Cushion (ms)

70 (a)RAT- SD
60 (b)RAT
50
40
30
20
(a)
10
0
0 20 40 60 80 100 120
経過時間 (sec)
2002/11/14 第12回ITRC研究会 71
 Cushion での解決
入力バッファ
データ量

オーディオデータ 閾値を設
定

読み込み 読み込み時間の減少 経過時間

出力バッファ
出力バッファに渡すタイミ
データ量

ングが遅れない

2002/11/14 遅延は最小限に
第12回ITRC研究会 経過時間72
 Cushion での解決
入力バッファ
データ量

オーディオデータ 閾値を設
定

読み込み 読み込み時間の減少 経過時間

出力バッファ
出力バッファに渡すタイミ
データ量

ングが遅れない

2002/11/14 遅延は最小限に
第12回ITRC研究会 経過時間73
 リードソロモン符号
 リードソロモン（ 15,11 ）ブロック符号

情報パケッ
ト
11 パケッ
ト

15 パケッ
ト
冗長パケッ
ト
4 パケッ
ト
ヘッ デー
ダ 2002/11/14 タ 第12回ITRC研究会 74
 パケットロスによる
ノイズの主観評価結果
全く気にならな 4
い RAT
3 RAT- SD
評価値

非常に気になる
1
0 1 3 5
パケットロス (%)
RAT と RAT-SD の評価値はほぼ同じ

RAT-SD の改訂による音質の劣化はみられな
い
2002/11/14 第12回ITRC研究会 75
 遅延の主観評価結果
全く気にならな
4
い

3
評価値

非常に気になる
1
RAT RAT- SD

RAT-SD では評価値 3.3 と気にならないといった回答が

多い
遅延は十分に減らすことができている

2002/11/14 第12回ITRC研究会 76
 利用場面と各モードの対応
遅延 　( 転送遅延、ジッタ、処理遅延 )

Broadcast モード
ロバスト性優
400ms
先

Conversation モード
従来の RAT
100ms
低遅延化優
Chorus
先 モード このモードを追
加
0ms 低 高
ロバスト性
2002/11/14 第12回ITRC研究会 77
 実験構成図
白島小学校（ソプラノ）

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