タイムスタンプ付ストリームI/Oによる音の実時間処理

Presentation on theme: "タイムスタンプ付ストリームI/Oによる音の実時間処理"— Presentation transcript:

1 タイムスタンプ付ストリームI/Oによる音の実時間処理
栗田 亮　（東工大） 千葉 滋　（東工大） 光来 健一　（NTT未来ねっと研究所）

2 タイミングが重要な音の処理 ♪ ♪ 自動伴奏システム ＩＮ ＯＵＴ 解析 伴奏データ 作成 ソリストに対しコンピュータが伴奏を合わせる
ソリストのメロディーの入力に対し伴奏データを出力で返す 入出力をリアルタイムに処理する必要がある ＩＮ ＯＵＴ ♪ ♪ 解析 伴奏データ 作成 音程、音量、 テンポ、etc 伴奏 メロディー

3 音の入出力処理 Linuxカーネルにおける音の録音 再生の場合は逆の流れ kernel application A/D
サウンドデバイスにアクセスして行う A/Dコンバータ・・・アナログ・デジタル変換器 割り込み・・・カーネルバッファにデジタルデータが格納される read()・・・カーネルバッファからアプリケーションバッファへサウンドデータをコピー 再生の場合は逆の流れ kernel application アナログデータ buffer buffer A/D

4 音の処理のミス 原因 その１： ハードウェア～カーネル間でのデータ損失 → アナログ音の録音再生では高負荷時でもめったに起きない
その１：　ハードウェア～カーネル間でのデータ損失 →　アナログ音の録音再生では高負荷時でもめったに起きない 割り込みの衝突は少ない その２：　カーネル～アプリケーション間の転送の遅れ ハードウェア～カーネル間の転送レートについていけなくなり、バッファリングでミスが生じる OSに大きな負荷がかかると生じる

5 2つの処理ミス 音飛び 途切れ 録音時に発生し、一部のデータが抜け落ちる カーネルバッファが一杯になって生じる
再生時に発生し、再生が一時止まる カーネルバッファが空になって生じる 6 5 アプリケーションへ カーネル ハードウェアへ 再生STOP カーネル

6 従来のLinux Linuxが備える実時間処理機能 問題点 優先度割り当て機能 完全な優先実行は不可能 処理ミスに対処できない
指定したプロセスを優先して実行することが可能 問題点 完全な優先実行は不可能 優先度の高い処理が、優先度の低い処理やハードウェア割り込みによって妨げられる場合がある 処理ミスに対処できない 処理ミスを検知する機能がないので対処できない

7 リアルタイムLinuxによる対処 既存のリアルタイムLinux 問題点 処理ミスに対処できない
リアルタイムスケジューラを用いる実時間処理システム ハードリアルタイム：RT-Linux, ART-Linuxなど ソフトリアルタイム：Linux-SRT, QLinuxなど 問題点 マルチメディア処理には不向き（ハードリアルタイム） ハードリアルタイムOSの応答性はあまり必要ではない 処理ミスに対処できない ユーザーの負担が大きい システムの肥大化 プログラミングが複雑

8 提案するシステム TS-I/O (Time Stamp - I/O)
処理ミスに対処する機能を提供 TS-I/Oでの入力処理 I/Oデータがバッファに格納された時刻を記録する 音飛びの検知が可能 タイムスタンプとデータサイズを比較する kernel buffer application buffer size=8 サウンド データ buf 時刻 4 6 10 tsize 音飛び タイム スタンプ 0..4 6..10 tbuf

9 TS-I/Oでの出力処理（１） 再生中の処理ミスへの対処 間が発生した場合、それ以降のデータをとばす 時間軸に沿った再生が可能
application buffer kernel buffer data0～5 5 7 0～5 play 5～7 no data! 7～10 play サウンド データ 7秒経過（2秒遅れ） data7～10 data5～10

10 TS-I/Oでの出力処理（２） タイムスタンプに従った再生処理 アプリケーションが渡したタイムスタンプに従って再生
録音時のミス（音飛び）に対処した再生が可能 application buffer kernel buffer size=8 0～5 play 5～7 wait… 7～10 play 音飛びした サウンド データ 0..5 7..10 タイム スタンプ

11 TS-I/Oの利点 シンプルな設計 カーネルレベルの処理 全てのストリームに適応できる I/Oのみをリアルタイム化
マシンの性能に依存しない実時間処理を可能に カーネルレベルの処理 アプリケーションレベルではできない処理が可能 OS内のバッファリングでのミスの検知 全てのストリームに適応できる 全てのストリームにTS-I/Oを利用できれば、タイミング重視のプログラムの作成は非常に楽 汎用ルーチンを作ることで実装できそう

