タイムスタンプ付ストリームI/Oによる音の実時間処理栗田亮（東工大）千葉滋（東工大）光来健一（NTT未来ねっと研究所） 1 タイミングが重要な音の処理  自動伴奏システム ソリストに対しコンピュータが伴奏を合わせる  ソリストのメロディーの入力に対し伴奏データを出力で返す  入出力をリアルタイムに処理する必要がある ♪ ＯＵＴＩＮメロディー解析伴奏データ音程、音量、作成テンポ、etc ♪ 伴奏 2 音の入出力処理  Linuxカーネルにおける音の録音  サウンドデバイスにアクセスして行う  A/Dコンバータ・・・アナログ・デジタル変換器  割り込み・・・カーネルバッファにデジタルデータが格納される  read()・・・カーネルバッファからアプリケーションバッファへサウンドデータをコピー kernel application buffer アナログデータ buffer A/D  再生の場合は逆の流れ 3 音の処理のミス 原因 その１：ハードウェア～カーネル間でのデータ損失 → アナログ音の録音再生では高負荷時でもめったに起きない  割り込みの衝突は少ない その２：カーネル～アプリケーション間の転送の遅れ  ハードウェア～カーネル間の転送レートについていけなくなり、バッファリングでミスが生じる  OSに大きな負荷がかかると生じる 4 2つの処理ミス  音飛び 録音時に発生し、一部のデータが抜け落ちる カーネルバッファが一杯になって生じる 9 8 7 4 3 2 1 6 5  途切れ 9 8 7 4 3 2 1 アプリケーションへカーネル 再生時に発生し、再生が一時止まる カーネルバッファが空になって生じる 7 8 9 1 2 3 4 5 6 5 ハードウェアへ再生STOP カーネル従来のLinux  Linuxが備える実時間処理機能 優先度割り当て機能  指定したプロセスを優先して実行することが可能  問題点 完全な優先実行は不可能  優先度の高い処理が、優先度の低い処理やハードウェア割り込みによって妨げられる場合がある 処理ミスに対処できない  処理ミスを検知する機能がないので対処できない 6 リアルタイムLinuxによる対処  既存のリアルタイムLinux リアルタイムスケジューラを用いる実時間処理システム  ハードリアルタイム：RT-Linux, ART-Linuxなど  ソフトリアルタイム：Linux-SRT, QLinuxなど  問題点 マルチメディア処理には不向き（ハードリアルタイム）  ハードリアルタイムOSの応答性はあまり必要ではない 処理ミスに対処できない ユーザーの負担が大きい  システムの肥大化  プログラミングが複雑 7 提案するシステム TS-I/O (Time Stamp - I/O)  入出力（I/O）のタイムスタンプを利用するシステム 処理ミスに対処する機能を提供  TS-I/Oでの入力処理 I/Oデータがバッファに格納された時刻を記録する 音飛びの検知が可能  タイムスタンプとデータサイズを比較する kernel buffer サウンドデータ時刻0 4 6 音飛び 10 タイムスタンプ 0..4 6..10 size=8 tsize application buffer buf tbuf 8 TS-I/Oでの出力処理（１） 再生中の処理ミスへの対処 間が発生した場合、それ以降のデータをとばす 時間軸に沿った再生が可能 application buffer 0 サウンドデータ 5 7 kernel data0～5 buffer 7秒経過（2秒遅れ） data7～10 data5～10 0～5 play 5～7 no data! 7～10 play 9 TS-I/Oでの出力処理（２） タイムスタンプに従った再生処理 アプリケーションが渡したタイムスタンプに従って再生 録音時のミス（音飛び）に対処した再生が可能 application buffer size=8 音飛びしたサウンドデータタイムスタンプ kernel buffer 0～5 play 5～7 wait… 0..5 7..10 7～10 play 10 TS-I/Oの利点  シンプルな設計 I/Oのみをリアルタイム化 マシンの性能に依存しない実時間処理を可能に  カーネルレベルの処理 アプリケーションレベルではできない処理が可能  OS内のバッファリングでのミスの検知  全てのストリームに適応できる 全てのストリームにTS-I/Oを利用できれば、タイミング重視のプログラムの作成は非常に楽 汎用ルーチンを作ることで実装できそう 11 追加システムコール read_gettbuf(fd,buf,tbuf,size,tsize) read(fd,buf,size)+タイムスタンプの取り出し デバイスからの録音データとタイムスタンプを返す tbuf・・・タイムスタンプを格納するバッファ tsize・・・タイムスタンプのサイズ write_puttbuf(fd,buf,tbuf,size,tsize) write(fd,buf,size)+タイムスタンプの転送 デバイスに再生データとタイムスタンプを送る 12 TS-I/Oの実装  デバイスドライバの関数に処理を追加  タイムスタンプの付加 割り込み処理関数  関数が呼ばれた際にタイムスタンプを取得する  タイムスタンプを処理 read関数  タイムスタンプをアプリケーションに転送する write関数  タイムスタンプに従って、時間軸にそった同期再生を行う  再生処理中のミスに対して、その後のデータが時間軸にそうように処理をとばす 13 実験  オーバーヘッドを測定 割り込み関数、read関数、write関数のオーバーヘッド 計算機：PentiumⅢ 733MHz, メモリ 512MB 処理にかかったクロックを測定  割り込み関数のオーバーヘッド 割り込み関数1回あたりのオーバーヘッドを測定 割り込み関数呼び出しの周期： 5333 μsec 結果： 2.3 μsec → 割り込み関数の呼ばれる周期内に納まる小さい値 14 read関数のオーバーヘッド 10秒のデータを数回のread関数に分けて録音し、1回あたりのタイムスタンプ転送の時間を測定回数（1回あたりの時間）オーバーヘッド（μsec）割合（%） 10000回（1msec） 3.2 0.32 1000回（10msec） 5.4 0.054 100回（100msec） 33.1 0.031 呼び出す回数が多いほどオーバーヘッドは大きい この時間だけバッファにデータがたまるが、この程度なら問題ない 15 write関数のオーバーヘッド 10秒のデータを数回のwrite関数に分けて再生し、関数が1 回呼ばれてから終わるまでの処理時間を測定  今回はミスが起こらない場合のオーバーヘッドを測定回数（1回あたりの時間）オーバーヘッド（μsec）割合（%） 10000回（1msec） 8.8 0.88 1000回（10msec） 10.3 0.103 100回（100msec） 0 0 100回呼び出した場合、オーバーヘッドはほとんどなかった この時間だけバッファのデータが減っていくが、この程度なら問題ない 16 ネットワークにおけるTS-I/O（１） TS-I/Oの拡張・・・UDPを利用するマルチメディア処理に関して パケットの損失の検知 メディア内、メディア間の同期 処理時間の制御 受信側のアプリケーションに処理開始時間を指定する → これらの処理をOSが自動的にしてくれる 17 ネットワークにおけるTS-I/O（２）  QoS制御 バッファのデータが減ってきた場合、タイムスタンプをみてストリームを優先的に処理 サーバからのストリームをバッファリングしながら再生する場合に有効 アプリケーションではできない処理サーバークライアントタイムスタンプ Check! リングバッファ ♪ 出力 18 関連研究アプリケーションレベルの実時間処理  MPEG 映像や音声の圧縮符号化方式 各パケットにタイムスタンプを含むヘッダーを付加する  RTP(Real-time Transport Protocol) 映像や音声のストリーミングのためのプロトコル タイムスタンプなどを含むヘッダーを付加して送る  我々のTS-I/O 上の技術が提供する実時間処理をカーネルレベルで提供する  パケットの損失の検知、同期処理 19 実時間処理のレベルの比較 SOFT アプリケーション アプリケーション メディア内、メディア間の同期が可能 TS-I/O カーネルレベルの実時間処理 TS-I/O リアルタイムOS QoS制御 OS内のバッファリングミスの検知 リアルタイムOS リアルタイムスケジューリング HARD 20 まとめ  TS-I/Oを提案 Linuxにおけるカーネルレベルでの実時間処理を可能にする機能  今後の発展 TS-I/Oの拡張  ネットワークでのマルチメディア処理にTS-I/Oを適用 ルーチンの作成  現在、各デバイスドライバを書き換える設計 → 汎用ルーチンを作ることで、デバイスドライバへの変更をせずに処理を提供する予定 21