JP6652726B2 - 情報処理装置、情報処理システム、情報処理装置の制御方法、情報処理システムの制御方法、およびプログラム - Google Patents

Description

ネットワークを介して音声を送受信するアプリケーションにおいて、ネットワークの遅延などによる音声の遅延を回復する技術に関する。

ネットワークを介して音声を送受信するアプリケーションにおいて、ネットワークの揺らぎなどを考慮し、例えば、サーバ上に各クライアントからの上り音声を蓄積するためのキューを用意する場合がある。しかし、キューを持つことにより、キューにデータが蓄積していくことで遅延が増大する状況も発生する。

クライアントが受信したそれぞれのクライアントの音声から無音を破棄することで遅延を回復するこことが可能であるが、サーバでミキシングする場合、クライアントが受信する下り音声はサーバでミキシングされた１つの音声データとなる。その場合、いずれか１つのクライアントが発話中であれば、そのミキシングした音声は無音ではないため破棄されず、遅延を回復することはできない。

そのため、下り音声をサーバでミキシングしてクライアントに送信する場合には、当該クライアントとサーバ間の下りの通信が揺らぐなどした際に、他のクライアントにはすでに送信済みである音声が、当該クライアントにだけ遅れて送信されるといったことが発生し、その後に受信する音声がすべて遅延する状態を維持してしまうことになる。

以上のように遅延が増大すると具体的には以下のような問題が発生する。複数拠点で遠隔会議をしているとした場合、時間の経過とともに音声の遅延が蓄積し、会議の進行に支障が出る場合がある。例えば、相手が発話していないと思い、発話した場合に音声が重複し、聞き取れない可能性がある。また、質問に対する回答が来ていないと思い再度質問するなど、会話が成り立たない可能性がある。

特許文献１における通信システムは、音声データを送信装置から受信装置に送信するシステム構成であって、送信側装置は、音声データの音量レベルに基づいて無音状態情報を生成して、送信装置は音声データを蓄積して遅延時間を調整するジッタ吸収バッファと、ジッタ吸収バッファに蓄積されている音声データ量が設定した許容蓄積量を超過した場合に、当該許容蓄積量を増加させ、ジッタ吸収バッファに蓄積されている音声データ量が一定時間、設定した許容蓄積量内である場合に、無音状態を示す音声データを廃棄して、当該許容蓄積量をデフォルト値に戻すジッタバッファ調整部を備えたものである。

特開２０１２−１２４６８９

しかしながら、特許文献１に記載の技術においては、あくまで送信端末、受信端末が一対一の関係にある場合に限られており、例えば、会議システムのように、一対多の関係であって、また、１つのクライアントから他のクライアントに直接音声データを送るわけではなく、例えば会議サーバにおいて他のクライアント端末の音声データをミキシングしてから、クライアント端末に音声データを送信する場合には対応できない。

本発明の目的は、上記問題に鑑み、遅延の発生している可能性のある端末に対する音声の遅延をスムーズに回復するための技術を提供することである。

本発明は、取得した音声データの送信と他の端末の音声データの再生が可能な複数の端末と通信可能であり、複数の端末から受信した複数の音声データを記憶する記憶手段を備える情報処理装置であって、前記記憶手段に記憶された、前記端末の音声データを用いて、各端末に送信する合成音声データを生成する生成手段と、前記生成手段により生成された合成音声データを、送信対象の端末に送信すべく出力する出力手段と、所定の条件を満たす音声データを、前記生成手段により生成される前の、前記記憶手段に記憶された音声データの中から特定する特定手段と、を備え、前記生成手段は、前記端末に対応する前記出力手段で出力された合成音声データが所定量蓄積されている場合に、前記特定手段により特定された音声データをスキップして所定量蓄積があるとされた前記端末に送信する合成音声データを生成することを特徴とする

本発明により、遅延の発生している可能性のある端末に対する音声の遅延をスムーズに回復することが可能となった。

本発明の実施の形態に係るシステム構成を示す図の一例である。 本発明の実施の形態に係るハードウェアの構成を示す図の一例である。 本発明の実施の形態に係るソフトウェアの機能構成を示す図の一例である。 本発明の実施の形態に係るクライアント端末における再生遅延の発生と回復処理を示すイメージの一例を示す図である。 本発明の実施の形態に係る会議サーバにおける、音声情報がキューに格納される状況を示すイメージの一例を示す図である。 本発明の実施の形態に係る会議サーバにおける、クライアント端末からの受信状態に基づく遅延状態の発生と回復処理を示すイメージの一例を示す図である。 本発明の実施の形態に係る会議サーバにおける、クライアント端末への送信状態に基づく遅延状態の発生と回復処理を示すイメージの一例を示す図である。 本発明の実施の形態に係るクライアント端末における、再生遅延回復処理のフローチャートの一例である。 本発明の実施の形態に係る会議サーバにおける、クライアント端末からの受信状態に基づく遅延回復処理のフローチャートの一例である。 本発明の実施の形態に係るクライアント端末への送信状態に基づく遅延回復処理のフローチャートの一例である。 図７において遅延が発生した場合の遅延回復方法をキューのイメージを用いて説明する図の一例である。

以下、本発明の実施の形態を、図面を参照して詳細に説明する。

図１は、本発明の実施の形態に係るシステム構成を示す図の一例である。クライアント端末１０１（複数）と会議サーバ１０２は、ネットワークを介して接続可能である。