12 追加システムコール read_gettbuf(fd,buf,tbuf,size,tsize)
read(fd,buf,size)+タイムスタンプの取り出し デバイスからの録音データとタイムスタンプを返す tbuf・・・タイムスタンプを格納するバッファ tsize・・・タイムスタンプのサイズ write_puttbuf(fd,buf,tbuf,size,tsize) write(fd,buf,size)+タイムスタンプの転送 デバイスに再生データとタイムスタンプを送る

13 TS-I/Oの実装 デバイスドライバの関数に処理を追加 タイムスタンプの付加 タイムスタンプを処理 割り込み処理関数 read関数
関数が呼ばれた際にタイムスタンプを取得する タイムスタンプを処理 read関数 タイムスタンプをアプリケーションに転送する write関数 タイムスタンプに従って、時間軸にそった同期再生を行う 再生処理中のミスに対して、その後のデータが時間軸にそうように処理をとばす

14 実験 オーバーヘッドを測定 割り込み関数のオーバーヘッド 割り込み関数、read関数、write関数のオーバーヘッド
計算機：PentiumⅢ 733MHz, メモリ 512MB 処理にかかったクロックを測定 割り込み関数のオーバーヘッド 割り込み関数1回あたりのオーバーヘッドを測定 割り込み関数呼び出しの周期：　5333 μsec 結果：　2.3 μsec 　→　割り込み関数の呼ばれる周期内に納まる小さい値

15 read関数のオーバーヘッド 10秒のデータを数回のread関数に分けて録音し、1回あたりのタイムスタンプ転送の時間を測定
呼び出す回数が多いほどオーバーヘッドは大きい この時間だけバッファにデータがたまるが、この程度なら問題ない 回数（1回あたりの時間） オーバーヘッド（μsec） 割合（%） 10000回（1msec） 3.2 0.32 1000回（10msec） 5.4 0.054 100回（100msec） 33.1 0.031

16 write関数のオーバーヘッド 10秒のデータを数回のwrite関数に分けて再生し、関数が1回呼ばれてから終わるまでの処理時間を測定
今回はミスが起こらない場合のオーバーヘッドを測定 100回呼び出した場合、オーバーヘッドはほとんどなかった この時間だけバッファのデータが減っていくが、この程度なら問題ない 回数（1回あたりの時間） オーバーヘッド（μsec） 割合（%） 10000回（1msec） 8.8 0.88 1000回（10msec） 10.3 0.103 100回（100msec）

17 ネットワークにおけるTS-I/O（１） TS-I/Oの拡張・・・UDPを利用するマルチメディア処理に関して
パケットの損失の検知 メディア内、メディア間の同期 処理時間の制御 受信側のアプリケーションに処理開始時間を指定する →　これらの処理をOSが自動的にしてくれる

18 ♪ ネットワークにおけるTS-I/O（２） QoS制御 サーバー クライアント
バッファのデータが減ってきた場合、タイムスタンプをみてストリームを優先的に処理 サーバからのストリームをバッファリングしながら再生する場合に有効 アプリケーションではできない処理 サーバー クライアント タイムスタンプ Check! ♪ 出力 リングバッファ

19 関連研究 アプリケーションレベルの実時間処理
関連研究 アプリケーションレベルの実時間処理 MPEG 映像や音声の圧縮符号化方式 各パケットにタイムスタンプを含むヘッダーを付加する RTP(Real-time Transport Protocol) 映像や音声のストリーミングのためのプロトコル タイムスタンプなどを含むヘッダーを付加して送る 我々のTS-I/O 上の技術が提供する実時間処理をカーネルレベルで提供する パケットの損失の検知、同期処理

20 実時間処理のレベルの比較 アプリケーション TS-I/O リアルタイムOS リアルタイムスケジューリング SOFT
メディア内、メディア間の同期が可能 TS-I/O カーネルレベルの実時間処理 QoS制御 OS内のバッファリングミスの検知 リアルタイムOS リアルタイムスケジューリング SOFT アプリケーション TS-I/O リアルタイムOS HARD

21 まとめ TS-I/Oを提案 今後の発展 Linuxにおけるカーネルレベルでの実時間処理を可能にする機能 TS-I/Oの拡張 ルーチンの作成
現在、各デバイスドライバを書き換える設計 →　汎用ルーチンを作ることで、デバイスドライバへの変更をせずに処理を提供する予定