StreamSR : 評価の基準（応答時間）

1. 話者が発話を開始する
2. 話者が発話を終了し、クライアントプログラムが発話データをまとめる
3. クライアントプログラムがTCP経由でサーバにクエリを送る
↓
4. サーバがTCP経由でクエリを受け取る
5. クエリを処理する（音声認識処理）
6. サーバからTCP経由でクライアントに認識結果を送る
↓
7. クライアントが認識結果を受け取る

2.の終了から7.の終了までの応答時間を小さくすることを目標とする
---
模擬実験では、実際には発話はすでに完了しているため、
スケジュール表を元に、一定のタイミングで発話が完了したものとして
その時刻から応答時間を計測する。
「実際にTCP送信を始めた時刻」ではなく「スケジュール表に基づく発話終了時刻」
からの計測であるという点がポイントとなる。

StreamSR : 入力データレートとスループット

「CPUインテンシブならば入力データレート ∝ スループットになる」というのは思い込みだった。
同じ実験で測定した入力データレートとスループットを図示する。
下図を見る限り、入力データレートではなくスループットで学習すればうまくいくかも？

学習の方法、ビーム幅の決定方法は未定

StreamSR : ビーム幅と入力データレート

トリビアルなテストデータを用いて、ビーム幅に対する入力データレートを測定した。
ソースノード数 : 4、認識ノード数 : 16

一回目（認識ノードのCPU使用率は100%）


二回目（CPU使用率不明）


---
補足

ビーム幅を x と置くと、音声処理時間（実時間係数 : RTF）は Ax+B で定式化される（はず）
データ入力でバッファリングが起こる、などの関係上、入力データレート ≒ スループット となる。

なので、入力データレート ∝ 1/(Ax+B) になる（はず）

---
確認事項

/tmp/ /dev/shm/ などにファイルを置いて試してみる。
今回のテストでは低いビーム幅から高いビーム幅の順にスクリプトを回したが、
逆に高いのから順にすると結果が変わるか確認。

StreamSR : 入力ボトルネック

以前からの変更点
・システムの入力を file: から stcp: に変更
・学習ユニットと認識ユニットを統合

問題点
・stcp: に変更したからなのか、入力データレートが非常に低い
・認識ノードのCPU使用率が100%までいかない

解決案
・無理矢理すべての入力をひとつの file: からの入力にまとめる
・stcp: を使う場合、TCP入力スクリプトを改良、音声形式をMFCCに変更、など

StreamSR : 現状メモ(2)

（言語化されていない記事）

学習ユニット
Decoderでスループットが低い場合、当然それに従って、バッファリングが生じて入力データレートも低くなってしまう。（ボトルネック）

それでも、学習ユニット内のデコーダの数を一つに限定してしまえば、ビーム幅vsスループットの学習はできる。

問題は、「認識ユニットの入力データレート増大時にビーム幅を下げる」機能の実装である。
当然だが、認識器のスループット≦入力データレートにしかならない上に、
ボトルネックの影響があるので「ボトルネックがなかった場合の」入力データレートを知ることはできない。
（この値がわかるのであれば、それに応じてビーム幅の変更が可能である。）

---

ビーム幅vsスループット、あるいはビーム幅vs（ボトルネック付き）入力データレートの学習はできるので、現在の観測された入力データレートが学習値に近づいた場合にビーム幅を下げる、というような実装ならば可能。

User-defined sources are able to produce multiple streams.

IBMInfoSphereStreams-LangRef.pdf の28ページ (35/100) より

StreamSR : 現状の問題

ユーザ定義ソースからpunctuation0()が送られていない？

(追記 : 20100702)
先生に教えてもらった -o オプションが spadec --help から見つからなかった。
-U オプションかな？と思って試してみたけど、うまくいかなかった。

(追記2 : 20100707)
うまくいった。単純に punctuation を送るところまで処理がいっていなかっただけらしい
修正