会議システム（図１）においては、会議に参加するユーザのうち、いずれか（便宜上、主催者とする）が、クライアント端末１０１から会議サーバ１０２にアクセスして、会議室を予約する。会議室とは、可能の会議スペースであって、後述するところの「招待された参加者」だけが入室可能にすることも可能である。また、フリースペースとして、不特定のユーザが参加できたり、発言はできないが、視聴のみ可能であったりしても良い。

主催者は、会議を特定する会議ＩＤ（あるいは会議室ＩＤ、部屋番号など）、その会議室を使用する時刻などを決定し、特定の参加者を招待する場合には、会議サーバに登録されている参加者の通知先（例えばメールアドレス）などを用いて、参加を呼びかけるようにしてもよい。特定のユーザのみを参加させるためには、前記通知の中に、当該会議室に入室するためのパスワードを記載可能とする。

ここで、各クライアント端末１０１ａ〜ｃのユーザ（実際の会議参加者）のマイクロフォン（不図示）、による音声データ、あるいはカメラ（不図示）による撮像データは、図４〜図７でそのイメージとして示すように、一旦、会議サーバ１０２に送信される。例えば音声については各々のクライアント端末１０１から会議サーバ１０２に対して、クライアント端末１０１の個数分の上り音声として送信される。

前述の上り音声は、会議サーバ１０２で、複数のクライアント端末１０１から受信した上り音声をミキシングし、他のクライアント端末１０１に配信する（下り音声データ）。ただ、ミキシングに際して、ある上り音声を送信したクライアント端末１０１に送り返される下り音声データには、その端末自身の音声をミキシングすることは不要である。

ここで、クライアント端末１０１と会議サーバ１０２を別筐体として記載しているが、ある１つのクライアント端末１０１が、会議サーバ１０２の機能を同じ筐体に構成されるようにしても良い。

なお、本発明の実施形態においては、会議システムを例として説明を進めるが、必ずしも会議システムに限らず、例えばネットワークを介して音声の交換をし、ネットワークの遅延などによりパケット(音声データを含むデータ)の遅延が発生する場合に利用可能な技術として提供する。

図２は、本発明の実施の形態に係るハードウェアの構成を示す図の一例である。図２に示すように、クライアント端末１０１、会議サーバ１０２は、システムバス２０４を介してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０２、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０３、入力コントローラ２０５、ビデオコントローラ２０６、メモリコントローラ２０７、通信Ｉ／Ｆコントローラ２０８等が接続された構成を採る。 ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や、各サーバあるいは各ＰＣが実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。また、本発明を実施するために必要な情報が記憶されている。なお外部メモリはデータベースであってもよい。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０３あるいは外部メモリ２１１からＲＡＭ２０２にロードし、ロードしたプログラムを実行することで各種動作を実現する。

また、入力コントローラ２０５は、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。

ビデオコントローラ２０６は、ディスプレイ２１０等の表示器への表示を制御する。尚、表示器は液晶ディスプレイ等の表示器でもよい。これらは、必要に応じて管理者が使用する。

メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、あるいは、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｍｅｍｏｒｙ Ｃａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ａｓｓｏｃｉａｔｉｏｎ）カードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ２０８は、ネットワークを介して外部機器と接続・通信し、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いた通信等が可能である。

尚、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上に表示することが可能である。また、ＣＰＵ２０１は、ディスプレイ２１０上のマウスカーソル（図示しない）等によるユーザ指示を可能とする。

本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイルおよび各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明についても後述する。

図３は、本発明の実施の形態に係るソフトウェアの機能構成を示す図の一例である。クライアント端末１０１と会議サーバ１０２のソフトウェア構成要素と各記憶部、およびそれらの間のデータの受け渡し（端末３から音声データ３２８等に関連付けられた点線矢印を除く）を図で示したものである。

まず、音声データの流れについて概略を説明する。クライアント端末１０１が、ユーザから音声の入力を受け付けると、音声データに変換され会議サーバ１０２に送信される。複数のクライアント端末１０１から会議サーバが受信した音声データは、クライアント端末１０１ごとに用意されたキューに格納される。あるクライアント端末１０１に送信される音声データは、当該クライアント端末１０１自体の音声データ（に対応するキュー）を除き、他のクライアント端末１０１に対応するキューから音声データを１つずつ取得してミキシングし、クライアント端末１０１に送信する。ミキシングされた音声データを受信したクライアント端末１０１は、（当該クライアント端末１０１自体の音声データはミキシングされていない）他のクライアント端末１０１のミキシングされた音声データを再生することでユーザは、音声を聴くことが出来る。

クライアント端末１０１は、音声入力部３１１において、ユーザが使用するマイクなどの接続機器により音声データの入力を受け付ける。入力を受け付けた音声データは、音声送信部３１２から、会議サーバ１０２に送信される。ここで、音声データは、一定のサイズ（例えば、時間を基準として１０ミリセカンド分の入力された音声など）に区切られる。以降の説明で「音声データ」と呼ぶ場合には、この一定のサイズに区切られた入力音声のデータを意味することにする。これはあくまで例であり、データのビット数など会議システムでの基準に従うものとする。

