「Push-To-Talk」基幹系システムを用いた、全二重通信方式用の全自動PTT案に関する検討。

　……これは単なるメモ。
　「ウィルコム定額プラン方式」と「手動PTT方式」の中間。

• マイクONの間録音し続ける。
• マイクOffになったらエンコードして、エラー訂正つきでパケットを投げる。

　……って、この方法では従来PTTよりも使いづらいか。

　手動PTTのような「半二重通信(一人はしゃべるだけ、他は聞くだけ)」ではなくて、ここで掲げるのは「全二重通信(一対一で喋りつつ聞く)」のための仕掛けです……一台の端末で「送信しつつ受信する」様に設計する点に注意。

• マイクOnの間は次の処理をして、エラー訂正付きパケットを投げる。
  • とりあえず録音開始。バッファはFIFOで、容量は10秒ぐらいか。
  • 録音内容は逐次「音声認識機能」を用いて内容抽出し、逐次「形態素解析」を行っていく。
    • 録音中の音声に対して「カラオケの字幕を振るように」音声認識結果を当てて、かつ「区切りマークを置いていく為に」形態素解析を用いる、と。
  • 形態素解析の結果、音声を区切って送出してもよい場面を見つけた時点で、「先頭〜区切り位置」を切り出す。
    • バッファはFIFOなので、切り出した後はその直後の音声がFIFOバッファの先頭に来ることになる。
    • バッファが満杯になりそうになったら、多少怪しい区切りマーク部分でも切り出してしまう。
  • 形態素解析に基づき切り出した音声データは、ネットワークの遅延度合いと速度に見合う圧縮率で圧縮し、エラー訂正つきで送出する。
    • その際、切り出しに用いた「音声認識結果」と「形態素解析による区切りデータ」も一緒のパケットにまとめて送出する。
• 受信側では次の処理を行う。
  • エラー訂正付きパケットを受け取ったら、「パケット受領通知」を送り返してから「エンコードして再生する」。
    • ユーザが表示するように設定した場合については、「パケットに含まれている音声認識結果と形態素解析の区切りデータ」も端末画面上に表示する。
• 送信側では次の処理を行う。
  • パケットを送出してから「パケット受領通知」が帰ってくるまでの時間を測定しておく。
    • この時間が妙に長い場合は「より短時間でデータが通るように圧縮率を上げる」ようにエンコーダの設定を変更する。
    • 逆にすぐ返答が来る場合は「より明瞭度が上がるように圧縮率を下げる」ようにエンコーダの設定を変更する。
  • 「通話終了」ボタンを押さない限りは、振り出しに戻る。

　……と、こんな感じのシステムを作れば

• 「PTTスイッチ不要」
• 「ネットワークの伝送速度を十分活用できる」
• 「音声通話でありながら、ネットワーク遅延が発生しても会話はとりあえず成立する」

というシステムができる、と。
　こういう方式であれば、今までは遅延の少ない有線系でしか使えなかった「パケット音声交換」が、遅延の大きい無線系でもとりあえずは使えそうな気がする。

　……もっとも、ネットワークに負荷が掛からないという利点を得るために

• 「ユーザに対して途切れ途切れの音声を提供する」
  • 「長い音声の後の短い音声」は続けて再生できるけど、「短い音声の後の長い音声」は最大10秒途切れてしまう。
• 音声品質がダイナミックに変化してしまう。
• 自然さをあげようとすれば「10秒近くの遅延が発生する」し、遅延を少なくしようとすれば「形態素解析での区切りマークが来るたびに音声がぶつ切りにされてしまう」。
• そもそも「音声認識エンジン」と「形態素解析エンジン」と「圧縮率可変型の音声圧縮・展開エンジン」を必要としてしまう。

という重荷を背負うのは、コスト的に見合わないような気はしますけれども。

　……うーん、完璧に夢物語(というか妄言)ですなorz