(57)【要約】【課題】  多者間通話サービスにおける効率的かつ計算量の少ない音声ミキシング方法及び音声ミキシングシステムを提供する。【解決手段】  同時刻に発生された複数参加者の音声データのパケットをサンプルごとに比較し、比較したサンプルの中から振幅の絶対値が最大のサンプルを抽出する。この抽出したサンプルを出力として取り出し、他のサンプルを破棄することで、同時に発生した音声の中では振幅絶対値が最大となる音声のみを送信する。これにより、多者間通話システムにおける計算量を著しく低減させることができる。【選択図】        図６
2005151044.tif 000002
【特許請求の範囲】
【請求項１】
デジタルサンプリングされた複数の音声データのミキシング方法であって、前記複数の音声データを所定時間毎のサンプルに分割して、該サンプルの振幅の絶対値を比較するステップと、前記比較した複数の音声データのサンプルの中から前記振幅の絶対値が最大となる音声データのサンプルを選択するステップと、前記選択された絶対値最大の音声データのサンプルを出力し、選択されなかった音声データのサンプルを破棄するステップとからなることを特徴とする音声ミキシング方法。
【請求項２】
前記各サンプルの振幅の絶対値の比較及び選択処理は、連続する複数サンプルの最初のサンプルについて一回だけ行い、前記最初のサンプルの大小判定の比較結果に基づいて、前記最初のサンプルに続く１または複数サンプルについては比較することなく選択処理することを特徴とする請求項１に記載の音声ミキシング方法。
【請求項３】
デジタルサンプリングされた複数の音声データのミキシングシステムであって、前記複数の音声データを所定時間毎のサンプルに分割して、該サンプルの振幅の絶対値を比較する比較手段と、前記比較した複数の音声データのサンプルの中から前記振幅の絶対値が最大となる音声データのサンプルを選択する選択手段と、前記選択された絶対値最大の音声データのサンプルを出力し、選択されなかった音声データのサンプルを破棄する出力手段とからなることを特徴とする音声ミキシングシステム。
【請求項４】
前記各サンプルの振幅の絶対値の比較手段及び選択手段は、連続する複数サンプルの最初のサンプルについて１回だけ比較処理を行い、前記最初のサンプルの大小判定の比較結果に基づいて、前記最初のサンプルに続く１または複数サンプルを比較することなく選択処理することを特徴とする請求項３に記載の音声ミキシングシステム。
【請求項５】
デジタルサンプリングされた複数の音声データのミキシングシステムを実現するプログラムであって、前記複数の音声データを所定時間毎のサンプルに分割して、該サンプルの振幅の絶対値を比較する機能と、前記比較した複数の音声データのサンプルの中から前記振幅の絶対値が最大となる音声データのサンプルを選択する機能と、前記選択された絶対値最大の音声データのサンプルを出力し、選択されなかった音声データを破棄する機能を実現するための音声ミキシング処理のためのプログラム。
【請求項６】
前記各サンプルの振幅の絶対値の比較及び選択機能を実現するプログラムは、連続する複数サンプルの最初のサンプルについて１回だけ比較処理を行い、前記最初のサンプルの大小判定の比較結果に基づいて、前記最初のサンプルに続く１または複数サンプルを比較することなく選択処理する機能を実現するものであることを特徴とする請求項５に記載の音声ミキシング処理のためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット交換網を用いて多人数で音声通話を行う場合の複数音声のミキシング方法に関し、特に、揺らぎと遅延を緩和した高速の音声ミキシング方法及びそれを利用した音声ミキシングシステム、並びにそのためのプログラムに関する。
【背景技術】
【０００２】
大容量回線の低価格化や通信業界の規制緩和などにより、安価に電話を行うことのできるIP 電話方式サービスの利用者は増加傾向にある。従来の電話は回線交換網を利用しているため、1対1通話が基本の音声通信であり、大手通信会社の提供するサービスとしての位置付けであった。
【０００３】
IP 電話方式はIP（Internet Protocol）を利用したパケット交換網を利用して電話通信を行うサービスである。このIP 電話方式では、音声データはWeb等のデータと同列に扱うことが可能である。このことは、従来の電話では実現が難しかった応用サービスの提供を容易にする可能性を有している。さらに、インターネットを利用するIP 電話方式では、一般利用者が容易に応用サービスを提供することも可能になる。
【０００４】
しかし、利用する回線の特性が異なるため、従来の電話では起こらない次のような問題が発生する。すなわち、IP 電話方式では回線交換網と違い、通信経路を占有することが無いため、データの伝送経路上のトラフィック状況によって遅延が生じ、特に到着時間に一貫性が無い「揺らぎ」が生じる。電話はリアルタイム性が重要になるため、揺らぎを吸収する制御は重要である。この揺らぎや遅延を吸収する制御用のプロトコルとしては、一般にRTP(Real-time Transport Protocol)が使用される。
【０００５】
また、IP 電話方式では、送話者から受話者へデータが到着するまでに、送話者側では音声サンプリング、エンコード、パケット化に伴った遅延時間が生じ、送話者から受話者までの伝送経路中では、伝送距離に応じた伝播遅延、経路にあるルータにおけるパケットのキューイング遅延等が生じ、受話者側ではパケットの処理、揺らぎの吸収、受信データのチェック、音声のデコード時間が生じる。したがって、高いQoS(Quality of Service)を有するには、遅延時間は短くする必要があり、合計の遅延時間は150ms以内にする必要がある。
【０００６】
IPのようなパケット交換網を伝送路として用いるIP電話では、従来の回線交換網による電話と異なり、回線の特性上様々な応用サービスを容易に提供することが可能である。従来の電話では、回線はキャリアにより綿密に管理されたものであるため、新規にサービスを提供するにはキャリアのサービスという位置付けで行う必要があった。しかし、パケット交換網は分散管理された網であるため、容易に様々なサービスを提供することが可能であり、かつソフトウェアベースで提供することが可能である。
【０００７】
IP 電話方式で重要な技術の一つとして、パケット化されたデジタル音声をミキシングする技術がある。従来のデジタル音声ミキシングは、集音装置から入力されたアナログ音声を標本化、量子化することによりデジタル化された音声データに対して行っていた。デジタル化された音声は、シャノンの標本化定理によりアナログ音声として再構成できるため、音波として扱うことができる。したがって、音波を重ね合わせることでミキシングが達成される。
【０００８】
従来の音声ミキシング方法及びシステムとしては、図１０に示すようなものが提案されている（非特許文献１）。図１０に示す音声ミキシング方法は、多者間通話システムに参加する３人の参加者Ａ、Ｂ、Ｃの音声を符号化し、ミキシング（混合）を行い、ミキシングした音声から自分（送信者）の音声を減算して復号化し、自分以外の他の二人に音声を送信する方法である。すなわち、参加者Ａの音声は符号化器Ｄ１で符号化され、タイムスタンプが押されたリニアストリームとしてバッファに記憶される。その後、ミキシングされてＸ＝Ａ＋Ｂ＋Ｃの混合リニアストリームが作成される。そして、この混合リニアストリームから、送信者自身の音声データを減算した音声データ（例えば、送信者がＡであれば、Ｘ−Ａ＝Ｂ＋Ｃ）が、復号化器Ｅ１で復号化されて、Ａに送信される。送り先がＢあるいはＣの場合も同様な操作で他の二者の音声データが送信される。ここで、各送信者からの音声データは、通常20ms単位で送られてくるので、このデータを二つまとめて40msの音声データとして送信される。
【非特許文献１】Internet Telephony Workshop 2001「Centralized Conferencing using SIP」（２００１年４月２日発行）
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、この従来のデジタル音声データのミキシングまでのプロセスでは、ミキシングなどに必要となる処理遅延を考慮はしているものの、全てをミキシングしてから自身のデータを減算する等の無駄があり、また送信する音声データを40msにすることで音声品質に影響を及ぼす危険性がある。
また、従来のデジタル音声ミキシングでは、波形を重ね合わせることにより、全てのサンプルに対して計算を行わなければならないため、計算量が大きいという問題があった。
本発明は、このような従来の手法が有している問題を解決しようとするものであり、ミキシング結果のクオリティを可能な限り落とさずに、高速な音声ミキシングを実現することを目的とするものである。
【課題を解決するための手段】
【００１０】
上記課題を解決し、本発明の目的を達成するため、請求項１に記載された音声データのミキシング方法の発明は、複数の参加者からのデジタルサンプリングされた音声データを所定時間毎のサンプルに分割して、該サンプルの振幅の絶対値を比較するステップと、この比較した複数の音声データのサンプルの中から振幅の絶対値が最大となる音声データのサンプルを選択するステップと、選択された絶対値最大の音声データのサンプルを出力し、選択されなかった音声データのサンプルを破棄するステップとからなることを特徴とする。
また、請求項２に記載された発明は、請求項１に記載された音声データのミキシング方法において、上記各サンプルの振幅の絶対値の比較及び選択処理は、連続する複数サンプルの最初のサンプルについて１回だけ比較処理を行い、この最初のサンプルの大小判定の比較結果に基づいて、最初のサンプルに続く１または複数サンプルについては比較することなく選択処理することを特徴としている。
【００１１】
請求項３に記載された発明は、複数の参加者からのデジタルサンプリングされた音声データのミキシングシステムとして、複数参加者からの複数の音声データを所定時間毎のサンプルに分割して、該サンプルの振幅の絶対値を比較する比較手段と、このサンプル毎に比較した複数の音声データのサンプルの中から振幅の絶対値が最大となるサンプルの音声データのサンプルを選択する選択手段と、選択された絶対値最大の音声データのサンプルを出力し、選択されなかった音声データのサンプルを破棄する出力手段とからなることを特徴とするものである。
請求項４に記載された発明は、請求項３に記載された音声データのミキシングシステムにおいて、上記各サンプルの振幅の絶対値の比較及び選択手段は、連続する複数サンプルの最初のサンプルについて１回だけ比較処理を行い、この最初のサンプルの大小判定の比較結果に基づいて、最初のサンプルに続く１または複数サンプルについては比較することなく選択処理することを特徴としている。
【００１２】
また、請求項５に記載された発明は、複数の参加者からのデジタルサンプリングされた音声データのミキシングシステムを実現するプログラムであって、複数参加者からの複数の音声データを所定時間毎のサンプルに分割して、該サンプルの振幅の絶対値を比較する機能と、このサンプル毎に比較した複数の音声データのサンプルの中から振幅の絶対値が最大となる音声データのサンプルを選択する機能と、この選択された絶対値最大の音声データのサンプルを出力し、選択されなかった音声データのサンプルを破棄する機能を実現するプログラムである。
請求項６に記載された発明においては、請求項５に記載された音声ミキシングシステムの機能を実現するプログラムにおいて、上記各サンプルの振幅の絶対値の比較及び選択機能は、連続する複数サンプルの最初のサンプルについて１回だけ比較処理を行い、この最初のサンプルの大小判定の比較結果に基づいて、最初のサンプルに続く１または複数サンプルについては比較処理を行うことなく選択処理を行うプログラムであることを特徴としている。
【００１３】
本発明の音声ミキシング方法、音声ミキシングシステム及び音声ミキシングシステムの機能を実現するプログラムによれば、音波の重ね合わせによるミキシングを行う必要はなく、任意の時間における振幅の絶対値の最大のデータを選択することができる。
これは、同時に発生された複数の音声データを比較すると、振幅の絶対値の大きなデータが振幅の絶対値の小さいデータをかき消す作用をもつために、最大の振幅のみを抽出することで、話者の音声が十分に他者に聞き取れることに基づくものである。
すなわち、この音声データの選択は、「小さな音は大きな音に掻き消される」という効果に基づいて、小さい振幅の音声を省いても、ミキシング後の音声品質は聴覚的に問題の無いレベルを実現できるのである。
【００１４】
また、本発明の好ましい形態によれば、全てのサンプルについて比較選択処理を行わないで、複数サンプルに1回の大小関係の比較選択処理の結果に基づいて、その選択された音声データのサンプルに続く複数サンプルを選択処理するようにしている。
このことは、所定時間のサンプルと、次のサンプルとの振幅値の差が小さいことに基づき、連続する複数サンプル全てに対して大小関係を判定するよりも、複数サンプル毎に一回の比較及び大小判定を行い、その結果を次の数サンプルの比較結果として適用するでも、全サンプルを比較したのと変わらない結果をうることができるからである。
この手法によれば、比較を行う計算を複数サンプルに一度行うだけでよいため、高速な音声ミキシングが実現される。つまり、一回の比較処理で複数のサンプルをミキシングすることが可能になるため、必要となる計算量を減らすことができ、高速化が実現する。
【発明の効果】
【００１５】
上述したように、本発明の音声ミキシング方法、音声ミキシングシステム、及び音声ミキシングのためのプログラムは、人間の聴覚レベルでは問題ないレベルの音質を保ちつつ、従来手法よりも遥かに計算量を少なくしてミキシングを行うことができる。
【００１６】
更に、本発明の好ましい形態によれば、１つのサンプルの音声データの比較結果を複数サンプル（例えば３つ）先のデータまで適用することができる。すなわち、まず1サンプル目を比較し、大きな方を選択する。そして、次の２、３、４サンプル目は、1サンプル目で選択したデータのサンプルを選択するようにする。次に5サンプル目のデータを比較処理し、この５サンプル目の比較結果を適用して、６、７、８番目のデータのサンプルを選択する。Nサンプル目を比較した場合、N+1・N+2・N+3サンプル目はNサンプル目で選択した音声データ側のサンプルを選択する。これを繰り返すことにより、必要となる計算量が４分の１に低減される。
【００１７】
この方法は、一見荒い制御に見えるが、実際はかなりミクロな時間軸での制御であること、かつ会話では全員が同時に発声することは稀であるので、ほとんど問題にならないで話者の声を識別することが可能である。音楽、男声、女声でミキシングを行った場合、全ての音声を容易に聴覚レベルで認識する事が可能であり、高品質な音声ミキシングを実現できる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の実施の形態の例を図１〜図３に基づいて説明する。
【００１９】
図１は、一般的な多者間の通話システムの概要図を示すものであり、多者間通話サーバ１と複数のユーザ端末（IP電話器）２がネットワーク３に接続されている。
この多者間の通話サービスにおいては、各ユーザが持っているユーザ端末の機能に差があることから、端末が必ず備えている最低限の機能でサービスを提供することが必要となる。すなわち、電話には、対象に対して電話をかける「シグナリング」機能と、シグナリングにより相手と通話できることが確定した後に音声を送信する「全2重音声伝送」機能が必要となる。ここで全2重とは、自身の音声と相手の音声を同時に扱う事を意味している。
【００２０】
ネットワーク3は、IP電話トラフィックのみ伝送する専用網と、インターネットのように電話以外のトラフィックが伝送されている共有回線も含んでおり、シグナリング機能と全2重音声伝送に関するユーザ端末の前提条件から、サーバでは次の流れで処理を行っている。
【００２１】
まず、シグナリング機能面では、サーバ１が、多者間通話を行うグループに対してユニークなIDを割り当て、ユーザＡはそのIDに対して電話をかける。ここで、ユーザＡは、多者間通話サーバ１と1対1セッションを張っているだけであるが、サーバ１は他のユーザＢ、Ｃ、Ｄともセッションを張っているため、見かけ上、ユーザA、B、C、Ｄはサーバ１を介して仮想的にマルチセッションを張っているといえる。
【００２２】
次に、電話に必要な全2重音声伝送機能面であるが、各ユーザから送信された音声を適切にミキシングし、複数の音声ストリームを一つのストリームに圧縮し、送出することが必要とされる。この全2重音声伝送機能を用いて複数の音声ストリームのやり取りが可能になる。
【００２３】
図２は、多者間通話サーバ１の機能ブロックを説明するための概略図である。１１は電話をかける際の制御を司るシグナリングモジュール、１２は音声データを受信する場合の制御を司るデータ受信モジュール、１３は参加者情報管理データベース操作モジュール、１４は参加者情報管理データベース、１５は正当性のあるパケットとして判別されたデータを格納する受信データキューである。
また、１６は受信データキュー１５に保持されている同一グループのキューの時刻同期制御モジュール、１７は時刻同期制御モジュール１６で同期されたパケットをミキシングする音声ミキシングモジュール、１８はミキシング済みのパケットにストリーム制御プロトコルに合わせた形式になるよう処理し、送信するデータ送信モジュールである。
なお、１９はシグナリングパケット、２０はサーバが受信する音声パケット、２１はサーバが送信するミキシング済み音声パケットである。
【００２４】
シグナリングモジュール１１は、ユーザからのシグナリングデータ処理するためのモジュールであって、シグナリングデータを内包するパケット１９を受信し、シグナリングデータの内容から、多者間通話サービスを提供するために必要となる情報を取得するためのものである。そして、シグナリングモジュール１１は、この取得した情報から、多者間通話サーバ1が多者間通話サービスを提供可能であるか否かを判別し応答する。また、シグナリングモジュール１１はすでに開始済みのサービスを停止するためのシグナリングの処理も行っている。
【００２５】
データ受信モジュール１２は、ユーザからの音声パケットを受信するためのモジュールであり、このモジュールにおいて受信したデータの正当性がチェックされる。例えば、IP電話では音声の送受信に関してストリーム制御プロトコル(RTP)を用い、パケットのロスや遅延を検出している。この正当性チェックは、パケットがロスしたり、遅れすぎたパケットを検出したりした場合にその制御や破棄を行うものである。
【００２６】
参加者情報管理データベース操作モジュール１３は、シグナリングモジュール１１で処理された内容を参加者情報管理データベース１４に反映させるためのモジュールであり、シグナリングモジュール１１からの命令で動作し、参加者情報管理データベース１４に対し、参加の場合は新規にエントリを追加し、脱退の場合は参加者情報管理データベース１４に存在するエントリを探して削除する。参加者情報管理データベース１４には、参加者のネットワーク的な位置情報(IPアドレス等)や、参加しているグループのID、送信状況等が格納されている。
【００２７】
データ受信モジュール１２において正当性のあるパケットとして判別されたデータを格納する受信データキュー１５は、新しいパケットをキュー１５の最後尾に格納し、キュー１５から取り出す場合は先頭から取り出していく。一人のユーザにつき独立した1つのキューを割り当てており、この点で受信データキュー１５は複数のキューの集合体であるといえる。
【００２８】
時刻同期制御モジュール１６は、受信データキュー１５に保持されている、同一グループのキューの時刻同期制御を行うものであり、この時刻同期制御モジュール１６における同期制御は、パケット交換網で発生する、データの到着時間に一貫性の無い「揺らぎ」という現象を回避するために必要とされる。この同期制御が行われないと、揺らぎの影響により、参加者全員の音声は同時に到着することが無く、データの到着順が異なってしまう。このため、ミキシング対象のデータが実時間的に同時に送出された音声であるかを判別し、時間を合わせる時刻同期が必要となる。同期を行わないで各送話者からの音声データの到着時刻がずれると、ミキシングを行うべきでないもの同士をミキシングすることになり、その結果がノイズとなって音声品質が悪くなる。また、同時に発生された音声パケットのうちの一方の到着が遅れた場合は、その一方の音声データの処理が、先に到着した他方の音声パケットの次に処理すべき他方のデータと一緒に処理されるため、処理後のミキシング音声に間延びが現れることになり、音声品質に悪影響を及ぼすことになる。
時刻同期後の音声パケットの音声ミキシングモジュール１７については、後述されるように、図６〜図９に示すシステム構成図、波形図、フローチャートを用いて詳細に説明される。
【００２９】
データ送信モジュール１８は、ミキシング済みのパケットをストリーム制御プロトコルに合わせた形式になるよう処理し、送信するモジュールであり、ここでの送信状況は参加者情報管理データベース１４で一括管理しているため、参加者情報管理データベース１４から送信状況に関する情報を取得し、その情報を元にパケットを整形し、整形されたパケット２１がユーザに送信される。
【００３０】
図３は、図２の２０、２１で送受信されるＲＴＰをストリーム制御プロトコルとする音声パケットのフォーマットを示したものである。３１は、ＲＴＰで定義された音声ストリームの何番目のパケットであるかを示すシーケンス番号であり、パケットが一つ送信されるたびに１ずつ増加する。そのため、最後に受信した音声パケットのシーケンス番号との差が１にならない場合は、パケットロスが発生したと判断される。
【００３１】
３２はＲＴＰで定義されているタイムスタンプである。タイムスタンプ３２は時間情報ではなく、送信されたデータのデータサイズで表現されている。このタイムスタンプ３２は主として再生タイミングの制御に用いられる。３３は、ＲＴＰで定義されているストリームの識別子であり、同一ストリームではこの識別子は常に同じになる。３４は、ユーザ端末で音声をデジタル化したペイロード（音声データ）である。
【００３２】
図４は、参加者情報管理データベース１４における時刻同期に関係するデータ構造を示すものである。
４１には、多者間通話の１グループの通話に、任意の時間に参加している参加者数が保持される。４２には、参加者情報を保持する配列のアドレスが格納される。この参加者情報を保持する配列のアドレス４２の内部構造は、参加者情報保持テーブル４３に示されている。このように、参加者情報保持テーブル４３には、ＩＤキーとそれに対応する指定されたアドレスとが保持されている。このＩＤ番号と対応する情報のアドレスの詳細はユーザ固有の情報テーブル４４に示されている。
すなわち、テーブル４４には、ユーザのＩＤ番号４５に対応して、ユーザ固有の受信データキューの先頭アドレス４６と、ユーザ固有の受信データキューの最後尾アドレス４７と、最初に受信した音声パケットの受信時刻（Ｔ０）４８と、最初に受信した音声パケットのタイムスタンプ（ＴＳ０）４９とが格納されている。
【００３３】
同時刻処理は、ユーザ固有の受信データキューの先頭アドレス４６で指定されているユーザに対して行われる。また、ユーザ固有の受信データキューの最後尾アドレス４７には、図２で説明したメディアデータを処理するブロックであるデータ受信モジュール１２で処理された音声パケットのアドレスが格納される。また、最初に受信した音声パケットの受信時刻（Ｔ０）４８は、多者間通話サーバ１におけるコンピュータ内部時計の時間を格納するものであり、この時間をミリ秒以下の制度で保持している。最初に受信した音声パケットのタイムスタンプ（ＴＳ０）４９は、最初に受信した音声パケットの受信時刻（Ｔ０）４８とともに、時刻同時処理に用いられる。
【００３４】
次に、図５に基づいて、音声パケットの受信からミキシングして送信するまでの音声パケットの流れにそって、本発明の全体像を説明する。ここでは多者間通話に参加する3人のユーザＡ、Ｂ、Ｃからの音声データのミキシング処理について説明する。
図５に示すように、音声パケットの受信から音声パケットの送信までの全体システムは、複数参加者Ａ、Ｂ、Ｃからの音声パケットデータを受信して、時刻の刻印を行うタイムスタンパ５２と、揺らぎの吸収処理を行うバッファ５３と、時刻同期処理部５４と、データミキシング処理部５５と、データ送出処理部５６と、これら全体の時間のタイミングを制御する計算機内部時計５７とから構成される。計算機内部時計５７は、タイムスタンパ５２と、時刻同期処理部５４において主として利用される。カウンタ５８は固定周期、すなわち、音声パケットの１つの時間、例えば20msをカウントしてリセットするカウンタである。
【００３５】
次に、図５の全体システムの動作を説明する。ユーザＡ、Ｂ、Ｃからの音声パケット５１ａ、５１ｂ、５１ｃは、タイムスタンパ部５２に供給される。ここで、ユーザＡ、Ｂ、Ｃから送られてくる音声パケットには、その発生時には同時刻であっても、５１ａ〜５１ｃに図示するように、到達時間にばらつきが生じている。これは、上述したように、送話者側では音声サンプリング、エンコード、パケット化に伴った遅延時間が生じ、あるいは伝送経路中の伝送距離に応じた伝播遅延や経路にあるルータにおけるパケットのキューイング遅延等が生じるからである。
【００３６】
タイムスタンパ部５２は、受信した音声パケットのストリームにおける最初の音声パケットの受信時刻Ｔ０とタイムスタンプＴＳ０を取得し、受信時刻Ｔ０を図４の４８に、タイムスタンプＴＳ０を同じく図４の４９にそれぞれ格納する。そして、受信した音声パケットの受信データキューの最後尾アドレスを図４の４７に格納する。ここで、ｎ番目のタイムスタンプＴＳｎは、受信したデータサイズの累計で表現されるので、例えば、音声パケットのデータサイズが100バイトであれば、ｎ番目のパケットのタイムスタンプＴＳｎは100ｎバイトとなる。
【００３７】
タイムスタンパ部５２でタイムスタンプが付与されたユーザＡ、Ｂ、Ｃからの音声パケットデータは、揺らぎ吸収バッファ５３に送られる。この揺らぎ吸収バッファ５３は、図２で示した受信データキュー１５において実現されるものであり、受信データキュー１５に保持されている音声パケットの録音時間の累計時間と同じ揺らぎを吸収することが可能である。1つの音声パケットあたりの録音時間が20msであるから、キュー１５に2つの音声パケットが保持されていれば40msまでの揺らぎを吸収することができる。
【００３８】
揺らぎ吸収処理が行われた各音声データは、時刻同期処理部５４に送られる。時刻同期処理部５４は、20ms周期で動作するカウンタ５８によってその処理が開始される。この同期処理は、サーバ内で動作する計算機内部時計５７で取得した現在時刻Timeが、数式（１）を満たすかどうかを判別することによって行われる。すなわち、比較すべき音声パケットのタイムスタンプＴＳｎが、図４の４８に格納されている最初に受信した音声パケットの受信時刻Ｔ０、同じく図４の４９に格納されている最初に受信した音声パケットのタイムスタンプＴＳ０、連続するRTPパケットのタイムスタンプの増加量ＴＳＩ（例えば100バイト）、音声パケットの送信周期でありかつ1つの音声パケットにおける録音時間ＳＴ（例えば20ms）を固定値とした場合に、サーバの動作するコンピュータの内部時計５７で取得した現在時刻Timeが数式（１）を満たすか否かの判断によって、処理可能な音声パケットかどうかが判断される。
Time≧T0＋{( TSn−TS0)/TSI}×ST    （１）
【００３９】
ここで、(TSn−TS0)は、受信した音声パケットの増加バイト数を表すから、{(TSn−TS0)/TSI}は、増加した音声パケット数を表し、この値に１つの音声パケットにおける録音時間ＳＴ（例えば20ms）を掛け、最初の受信時刻を足した右辺の値は、タイムスタンプＴＳｎが付された音声パケットが到着する時間を示している。
したがって、数１で示す不等式を満たす場合は、処理されるべき音声パケットの到着時間が実際の時刻(Time)より小さいことを意味するから、このパケットは処理可能であると判別される。
【００４０】
ここで、数式（１）に示す不等式が成立しなくなったとき、すなわち、数式（１）の右辺（タイムスタンプTSｎが付された音声パケットの処理時間）が左辺の現在時刻(Time)よりも大きいときは、タイムスタンプTSｎが付された音声パケットを処理する時間がまだ来ていないことを意味している。この場合には、処理すべきパケットは次の処理時間がくるまで、受信データキュー１５（図２）の先頭に戻って処理時間が来るのを待つことになる。
【００４１】
また、数式（１）に示す不等式を満たすだけでは、かなり遅れて到着した音声パケットを処理可能として判断することになる。例えば、現在時刻(Time)よりも1秒以上遅れて到着した音声パケットを処理してしまうことになって、処理後の音声が極めて聞き苦しいものとなる。そこで、任意設定の待機時間閾値（JT）（例えば、パケット2個分の遅延時間40msを有する「揺らぎ吸収バッファサイズ」とする。）を設け、数式（２）を満たす場合、すなわち、現在時刻(Time)とタイムスタンプTSｎが付された音声パケットの処理時刻との差が、待機時間閾値（JT）より大きい場合は、無視できない遅延が発生したと判断して、その音声パケットを処理しないようする。つまり、数式（１）に示す不等式を満たしても、数式（２）の条件を満たす音声パケットは破棄するようにしている。
Time−(T0＋{( TSn−TS0)/TSI}×ST)＞JT        （２）
【００４２】
以上の処理によって、時刻同期処理部５４で処理され、同期されていると判断された時刻同期処理済み音声パケットは、データミキシング処理部５５に送られ、ここで複数参加者からの音声パケットデータのミキシングが行われて、データ送出処理部５６を介して、自分以外の他の参加者に送信される。
【００４３】
次に、図６〜図９に基づいて、本発明のミキシング処理について詳細に説明する。図６はミキシング処理の機能ブロック図であり、図７はその説明のための波形図である。
図６は、ミキシング処理する音声パケットデータが2つの場合を示している。ミキシング対象データ６１ａと６１ｂは比較処理を行うサンプルの組を取得するサンプル取得ブロック６２に供給される。次に、サンプル取得ブロック６２で取得されたサンプルの先頭のサンプルが絶対値計算ブロック６３に供給され、ここで取得されたサンプルの振幅値の絶対値が計算される。絶対値計算ブロック６３でサンプルの振幅値は、大小比較ブロック６４に供給され、ここで絶対値の大小が比較される。
【００４４】
続いて、大小比較ブロック６４で比較されたサンプルの振幅の絶対値のうち大きいほうの絶対値のサンプルがサンプル選択ブロック６５で選択され、サンプル数管理ブロック６６に供給される。サンプル数管理ブロック６６は、何個ごとのサンプルについて選択処理を行うかを予め設定して処理管理するブロックであり、例えば、各音声パケットの連続するｍ個（例えば4個）のサンプルのうち最初のサンプルのみを、大小比較ブロック６４に供給し、続く（ｍ−１）個のサンプルについては、最初のサンプルの比較で大きいと判断された側の音声データのサンプルの振幅絶対値をデータ出力ブロック６７に送るためのものである。この場合、続く（ｍ−１）個のサンプルについては、振幅値の絶対値計算ブロック６３において絶対値計算がなされるだけで大小比較はおこなわれない。ここで、ｍ＝１であれば、全てのサンプルについて、絶対値計算と絶対値の大小比較をおこなうことになることは言うまでもない。
データ出力ブロック６７は、ミキシング済みデータ６８を図5のデータ送信処理部５６に供給する。
【００４５】
上述した音声ミキシング処理は、ＰＣＭ(Pulse Code Modulation)化された音声信号について行われ、ミキシング対象となる音声パケットのサンプル（例えば、サンプリング周波数を8kHzとする。参加者数によっては16kHzや32kHzとすることもできる。）を比較し、比較条件を満たした方を選択することでミキシングが行われる。例えば、８kHzのサンプリングでは、２つの音声ストリームをミキシングする場合、1秒間に8000回の処理を必要とする。また、この処理の回数は参加人数が多くなると、それに比例して大きくなる。
【００４６】
図7は、ユーザから送られる図６に示すミキシング対象データ６１ａ（図７の７１）と６１ｂ（図７の７２）の全てのサンプルについて、大小比較を行う例を示した波形図である。PCM音声は、ビットレートや圧縮方式によりデータ形式が異なるため、詳細な比較条件は違ったものとならざるを得ない。ただ、基本的な概念は、音声データを波形表示した際に、振幅の絶対値７０を求め、大きい方のサンプルを選択することである。
【００４７】
図７に示すように、ユーザから送られた音声パケット７１と音声パケット７２のそれぞれは、サンプルごとに大きいほうが選択され、ミキシングデータ７３として出力される。すなわち、音声パケット７１の最初のサンプル７１ａと音声パケット７２の最初のサンプル７２ａとを比較すると、その絶対値はサンプル７１ａの方が大きいので、サンプル７１ａがミキシングデータとして選択される。この選択は、見かけ上洗い制御ではあるが、実際に扱っている１サンプル当たりの録音時間は8000分の1秒（8kHzサンプリングの場合）とミクロなレベルの制御となる。
【００４８】
図８は、入力されるミキシング対象データが４つの場合の例であり、その他の処理機能ブロックは図６と同じであるので、同一符号を付し、説明は省略する。本例では４つの例を示しているが、ミキシング対象データの数をいくらにするかは、多者間通話の参加者数によって決まるものであり、通話が可能であれば４以上であってもよいことは言うまでもないことである。
【００４９】
次に、図９のフローチャートに基づいて、本発明のミキシング方法の手順について説明する。最初に、ミキシングを行うための音声パケットデータの入力が行われる（ステップＳ８１）。続いて、図６（図８も同じである）のサンプル数管理ブロック６６における処理中のサンプルの順番を表す番号“ｉ”を“１”に初期化する（ステップＳ８２）。次に、図６のサンプル取得ブロック６２において、各入力データの“ｉ”番目のサンプルからＫ個のサンプルの組を取得する(ステップＳ８３)。ここで、Ｋは、同時に処理するサンプル数であり、固定値である。
【００５０】
次に、図６に示す絶対値計算ブロック６３において、各サンプルの組から“ｉ”番目のサンプルの振幅値の絶対値が計算され（ステップＳ８４）、計算された各々の絶対値は大小比較ブロック６４においてその大小関係が比較され、最大の絶対値を持つものが選択される（ステップＳ８５）。続いて、図６のサンプル選択ブロック６５において、振幅値が最大となったサンプルの組の“ｉ”番目から“（ｉ＋Ｋ）−１”番目までのＫ個の出力データが出力サンプルとして選択される（ステップＳ８６）。
【００５１】
次に、サンプル数管理ブロック６６において、“ｉ”を“ｉ＋Ｋ”に更新する。例えば“ｉ”が“１”で“Ｋ”が“４”であれば、次に最大値を比較するサンプルは“４＋１”番目、つまり“５”番目のサンプルになる。ここで、全てのサンプルについて大小関係を判断する場合では、“Ｋ”が“１”となることはいうまでもない。
サンプル処理の順番管理用の番号“ｉ”が更新されると、続いて“ｉ”が入力データの最後に達したか否かが判断される（ステップＳ８８）。ここで、入力データがまだあるとき、すなわち最後まで処理されていないときは、ステップＳ８３に戻り、各入力データから再び更新された“ｉ”番目のデータからＫ個のサンプルを取得する。判断ステップＳ８８で“ｉ”が入力データの最後に達したと判断されると、結果を出力して処理を終了する（ステップＳ８９）。
【００５２】
以上、図６〜図９に基づいて、本発明のミキシング方法及びそのシステムについて説明した。本発明によれば、1回の処理にかかる処理時間は、データに四則演算を行う波形の重ねあわせよりも少ないため、処理時間の低減が可能である。また、本発明の比較ミキシングによれば、複数（特に、３つ以上）のストリームを同時にミキシングする場合には、さらに処理時間の低減を行うことが可能である。
すなわち、波形の重ねあわせで３つのデータをミキシングする場合、まず２つのデータをミキシングし、その結果を残りのデータとミキシングする必要がある。したがって、ミキシングテータ数を8000バイト、ミキシング対象データを“Ｎ”とすると、必要計算数は8000＊”Ｎ−1”となる。
【００５３】
これに対して、本発明の比較ミキシング方法によれば、例えば、３つのミキシング対象データＡ、Ｂ、Ｃをミキシングする場合、Ａ、Ｂ、Ｃ全てのデータに対して、同時に比較演算を行って絶対値最大のものを選択するので、必要計算数はミキシング対象データの数にかかわらず常に8000回/秒になる。
【００５４】
また、音声データの比較でミキシングすることで、さらに高速化を図ることができる。PCM音声には、Differential PCMと呼ばれる圧縮方式がある。これは、連続するサンプル間の差が小さいことを利用し、連続する2つのサンプルの差を取ることで圧縮する手法である。この概念を応用することにより、大小比較を行うミキシングでは、大小比較を行ったサンプルの次のサンプルへも、高確率で結果を適用することができる。
【００５５】
仮に3つ先のサンプルまで比較結果を適用した場合、まず1サンプル目を比較し、大きな方を選択。次の2・3・4サンプル目は、1サンプル目で選択したデータのサンプルを選択するようにする。次に5サンプル目のデータを比較処理し、6・7・8サンプル目のデータは5サンプル目の比較処理で選択したデータのサンプルを選択する。Nサンプル目を比較した場合、N+1・N+2・N+3サンプル目はNサンプル目で選択した側の音声データのサンプルを比較することなく選択する。これを繰り返すことにより、必要となる計算数は2000回/秒となり、計算量が４分の１に低減される。
【００５６】
この方法は、一見荒い制御に見えるが、実際はかなりミクロな時間軸での制御であること、かつ会話では全員が同時に発声することは稀であるので、ほとんど問題にならないで話者の声を識別することが可能である。音楽、男声、女声でミキシングを行った場合、全ての音声を容易に聴覚レベルで認識する事が可能であり、高品質な音声ミキシングを実現できる。
【産業上の利用可能性】
【００５７】
本発明の音声ミキシング方法、音声ミキシングシステム及び音声ミキシングのためのプログラムは、応用サービスとして多人数が同時にコミュニケーションを行うことができる多者間通話システムに用いるに好適である。
【図面の簡単な説明】
【００５８】
【図１】本発明の実施の形態によるネットワークを基盤とする多者間通話システムの概略図である。
【図２】図1における多者間通話サーバ１の機能ブロックを説明するための概略図である。
【図３】ＲＴＰをストリーム制御プロトコルとするパケットフォーマットである。
【図４】図２における参加者情報管理データベース１４における時刻同期に関係するデータ構造を示す図である。
【図５】音声パケットの受信からミキシングして送信するまでの音声パケットの流れを示すシステム構成図である。
【図６】ミキシング対象データが２つの場合の、図５のミキシング処理部５５の細部構成を示すブロック図である。
【図７】ミキシング処理を説明するための波形図である。
【図８】ミキシング対象データが４つの場合の、図５のミキシング処理部５５の細部構成を示すブロック図である。
【図９】ミキシング処理を説明するためのフローチャートである。
【図１０】従来の音声データのミキシングを説明するための図である。
【符号の説明】
【００５９】
１・・・多者間通話サーバ、２・・・IP電話機 、３・・・ネットワーク(インターネット、IP網等)、１１・・・シグナリングモジュール、１２・・・データ受信モジュール、１３・・・参加者情報管理データベース操作モジュール、１４・・・参加者情報管理データベース、１５・・・受信データキュー、１６・・・時刻同期制御モジュール、１７・・・音声ミキシングモジュール、１８・・・データ送信モジュール、１９・・・シグナリングパケット、２０・・・音声パケット(サーバが受信)、２１・・・音声パケット(ミキシング済みでサーバが送信)、５２・・・タイムスタンパ部、５３・・・揺らぎ吸収バッファ、５４・・・時刻同期処理部、５５・・・データミキシング処理部、５６・・・データ送信処理部、６１ａ〜６１ｄ・・・ミキシング対象データ、６２・・・サンプル取得ブロック、６３・・・絶対値計算ブロック、６４・・・大小比較ブロック、６５・・・サンプル選択ブロック、６６・・・サンプル数管理ブロック、６７・・・データ出力ブロック、６８・・・ミキシング済データ
【図１】
2005151044.tif 000003
【図２】
2005151044.tif 000004
【図３】
2005151044.tif 000005
【図４】
2005151044.tif 000006
【図５】
2005151044.tif 000007
【図６】
2005151044.tif 000008
【図７】
2005151044.tif 000009
【図８】
2005151044.tif 000010
【図９】
2005151044.tif 000011
【図１０】
2005151044.tif 000012