クライアント端末１０１から送信された音声データ（上り音声データ）は、会議サーバ１０２の音声受信部３２１において、受信される。受信した音声データは、ミキシング用音声記憶部３２６に格納される。ミキシング用音声記憶部３２６は、会議に参加している各々のクライアント端末１０１に対応してキューを用意し、ある程度の数の音声データを記憶する。図３においては、ミキシング用音声記憶部３２６のうち、各々のクライアント端末１０１に対応してキューの１つ１つの要素を端末１〜端末３に対応して縦方向（例では７つの矩形）に示している。

音声受信時に、上りチェック部３２２により上り音声データ受信（取得）が原因で、処理の遅延が発生していると判断された場合には、遅延回復処理が行われる。具体的には、この処理は、受信したクライアント端末１０１ごとに行われ、対応するキューに格納されている音声データの数が、サーバ閾値記憶部３２７の上り遅延閾値に基づき、所定数を上回っていると判断された場合に、無音データの削除処理をする。

ここで、各キューに格納される音声データの一単位は１つの矩形に対応するものであり、より詳細には、音声データ３２８と送信済端末情報３２９のペアを格納する。音声データ３２８は、前述のクライアント端末１０１から受信した音声データである。一方、受信された音声データは、他の端末から受信した音声データとミキシングして、会議サーバ１０２から、各々のクライアント端末１０１に送信（ミキシング音声送信部３２３）される。その際、何らかの状態（例えばネットワークの回線速度の違い）により、送信済のクライアント端末１０１と、未送信クライアント端末１０１とが発生する。そこで、後述の遅延回復処理をクライアント端末１０１ごとに処理できるよう、送信済のクライアント端末１０１か、未送信のクライアント端末１０１かの情報を「送信済端末情報３２９」に記載する。データ構成は如何様でもよく、送信済／未送信のクライアント端末１０１が識別できればよい。

なお、あるクライアント端末１０１へ送信する音声データのミキシングに際して、もともと当該クライアント端末１０１から受信した音声データはミキシングする対象から省く。即ち、自分自身以外のクライアント端末１０１から送られた音声データをミキシングする。

下りチェック部３２４は、ミキシング音声送信部３２３がクライアント端末１０１に音声データを送信する際に、ミキシングすべきクライアント端末１０１（即ち、送信するクライアント端末１０１以外のクライアント端末１０１）関する遅延回復処理をする。具体的には、この処理は、ミキシングする際に、サーバ閾値記憶部３２７の下り遅延フラグ(クライアント端末１０１ごとに存在する)が“オン”になっている場合に、各キュー内の無音データをスキップし、次の音声データをミキシングする。

下りチェック部３２４による遅延回復処理の完了後（遅延回復の必要がないと判定された場合を含む）、ミキシングされたデータは、所定のクライアント端末１０１に送信される。なお、会議サーバ１０２の処理において、音声受信部３２１とミキシング音声送信部３２３は、同期した処理である必要はない。

クライアント端末１０１のミキシング音声受信部３１３においては、会議サーバ１０２が、当該クライアント端末１０１以外の音声データをミキシングしたデータを受信し、受信音声記憶部３１６（キュー）に格納する。その際に、端末閾値記憶部３１７の再生遅延閾値に基づき、所定数を上回っていると判断された場合に、無音データの削除処理をする。

音声再生部３１５においては、受信音声記憶部３１６（キュー）からミキシングされた音声を取り出し、再生する。なお、クライアント端末１０１の処理において、ミキシング音声受信部３１３と音声再生部３１５は、同期した処理である必要はない。

音声の遅延回復処理は、クライアント端末１０１、会議サーバ１０２の双方で実行される。それぞれの遅延回復処理の概要を、音声データを格納するキューのイメージを用いて図４（クライアント端末１０１側）、図５〜図７（会議サーバ１０２側）について説明する。

図４は、本発明の実施の形態に係るクライアント端末における再生遅延の発生と回復処理を示すイメージの一例を示す図である。図４においては、１）遅延が発生していない状態、２）遅延が発生している状態、３）遅延回復方法、について説明する。なお、図４〜図７で説明する本発明の実施の形態に係わるキューはすべてＦＩＦＯとして説明する。まず「遅延が発生していない状態」について１）を用いて説明する。

（１）まずクライアント端末１０１は、会議サーバ１０２から音声データ（ミキシングされた音声データ）を受信する。
（２）その音声データを受信音声記憶部３１６に再生する待ち状態のデータとして格納する。

（３）図４の例では、受信した「Ａ１」のみが格納されているが、再生遅延閾値に基づき、所望の範囲の個数であれば遅延とはみなさいとしてよい。キューは、ＦＩＦＯであり、先に格納された音声データが先に取り出され再生される。

（４）キューの先頭にきた音声データは、音声再生部３１５により取り出され再生されることにより、当該クライアント端末１０１のユーザが聞くことが出来る。

以降の図４における説明で、遅延が発生する／しないの違いはあるものの、この（１）〜（４）の流れは同じである。

次に「遅延が発生している状態」について２）を用いて説明する。例えば、ネットワークの遅延などにより複数のパケット（便宜上音声データと同じ記号で表す。例ではＡ１〜Ａ７の７個）を、ほぼ同時にクライアント端末１０１にて受信したとする。クライアント端末１０１のキュー（受信音声記憶部３１６）には７個の音声データが蓄積され、音声データの再生が遅延することになる。

これ以降の処理において、再生のためキューから削除されていく音声データと、受信してキューに格納する音声データは原則として同一のタイミングであるため、遅延の速度は一定になる（自然に遅延が回復することはない、ということ）。

従って、何らかの理由により、再度の遅延が発生すると、その遅延した音声データの総数は、次第に蓄積されていき、最終的には、会議の通話にユーザが違和感を感ずるレベルに達する。すなわち、カメラで撮影した画像が別に送受信されている場合には、発言の画像と音声が著しくずれる、また他のクライアント端末１０１との発言内容の前後関係がおかしくなってくる、などが考えられる。

従って、前述の通り、再生遅延閾値に基づき、所望の範囲の個数であれば遅延とはみなさいが、所定の範囲を超えた場合には、再生時の遅延回復処理を行う必要がある。

図４の最後に「遅延回復方法」について３）を用いて説明する。すなわち、再生遅延閾値に基づき、所望の範囲の個数を超えたとして、遅延回復処理を行う。キューにある音声データには、Ａ１〜Ａ７の音声データが格納されているが、このうち「（）」が付与された音声データ（Ａ２、Ａ４、Ａ５、Ａ６を例えば（Ａ２）と記載したもの）については、「無音データ」であるとする。ここで無音データとは、システム上「音声が含まれていないとみなす音声データ」である。音声データが無音データであるか否かの判定については「特開２０００−３１２２２３」などにより周知の技術であるため、説明を省略する。

音声データの再生には、キューの先頭から音声データを１つずつ取得して再生するが、取得する際にキューに格納されている音声データの数をカウントし、その数が、再生遅延閾値に基づき、所望の範囲の個数を超えた場合には、遅延回復処理を開始する。その場合、キューに格納されているすべての音声データを確認し、無音データを削除していく。なお、遅延回復処理は、他の処理に割り込まれることなく一気に処理を行う。

図５は、本発明の実施の形態に係る会議サーバにおける、音声情報がキューに格納される状況を示すイメージの一例を示す図である。図５は、遅延が発生していない場合の状態を示す。
（１）まず、会議サーバ１０２は、クライアント端末１０１ごとに音声データを受信する。

（２）次に、受信した音声データを、ミキシング用音声記憶部３２６においてクライアント端末１０１ごとに用意したキューに格納する。格納する情報は、図３で説明したように音声データ３２８だけではなく、他のクライアント端末１０１が当該音声データをミキシングして送信済であるかどうかを、他のクライアント端末１０１ごとに記憶する送信済端末情報３２９をも格納する。両者（３２８、３２９）を合わせて、便宜上音声情報と呼ぶことにする。キューに積んだ直後の初期状態では、他のいずれのクライアント端末１０１にも送信していない。なお、この送信済であるか否かの情報は、他のすべてのクライアント端末１０１の配列を用意したフラグであってもよいし、あるいは送信済端末の一覧、あるいは送信済でない端末の一覧など、いずれのデータ構成であってもよい。

（３）次に、各キューの音声データ（キューの先頭の音声情報に含まれる音声データ）を取り出しミキシングする。前述の通り、音声データを送信しようとするクライアント端末１０１に対応するキューを除き、その他のキューの音声データをミキシングする。
（４）ミキシングした音声データをクライアント端末１０１に送信する。

図６は、本発明の実施の形態に係る会議サーバにおける、クライアント端末からの受信状態に基づく遅延状態の発生と回復処理を示すイメージの一例を示す図である。図６では、まず「１）上り音声データ取得（クライアント端末１０１から会議サーバ１０２に送信された音声データ取得）が原因で、遅延が発生する状況」を説明する。

（１）まず、クライアント端末１０１Ａからは、遅延することなく音声データを受信しているとする。一方、クライアント端末１０１Ｂからは、ネットワークの問題などで、７つの音声データ（Ｂ１〜Ｂ７）を受信する。

（２）従って、クライアント端末１０１Ａに対応するキューは、１つの音声情報が格納されるが、クライアント端末１０１Ｂでは、７つの音声情報が対応するキューに格納する。

（３）クライアント端末１０１Ｃに送信するためのミキシングは、クライアント端末１０１Ａ用、Ｂ用のキューから取り出した音声データを用いる。クライアント端末１０１Ａ用のキューからは、音声データ「Ａ７」（「Ｂ７」と同じ時間の音声）が取得され用いられるが、クライアント端末１０１Ｂ用のキューからは、音声データ「Ｂ１」（「Ｂ７」より６単位時間前の音声）が遅延データとして残っている。従って、それぞれ時間のずれた「Ａ７＋Ｂ１」というミキシング音声データが生成される。

前述のクライアント端末１０１における再生の場合と同様に、ミキシングのためキューから削除されていく音声情報と、受信してキューに格納する音声情報は原則として同一の個数であるため、遅延の速度は一定になる（自然に遅延が回復することはない、ということ）。従って、何らかの理由により、クライアント端末１０１Ｂから受信する音声データのみに対して遅延が発生すると、その遅延した音声データの総数は、次第に蓄積されていく。

（４）最終的にクライアント端末１０１に送信された（ミキシングされた）音声データは、ユーザからみて問題と判断されるレベルに達する。即ち、ミキシングされた音声データを受信したクライアント端末１０１以外のクライアント端末１０１の音声データがミキシングされているわけだが、時間的なずれがあり、会話が成り立たない可能性もある。

次に、前述の遅延に対する「２）遅延回復方法」を説明する。例として１）のようにクライアント端末１０１Ｂから受信したキューにおいて、所定の数の範囲を超える音声情報が蓄積されたとする（上り遅延閾値に基づいて判定）。所定の数の範囲を超える音声情報が蓄積されたと判定されると遅延回復処理が開始される。「２）」の図の左側にあるキューには、Ｂ１〜Ｂ７のうち、無音データに対応する音声情報（「（）」が付与されたもの）が４つあるため、これを削除する。無音データかどうかの判定は、クライアント端末１０１で行い、送信する音声データに付加される。会議サーバ１０２においては、実際の音声データ内部を解析するのではなく、クライアント端末１０１から送信された音声データの付加情報により、無音データであるか否かを判定する。ただし、無音データかどうかの判定は会議サーバ１０２で行ってもよい。なお、会議サーバにおいては、音声データの下り処理（クライアント端末１０１への音声データ送信）においても、音声データが無音であるか否かを判定する場合があるが、同様とする。残りは右側のキューの通り、３つ（Ｂ１、Ｂ３、Ｂ７）の音声情報が格納されることになる。これらが、すべてのキュー（クライアント端末１０１ごとに用意されている）ごとに、実行される。なお、遅延回復処理は、他の処理に割り込まれることなく一気に処理を行う。

図７は、本発明の実施の形態に係る会議サーバにおける、クライアント端末への送信状態に基づく遅延状態の発生と回復処理を示すイメージの一例を示す図である。図７では、まず「３）下り音声データ取得（会議サーバ１０２からクライアント端末１０１へのミキシング音声データ送信）が原因で、遅延が発生する状況」を説明する。
（１）会議サーバ１０２は、クライアント端末１０１Ａ、Ｂの双方から音声データを受信する。

（２）各々の対応するキューに、音声情報（音声データと送信済端末情報を関連付けた情報）を格納する。図７の３）では、それぞれ７つの音声情報が格納されている。

（３）クライアント端末１０１ごとの各キューから、音声データを取り出す。各クライアント端末１０１に送るための音声データをミキシングするため、クライアント端末１０１ごとに、自分自身を除く他のクライアント端末１０１のすべての音声データを取り出す。

（４）次にミキシングした音声データを、クライアント端末１０１Ｃに送信する。その際に、ネットワークの状態などにより、遅延が発生することがある。一方、クライアント端末１０１Ｂへ送信する音声(クライアント端末１０１Ａとクライアント端末１０１Ｃの音声データをミキシングした音声データ)は遅延なく送信できたとする。その場合、クライアント端末１０１Ｂには送信済みだが、クライアント端末１０１Ｃには未送信のクライアント端末１０１Ａの音声がキューに存在することになる。音声情報の送信済端末情報３２９に、未送信クライアント端末１０１が１つでもあれば、キューに格納された音声情報を削除することは出来ない。削除されなくとも、クライアント端末１０１Ｂでは、ミキシング／送信で無視されるデータとなるが、クライアント端末１０１Ｃでは無視できないため、クライアント端末１０１Ａで再生される音声と、クライアント端末１０１Ｃで再生される音声との時間間隔が累積されてきて、徐々に会話の時間的な前後関係が不自然になることも想定される。
次に、図１１をもちいて前述の遅延に対する「４）遅延回復方法」を説明する。

図１１は、図７において遅延が発生した場合の遅延回復方法をキューのイメージを用いて説明する図の一例である。

例としてクライアント端末１０１Ｃに送信する音声で遅延が発生している場合(下り遅延フラグにて判断)、クライアント端末１０１Ａおよびクライアント端末１０１Ｂの音声をキューから取出しミキシングする際に、無音データをスキップし、無音ではない音声データをミキシングすることで、遅延を回復する。なお、スキップした無音データに未送信端末が存在しない場合はキューから削除される。「４）」の図のキューには、Ｂ１〜Ｂ７のうち、無音データに対応する音声情報（「（）」が付与されたもの）が４つあるため、これをスキップする。これらが、すべてのキュー（クライアント端末１０１ごとに用意されている）ごとに、実行される。なお、遅延回復処理は、他の処理に割り込まれることなく一気に処理を行う。

図８〜図１０のフローチャートは、クライアント端末１０１、または会議サーバ１０２における遅延に対して、遅延回復の処理を説明するものである。

図８は、本発明の実施の形態に係るクライアント端末における、再生遅延回復処理のフローチャートの一例である。図８のフローチャートの各ステップ（Ｓ８０１〜Ｓ８１３）はクライアント端末１０１のＣＰＵ２０１により、また、Ｓ８１４〜Ｓ８１５は会議サーバ１０２のＣＰＵ２０１により実行される。図８のフローチャートは、図４のキューのイメージに対応する。
Ｓ８０１においては、会議サーバから送信されたミキシング済音声データを受け付ける。

Ｓ８０２においては、クライアント端末１０１の受信音声記憶部３１６のキューに、前記受信したミキシング済音声データを格納する（エンキュー）。
Ｓ８０３においては、前記キューに格納された音声データの数をカウントする。

Ｓ８０４においては、キューに所定の数の範囲を超える音声データが蓄積されているか判定する（再生遅延閾値に基づいて判定）。

Ｓ８０５においては、所定の数の範囲外音声データが蓄積されたか否かの判定に基づき分岐する。所定の数が範囲内である場合は、ＮＯに進み、Ｓ８１０に進む。所定の数が範囲外である場合には、ＹＥＳに進み＜無音破棄＞のルーチンを実行するためＳ８０６に進む。

このＳ８０６〜Ｓ８０９の処理は、他の処理に割り込まれることなく一気に処理を行う。ここで、クライアント端末１０１のキューの全ての音声データについてすべてのチェックを行う。
Ｓ８０６においては、キューの先頭の１つの音声データをデキューする（取り出す）。
Ｓ８０７においては、取り出した音声データが、無音データであるか否かをチェックする。

Ｓ８０８においては、チェックした音声データが無音であると判定された場合には、そのまま（音声データをキューに戻すことなく）次の音声データをチェックすべくＳ８０６に戻る。即ち、無音であると判定された音声データは破棄される。また、チェックした音声データが無音ではないと判定された場合には、Ｓ８０９において、（Ｓ８０６でキューから取り出した）音声データを、再度キューにエンキューする（格納する）。

前述の通り、キューはＦＩＦＯであり、また、Ｓ８０６〜Ｓ８０９の処理は、他の処理に割り込まれることなく、全ての音声データに対して一度ずつ処理を行うため、無音データは全て削除され、図４の３）に記載された左のキューから右のキューのように変わった後でも、残った音声データの時間的順序性は確保される。

以上で、受信音声記憶部３１６におけるミキシング音声データを受信したクライアント端末１０１のキューにおいて遅延が発生した場合には、その遅延回復処理を行った。

次にＳ８１０において、再度、キューに所定の数の範囲を超える音声データが蓄積されているかカウントする。

Ｓ８１１においては、所定の数の範囲を超える音声データが蓄積されているか判定する（再生遅延閾値と同じ値でもよいし、異なる値でもよい）。すなわち、遅延回復処理を完了した結果として十分な効果が得られたか否かを判断する。

Ｓ８１２においては、所定の数の範囲を超える音声データが蓄積されている場合（ＹＥＳの場合）には、Ｓ８１３に進む。そうでない場合（ＮＯの場合）には、Ｓ８０１（音声の受信）に戻る。なお、音声の再生は、非同期処理にて実行されおり、遅延回復処理とは無関係であるため、フローチャートとしては図示していない。

Ｓ８１３においては、会議サーバ１０２に、遅延回復処理の通知を行う。即ち、無音データを削除すると言う方式では、クライアント端末１０１においては、これ以上の対応は出来ない。従って、その場合は、会議サーバ側にも、遅延回復のための支援を要請することになる。また、会議サーバ１０２に、遅延回復処理の通知を行った後、Ｓ８０１に戻る。一方、会議サーバ１０２のＳ８１４においては、クライアント端末１０１のＳ８１３からの通知を受け取る。

Ｓ８１５においては、「下り遅延フラグ」をオンにして、クライアント端末１０１から回復支援処理の支援要請があることを示す。これにより、会議サーバ１０２で動作している「下り音声遅延回復」の処理が起動されるようにしても良い。ただし、「下り音声遅延回復」は、クライアント端末１０１からの要請の有無にかかわらず、独自のルーチンにおける判断で起動されても良い。
以上で、クライアント端末１０１における遅延回復処理に関するフローチャートの説明を完了する。

図９は、本発明の実施の形態に係る会議サーバにおける、クライアント端末からの受信状態に基づく遅延回復処理のフローチャートの一例である。図９のフローチャートの各ステップは会議サーバ１０２のＣＰＵ２０１により実行される。下記の処理は、会議サーバ１０２において、クライアント端末１０１ごとに用意された個々のキューごとに処理される。また、図９のフローチャートで説明する処理は、クライアント端末１０１から会議サーバ１０２が受信する音声データなので、上り音声データに関する音声遅延回復処理の説明である。図９のフローチャートは、図５および図６のイメージに対応する。

Ｓ９０１においては、クライアント端末１０１から音声データ（正確には音声データを含む通信用のパケット）を受信する。ここで、フローチャートを１つだけ記載しているが、具体的には、１つの受信部で受け付けて、そのデータから複数あるクライアント端末１０１のいずれから送信されたデータであるかを判別しても良いし、そもそも、会議サーバ１０２とクライアント端末１０１の接続が確立されると“クライアント端末１０１ごと”に受信部がマルチスレッドで生成されて、特定のクライアント端末１０１の受信部としてもよい。ただし、Ｓ９０２以降では、受信部でクライアント端末１０１が識別されているものとして、識別された１つのクライアント端末１０１に対応する処理とする。

Ｓ９０２においては、Ｓ９０１で受信した音声データをミキシング用音声記憶部３２６の識別された１つのクライアント端末１０１に対応するキューに、既に音声情報（前述のパケット内の音声データと、前述の送信済端末情報３２９）が幾つ格納されているかをチェックする。

Ｓ９０３においては、前記音声情報の数が、サーバ閾値記憶部３２７の上り遅延閾値に従って所定数を上回っているか否かを判断する。

Ｓ９０４においては、キューにおける音声情報の数が、上り遅延閾値に従って所定数を上回っている、と判定された場合（ＹＥＳの場合）には、Ｓ９０５に進む。上回っていない、と判定された場合（ＮＯの場合）には、Ｓ９０９に進む。

Ｓ９０９においては、キューに格納された音声情報の数が、上り遅延閾値に従って所定数を上回っていない、即ち、まだ（遅延回復処理をすることなく）音声情報を格納できると判断されるため、キューに格納（エンキュー）して、次の音声受信のためＳ９０１に戻る。

Ｓ９０５に進んだ場合には、Ｓ９０５からＳ９０８の処理を、キューに格納されている全ての音声情報に対して繰り返す。その間、Ｓ９０５からＳ９０８のループは抜けない。

上り遅延閾値に従って所定数を上回っている、と判定された場合には、Ｓ９０５において、キューから１つの音声情報を抽出（デキュー。キューから取り出すこと）する。

Ｓ９０６においては、Ｓ９０５において抽出した音声情報に含まれる音声データが、“無音データ”であるか否かを判定する。 Ｓ９０７においては、Ｓ９０５において抽出した音声情報に含まれる音声データが“無音データ”である場合（ＹＥＳの場合）、Ｓ９０５に戻る。すなわち、デキューした音声情報は無音データであるので、キューに戻さない（削除する）。

Ｓ９０８においては、デキューした音声情報は無音データではないので、エンキューする（キューの最後に戻す）。

これらのＳ９０５からＳ９０８の処理により、キューの中の無音データの数分だけ音声情報が削減されることにより、音声遅延を削減するという効果を得ることができる。以上で、図９のフローチャートの説明を完了する。

図１０は、本発明の実施の形態に係るクライアント端末への送信状態に基づく遅延回復処理のフローチャートの一例である。図１０のフローチャートの各ステップは会議サーバ１０２のＣＰＵ２０１により実行される。図１０のフローチャートは、会議サーバ１０２のミキシング用音声記憶部３２６における複数のクライアント端末１０１のキューにおける音声情報（に含まれる音声データ）をミキシングして、クライアント端末１０１に送信する処理である。会議サーバ１０２からクライアント端末１０１に送信するため、上り音声データである。図７のキューのイメージに対応する。

あるクライアント端末１０１に送信するミキシング音声データに、その端末自身の音声データはミキシングされていない。従って図１０のフローチャートで処理するミキシング用音声記憶部３２６のキューは、送信しようとするクライアント端末１０１以外のキューに対応するキュー１つずつに対して処理される。
Ｓ１００１においては、キューから１つの音声情報を抽出する（デキュー）。
Ｓ１００２においては、図８のＳ８１５で“オン”にされる下り遅延フラグをチェックする。

Ｓ１００３においては、下り遅延フラグが“オン”である場合（ＹＥＳの場合）には、Ｓ１００４に進む。すなわち、クライアント端末１０１側から、会議サーバ１０２側での遅延回復処理が要求されているためである。また、“オフ”である場合（ＮＯ）の場合には、Ｓ１００７に進む。

なお、Ｓ１００２において、下り遅延フラグをチェックするのではなく、上り時のチェック（サーバ閾値記憶部３２７における上り遅延閾値）と同様に、閾値を用いても良い。この閾値を、下り遅延閾値とし、キューにおける音声情報の数が、下り音声閾値に基づいて所定の数に達したらＳ１００３においてＳ１００４（ＹＥＳの方向）、達していない場合にはＳ１００７に進むようにしても良い。

Ｓ１００４においては、Ｓ１００１においてデキューした音声情報に含まれる音声データが、無音データであるか否かをチェックする。

Ｓ１００５においては、Ｓ１００４においてチェックした音声データが“無音データ”である場合（ＹＥＳの場合）には、Ｓ１００６に進み、次の音声情報をキューから取り出して、Ｓ１００４に戻り処理を繰り返す。この繰り返しにより、“無音データ”を無視した処理が進んでいく。

一方、Ｓ１００４においてチェックした音声データが“無音データ”ではない場合（ＮＯの場合）には、Ｓ１００７に進み、前述の通りミキシング音声として、Ｓ１００８によりクライアント端末１０１に送信する。Ｓ１００７においては、ミキシングに使用した音声データは、不要なデータとしてキューに戻していない。しかし、実際には、他のクライアント端末１０１で使用する必要があるかも知れないため、“全てのクライアント端末（この音声データを送信してきたクライアント端末を除く）で、この音声データを送信済みではない”場合には、改めてエンキューする必要がある。 以上で、図１０のフローチャートの説明を完了する。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明におけるプログラムは、図８〜図１０のフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図８〜図１０のフローチャートの処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは図８〜図１０のフローチャートの各装置の処理方法ごとのプログラムであってもよい。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。

コンピュータプログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１ クライアント端末
１０２ 会議サーバ
１０３ ネットワーク
３１１ 音声入力部
３１２ 音声送信部
３１３ ミキシング音声受信部
３１４ 受信音声チェック部
３１５ 音声再生部
３１６ 受信音声記憶部
３１７ 端末閾値記憶部
３２１ 音声受信部
３２２ 上りチェック部
３２３ ミキシング音声送信部
３２４ 下りチェック部
３２５ ミキシング部
３２６ ミキシング用音声記憶部
３２７ サーバ閾値記憶部
３２８ 音声データ
３２９ 送信済端末情報

Claims (10)

1. 取得した音声データの送信と他の端末の音声データの再生が可能な複数の端末と通信可能であり、複数の端末から受信した複数の音声データを記憶する記憶手段を備える情報処理装置であって、
   前記記憶手段に記憶された、前記端末の音声データを用いて、各端末に送信する合成音声データを生成する生成手段と、
   前記生成手段により生成された合成音声データを、送信対象の端末に送信すべく出力する出力手段と、
   所定の条件を満たす音声データを、前記生成手段により生成される前の、前記記憶手段に記憶された音声データの中から特定する特定手段と、
   を備え、
   前記生成手段は、前記端末に対応する前記出力手段で出力された合成音声データが所定量蓄積されている場合に、前記特定手段により特定された音声データをスキップして所定量蓄積があるとされた前記端末に送信する合成音声データを生成することを特徴とする情報処理装置。
2. 前記生成手段は、前記端末に出力する前記合成音声データが所定量蓄積されている場合に前記特定手段により特定された音声データをスキップし、特定手段により特定されなかった音声データを用いて合成音声データを生成することを特徴とする請求項１に記載の情報処理装置。
3. 前記生成手段は、前記端末から前記合成音声データの送信による遅延がある旨の通知を受け付けた場合に、前記特定手段により特定された音声データをスキップして、前記端末に送信する合成音声データを生成することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記所定の条件を満たす音声データとは、音声が含まれていないとみなされる無音データであることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記音声が含まれていないとみなされる無音データとは、無音であることを示す付加情報が付加された音声データであることを特徴とする請求項４に記載の情報処理装置。
6. 取得した音声データの送信と他の端末の音声データの再生が可能な複数の端末と通信可能であり、複数の端末から受信した複数の音声データを記憶する記憶手段を備える情報処理装置の制御方法であって、
   前記記憶手段に記憶された、前記端末の音声データを用いて、各端末に送信する合成音声データを生成する生成工程と、
   前記生成工程により生成された合成音声データを、送信対象の端末に送信すべく出力する出力工程と、
   所定の条件を満たす音声データを、前記生成工程により生成される前の、前記記憶手段に記憶された音声データの中から特定する特定工程と、
   を含む、、
   前記生成工程は、前記端末に対応する前記出力工程で出力された合成音声データが所定量蓄積されている場合に、前記特定工程により特定された音声データをスキップして所定量蓄積があるとされた前記端末に送信する合成音声データを生成することを特徴とする制御方法。
7. 取得した音声データの送信と他の端末の音声データの再生が可能な複数の端末と通信可能であり、複数の端末から受信した複数の音声データを記憶する記憶手段を備える情報処理装置を、
   前記記憶手段に記憶された、前記端末の音声データを用いて、各端末に送信する合成音声データを生成する生成手段と、
   前記生成手段により生成された合成音声データを、送信対象の端末に送信すべく出力する出力手段と、
   所定の条件を満たす音声データを、前記生成手段により生成される前の、前記記憶手段に記憶された音声データの中から特定する特定手段として機能させ、
   前記生成手段を、前記端末に対応する前記出力手段で出力された合成音声データが所定量蓄積されている場合に、前記特定手段により特定された音声データをスキップして所定量蓄積があるとされた前記端末に送信する合成音声データを生成する手段として機能させるためのプログラム。
8. 取得した音声データの送信と他の端末の音声データの再生が可能な複数の端末と通信可能であり、複数の端末から受信した複数の音声データを記憶する記憶手段を備える情報処理装置と、を含む情報処理システムであって、
   前記記憶手段に記憶された、前記端末の音声データを用いて、各端末に送信する合成音声データを生成する生成手段と、
   前記生成手段により生成された合成音声データを、送信対象の端末に送信すべく出力する出力手段と、
   所定の条件を満たす音声データを、前記生成手段により生成される前の、前記記憶手段に記憶された音声データの中から特定する特定手段と、
   を備え、
   前記生成手段は、前記端末に対応する前記出力手段で出力された合成音声データが所定量蓄積されている場合に、前記特定手段により特定された音声データをスキップして所定量蓄積があるとされた前記端末に送信する合成音声データを生成することを特徴とする情報処理システム。
9. 取得した音声データの送信と他の端末の音声データの再生が可能な複数の端末と通信可能であり、複数の端末から受信した複数の音声データを記憶する記憶手段を備える情報処理装置と、を含む情報処理システムの制御方法であって、
   前記記憶手段に記憶された、前記端末の音声データを用いて、各端末に送信する合成音声データを生成する生成工程と、
   前記生成工程により生成された合成音声データを、送信対象の端末に送信すべく出力する出力工程と、
   所定の条件を満たす音声データを、前記生成工程により生成される前の、前記記憶手段に記憶された音声データの中から特定する特定工程と、
   を備え、、
   前記生成工程は、前記端末に対応する前記出力工程で出力された合成音声データが所定量蓄積されている場合に、前記特定工程により特定された音声データをスキップして所定量蓄積があるとされた前記端末に送信する合成音声データを生成することを特徴とする制御方法。
10. 取得した音声データの送信と他の端末の音声データの再生が可能な複数の端末と通信可能であり、複数の端末から受信した複数の音声データを記憶する記憶手段を備える情報処理装置と、を含む情報処理システムを、
    前記記憶手段に記憶された、前記端末の音声データを用いて、各端末に送信する合成音声データを生成する生成手段と、
    前記生成手段により生成された合成音声データを、送信対象の端末に送信すべく出力する出力手段と、
    所定の条件を満たす音声データを、前記生成手段により生成される前の、前記記憶手段に記憶された音声データの中から特定する特定手段として機能させ、
    前記生成手段を、前記端末に対応する前記出力手段で出力された合成音声データが所定量蓄積されている場合に、前記特定手段により特定された音声データをスキップして所定量蓄積があるとされた前記端末に送信する合成音声データを生成する手段として機能させるためのプログラム。

Images