JP6476768B2 - 音声処理装置、プログラム及び方法 - Google Patents

Description

この発明は、音声処理装置、プログラム及び方法に関し、例えば、多地点間をネットワーク接続して会議環境を提供する会議システムを構成する会議サーバ（例えば、ＭＣＵ（Ｍｕｌｔｉｐｏｉｎｔ Ｃｏｎｔｒｏｌ Ｕｎｉｔ等の装置）の音声ミキシング処理に適用し得る。

従来、多地点間をネットワーク接続して会議環境を提供する会議システムにおいて、多数の拠点間の音声をミキシングする処理には、通常、専用ハードウェアが用いられる。

ところで、従来の会議システムの音声ミキシング処理を行う装置では、ＩＴＵ−Ｔ Ｇ．７２９などの高圧縮の符号化方式を用いると、デコーダおよびエンコーダの処理負荷が大きくなり、ミキシング可能なチャネル数が制限されるという課題がある。さらに、近年、ネットワーク設備に関する、コスト低減および維持管理の観点から、専用ハードを使用せずに、汎用サーバ上にソフトウェア的にミキシング機能を実現することが求められている。

このような課題を解決するための従来技術として特許文献１の記載技術がある。

特許文献１には、複数の入出力音声データをミキシングする通信ブロックを複数と、中央ミキサを用いることにより、ミキシング演算処理の負荷を軽減し、多地点の音声ミキシングを実現することについて記載されている。

特許公開２００８−２１１２９１号公報

一般的に汎用サーバは、複数のＣＰＵを搭載しており、各ＣＰＵは複数のＣＰＵコアで構成されているが、特許文献１の装置における中央ミキサを汎用サーバ上にソフトウェア的に実装する場合、１つのＣＰＵコアの処理能力が、メディア処理スレッド処理の性能限界となってしまう。例えば、１２コア（２ＣＰＵ×６コア）のサーバの場合、ＣＰＵ全体の１／１２の処理能力でミキシング可能なチャネル数が制限されてしまう。

そのため、低コストでより多くの音声チャネルについてソフトウェア的にミキシング処理可能な音声処理装置、プログラム及び方法が望まれている。

第１の本発明の音声処理装置は、（１）複数の音声処理手段を備え、（１−１）それぞれの上記音声処理手段は、（１−２）時系列ごとの受信音に基づいた受信音データを受信する複数の音信号受信手段と、（１−３）上記複数の音信号受信手段が受信した受信音データを合成して第１の合成音声データを生成する第１の合成手段と、（１−４）第１の合成音声データを保持するバッファ手段と、（１−５）他の上記音声処理手段のそれぞれで生成された第１の合成音声データを合成して第２の合成音声データを生成する第２の合成手段と、（１−６）送信先ごとに、複数の上記音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと上記第２の合成音声データとを合成した送信音データを生成する第３の合成手段とを有し、（１−７）上記バッファ手段は、１つの時系列の第１の合成音声データを保持する複数のバッファ部を循環的に配列した循環バッファに、時系列順に第１の合成音声データを記憶させ、（１−８）上記バッファ手段は、上記循環バッファに、所定数の第１の合成音声データを保持した後に、上記循環バッファで保持している第１の合成音声データの出力を開始することを特徴とする。

第２の本発明の音声処理プログラムは、（１）コンピュータを複数の音声処理手段として機能させ、（２）それぞれの上記音声処理手段は、（２−１）時系列ごとの受信音に基づいた受信音データを受信する複数の音信号受信手段と、（２−２）上記複数の音信号受信手段が受信した受信音データを合成して第１の合成音声データを生成する第１の合成手段と、（２−３）第１の合成音声データを保持するバッファ手段と、（２−４）他の上記音声処理手段のそれぞれで生成された第１の合成音声データを合成して第２の合成音声データを生成する第２の合成手段と、（２−５）送信先ごとに、複数の上記音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと上記第２の合成音声データとを合成した送信音データを生成する第３の合成手段とを有し、（２−６）上記バッファ手段は、１つの時系列の第１の合成音声データを保持する複数のバッファ部を循環的に配列した循環バッファに、時系列順に第１の合成音声データを記憶させ、（２−７）上記バッファ手段は、上記循環バッファに、所定数の第１の合成音声データを保持した後に、上記循環バッファで保持している第１の合成音声データの出力を開始することを特徴とする。

第３の本発明は音声処理装置が実行する音声処理方法において、（１）複数の音声処理手段を備え、（２）それぞれの音声処理手段は、複数の音信号受信手段、第１の合成手段、バッファ手段、第２の合成手段、及び第３の合成手段を備え、（３）それぞれの上記音信号受信手段は、時系列ごとの受信音に基づいた受信音データを受信し、（４）上記第１の合成手段は、上記複数の音信号受信手段が受信した受信音データを合成して第１の合成音声データを生成し、（５）上記バッファ手段は、第１の合成音声データを保持し、（６）上記第２の合成手段は、他の上記音声処理手段のそれぞれで生成された第１の合成音声データを合成して第２の合成音声データを生成し、（７）上記第３の合成手段は、送信先ごとに、複数の上記音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと上記第２の合成音声データとを合成した送信音データを生成させ、（８）上記バッファ手段は、１つの時系列の第１の合成音声データを保持する複数のバッファ部を循環的に配列した循環バッファに、時系列順に第１の合成音声データを記憶させ、（９）上記バッファ手段は、上記循環バッファに、所定数の第１の合成音声データを保持した後に、上記循環バッファで保持している第１の合成音声データの出力を開始することを特徴とする。

本発明によれば、低コストでより多くの音声チャネルについてソフトウェア的にミキシング処理可能な音声処理装置を提供することができる。

第１の実施形態に係る多地点音声ミキシング装置で動作するメディア処理スレッドの構成例について示したブロック図である。 第１の実施形態に係る多地点音声ミキシング装置のハードウェア構成及び接続構成について示したブロック図である。 第１の実施形態に係る多地点音声ミキシング装置に接続する端末の構成の例について示したブロック図である。 第１の実施形態に係る音声受信処理の内部構成の例について示したブロック図である。 第１の実施形態に係る音声送信処理の内部構成の例について示したブロック図である。 第１の実施形態に係る循環バッファの構成例について示した説明図である。 第１の実施形態にミキサの内部構成の例について示した説明図である。 第１の実施形態に係る多地点音声ミキシング装置の動作（メディア処理スレッドの動作）の例について示したタイミングチャートである。 第２の実施形態に係る多地点音声ミキシング装置の動作（メディア処理スレッドの動作）の例について示したタイミングチャートである。

（Ａ）第１の実施形態
以下、本発明による音声処理装置、プログラム及び方法の第１の実施形態を、図面を参照しながら詳述する。以下では、本発明の音声処理装置および音声処理プログラムを多地点音声ミキシング装置に適用する例について説明する。

（Ａ−１）第１の実施形態の構成
図２は、この実施形態の多地点音声ミキシング装置１０のハードウェア構成及び接続構成の例について示したブロック図である。

図２に示すように、多地点音声ミキシング装置１０は、Ｎ×Ｍ台の端末２０−１＿１〜２０−Ｍ＿Ｎ（端末２０−１＿１、２０−１＿２、…、２０−１＿Ｎ、２０−２＿１、２０−２＿２、…、２０−２＿Ｎ、…２０−Ｍ＿１、２０−Ｍ＿２、…、２０−Ｍ＿Ｎ）とネットワーク４０を介して接続している。なお、Ｎ、Ｍは、２以上の任意の整数である。また、Ｎ×Ｍ台の端末２０は、多地点音声ミキシング装置１０に接続可能な最大の端末２０の数であり、多地点音声ミキシング装置１０に接続される端末２０の数は、Ｎ×Ｍ台以下であってもよい。

ネットワーク４０としては例えばＩＰネットワークを適用することができるが、多地点音声ミキシング装置１０と各端末２０との間のネットワーク接続構成については限定されないものである。この実施形態では、多地点音声ミキシング装置１０と各端末２０との間ではＩＰ通信により、音声（会議音声）データのリアルタイム送受信を行うことが可能であるものとする。

図３は、端末２０の内部構成の例について示したブロック図である。

各端末２０は、会議端末（電話端末）として機能するものである。各端末２０の具体的な構成は、図３の構成に限定されないものであり、例えば、ＩＰ電話機やソフトフォンのアプリケーションをインストールしたＰＣ等を適用することができる。

この実施形態では、端末２０は、全て図３のブロック図で示される構成であるものとして以下の説明を行うが、各端末２０の具体的な構成は、図３の構成に限定されないものである。例えば、ＩＰ電話機や、ソフトフォンとして機能するコンピュータ（例えば、ＰＣ，スマートフォン、タブレットＰＣ等にソフトフォンのアプリケーションをインストールしたもの）等を適用することができる。

図３に示す端末２０は、通話処理部２１、ネットワークインタフェースとしての通信部２２、ユーザの音声を捕捉するマイク２３、及びユーザに音声出力するスピーカ２４を有している。マイク２３、及びスピーカ２４は、端末２０において送受話器として機能するものであり、例えば、電話機やスピーカフォンの受話器やヘッドセット等を適用することができる。

通話処理部２１は、音声データ／音声信号の処理や呼制御処理等、通話に係る処理を行うものである。端末２０が、例えば、ＰＣ等の汎用的なコンピュータで構成されている場合には、通話処理部２１はソフトフォンのアプリケーションに該当する構成要素となる。

通話処理部２１は、多地点音声ミキシング装置１０と電話通信の呼の接続を行い、音声データをリアルタイムに送受信する。端末２０と多地点音声ミキシング装置１０との間の呼制御処理や音声通信のプロトコルは限定されないものであるが、例えば、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）等のプロトコルを用いて呼制御処理及び音声通信が可能であるものとする。

通話処理部２１は、マイク２３で捕捉した音声信号に所定の符号化処理（コーデック化）を施した音声データを、多地点音声ミキシング装置１０へ送信する。また、通話処理部２１は、多地点音声ミキシング装置１０から受信した音声データを音声信号に復号して、スピーカ２４から出力させる処理を行う。多地点音声ミキシング装置１０と端末２０との間で用いられる音信号の符号化方式（コーデック）については限定されないものであるが、例えば、例えば、ＩＴＵ−Ｔ Ｇ．７１１、Ｇ．７２９などの符号化方式が適用できる。

次に、多地点音声ミキシング装置１０のハードウェア構成について説明する。

多地点音声ミキシング装置１０は、データ処理部１１、及び通信部１２を備えている。

多地点音声ミキシング装置１０は、例えば、ＰＣやワークステーション等の汎用的なコンピュータ（サーバ装置）に、実施形態の音声処理プログラム等をインストールすることにより構成することができる。

通信部１２は、ネットワーク４０と接続するための通信インタフェースである。

データ処理部１１は、端末２０との電話通信（会議通信）に係る音声処理(例えば、音声データの送受信、や音声ミキシング処理等)をソフトウェア的に行うデータ処理手段（コンピュータ）として機能するものである。

データ処理部１１は、データ処理手段（コンピュータ）として機能するためのプロセッサ１１１及びメモリ１１２を備えている。

図２では、プロセッサ１１１は１つのブロックで図示しているが、物理的に複数のプロセッサで構成するようにしてもよい。また、プロセッサ１１１としては、複数のコアを備えるプロセッサ（マルチコアプロセッサ）を用いて構成するようにしてもよい。

さらに、図２では、メモリ１１２は１つのブロックで図示しているが、具体的な構成については限定されないものであり、例えば、高速に動作する揮発メモリ（例えば、ＳＲＡＭ、ＤＲＡＭ等）と、不揮発メモリ（例えば、フラッシュメモリーやＨＤＤ等）等、複数メディアのメモリを組み合わせて構成するようにしてもよい。この実施形態では、データ処理部１１により構成されるコンピュータに、実施形態の音声処理プログラムがインストールされているものとして説明する。

次に、データ処理部１１に実施形態の音声処理プログラムがインストールされた場合の機能的な構成（スレッドの構成）について図１を用いて説明する。

図１に示すように、多地点音声ミキシング装置１０のデータ処理部１１（実施形態の音声処理プログラム）は、Ｍ個の音声処理手段としてのメディア処理スレッド３０（３０−１〜３０−Ｍ）を用いて、Ｎ×Ｍチャネル（Ｎ×Ｍ台の端末２０との音声データの送信及び受信するチャネル）の音声ミキシング処理を実現する。

メディア処理スレッド３０は、例えば、１０ｍｓごとに、周期起動し、その周期処理の中で、当該周期分（この実施形態の例では１０ｍｓ）を１つの処理単位として音声データの処理を行う。すなわち、それぞれのメディア処理スレッド３０は、Ｎ個のチャネルを処理（Ｎ台の端末２０が送受信する音声データのストリームを処理）することが可能であるものとする。なお、データ処理部１１において、各メディア処理スレッド３０（３０−１〜３０−Ｍ）を生成及び管理する手段（例えば、スレッドの生成及び管理を行うミドルウェアやプログラミング言語等の環境）は限定されないものであり、種々の構成を適用することができる。また、メディア処理スレッド３０における周期起動の間隔や音声データの処理単位の時間は１０ｍｓに限定されないものである。

各メディア処理スレッド３０は、Ｎ個の音声受信処理３１を有している。図１では、メディア処理スレッド３０−１〜３０−Ｍは、それぞれ音声受信処理３１−１＿１〜３１−１＿Ｎ、３１−２＿１〜３１−２＿Ｎ、…、３１−Ｍ＿１〜３１−Ｍ＿Ｎを有している。また、メディア処理スレッド３０−１〜３０−Ｍは、それぞれ音声送信処理３６−１＿１〜３６−１＿Ｎ、３６−２＿１〜３６−２＿Ｎ、…、３６−Ｍ＿１〜３６−Ｍ＿Ｎを有している。音声受信処理３１−１＿１〜３１−Ｍ＿Ｎは、それぞれ端末２０−１＿１〜２０−Ｍ＿Ｎから供給される音声データ（符号化された音声データ）を受信処理するものとなっている。また、音声送信処理３６−１＿１〜３６−Ｍ＿Ｎは、それぞれ端末２０−１＿１〜２０−Ｍ＿Ｎにミキシング処理した音声データ（符号化された音声データ）を送信するものである。

図４は、各音声受信処理３１の内部構成について示したブロック図である。

図４に示すように各音声受信処理３１は、ＲＴＰ受信３１１、ジッタバッファ３１２およびデコーダ３１３を有している。ＲＴＰ受信３１１は、周期処理までに到来したＲＴＰパケットの受信処理を実行し、ＲＴＰペイロード（音声符号化データ）をジッタバッファ３１２に投入する。そして、ジッタバッファ３１２は、１０ｍｓ分（所定の処理単位時間分）の符号化された音声データを取出し、デコーダ３１３で復調（リニア音声データに復調）し、１０ｍｓ分の音声データ（リニア音声データ）を出力する。

図５は、各音声送信処理３６の内部構成について示したブロック図である。

図５に示すように、音声送信処理３６は、エンコーダ３６１およびＲＴＰ送信３６２を有している。エンコーダは、１０ｍｓ分（所定の処理単位時間分）の符号化された音声データをＲＴＰ送信３６２に供給する。そして、ＲＴＰ送信３６２は、ＲＴＰパケット化周期分の符号化された音声データが蓄積できたらＲＴＰパケットを生成し、ＲＴＰパケットを送信する。この実施形態では、例として、ＲＴＰパケット化周期が、２０ｍｓであるものとして説明する。なお、ＲＴＰパケット化周期は２０ｍｓに限定されないものである。

また、各メディア処理スレッド３０（３０−１〜３０−Ｍ）は、加算処理３２（３２−１〜３２−Ｍ）、循環バッファ３３（３３−１〜３３−Ｍ）、加算処理３４（３４−１〜３４−Ｍ）、及びミキサ３５（３５−１〜３５−Ｍ）を有している。例えば、メディア処理スレッド３０−１は、加算処理３２−１、循環バッファ３３−１、加算処理３４−１、及びミキサ３５−１を有している。

以下では、メディア処理スレッド３０−１〜３０−Ｍを、それぞれ１〜Ｍ番目のメディア処理スレッド３０と呼ぶものとする。そして、以下では、任意のｍ番目（ｍは、１〜Ｍの任意の整数）のメディア処理スレッド３０を、メディア処理スレッド３０−ｍと表すものとする。また、以下では、（ｍ−１）番目のメディア処理スレッド３０をメディア処理スレッド３０−（ｍ−１）と呼び、（ｍ＋１）番目のメディア処理スレッド３０をメディア処理スレッド３０−（ｍ＋１）と呼ぶものとする。したがって、メディア処理スレッド３０−ｍは、メディア処理スレッド３０−ｍ、音声受信処理３１−ｍ＿１〜３１−ｍ＿Ｎ、加算処理３２−ｍ、循環バッファ３３−ｍ、加算処理３４−ｍ、ミキサ３５−ｍ、及び音声送信処理３６−ｍ＿１〜３６−ｍ＿Ｎを有していることになる。

また、メディア処理スレッド３０−１〜３０−Ｍの順序は循環的に管理されるものとして説明する。例えば、メディア処理スレッド３０−１に順序が隣接するメディア処理スレッド３０は、メディア処理スレッド３０−２と、メディア処理スレッド３０−Ｍであるものとする。したがって、例えば、メディア処理スレッド３０−（ｍ＋１）〜３０−（ｍ＋Ｍ−１）とした場合は、メディア処理スレッド３０−１〜３０−Ｍのうちメディア処理スレッド３０−ｍ以外を表すことになる。例えば、ｍ＝３とした場合、メディア処理スレッド３０−（ｍ＋１）〜３０−（ｍ＋Ｍ−１）は、メディア処理スレッド３０−１〜３０−２及びメディア処理スレッド３０−４〜３０−Ｍを表すことになる。

以下では、ｍ番目のメディア処理スレッド３０−ｍを中心とした例で、各メディア処理スレッド３０の内部構成について説明する。

加算処理３２−ｍは、音声受信処理３１−ｍ＿１〜３１−ｍ＿Ｎのそれぞれから出力される単位時間分の音声データ（例えば、１０ｍｓ分のリニア音声データ）を加算（合成）し、１０ｍｓ分の音声データを循環バッファ３３−ｍへ書込むものである。なお、加算処理３２が複数の音声データに係る音声を加算（合成）し、加算後（合成後）の音声データを生成する処理については、種々の音声データ加算技術（合成技術）を適用することができるため、詳しい説明は省略する。

図６は、循環バッファ３３−ｍの内部構成について示したブロック図である。

循環バッファ３３は、Ｚ個のバッファ面３３１−１〜３３１−Ｚ、読込み位置ポインタ群３３２、書込み面選択手段３３３、読込面選択手段３３４、及び読込み位置ポインタ選択手段３３５を有している。また、循環バッファ３３−ｍは、書込み位置ポインタＷＰ（ｍ）を保持している。各バッファ面３３１は、メディア処理スレッド３０で、音声データを処理する際の１単位分（この実施形態では１０ｍｓ分の音声データ（リニア音声データ））を保持可能なバッファであるものとする。以下では、バッファ面３３１−１〜３３１−Ｚに対応するポインタ値（アドレス値）を、それぞれ１〜Ｚとする。

書込み位置ポインタＷＰ（ｍ）には、音声データを書き込むポインタ値（バッファ面３３１−１〜３３１−Ｚのいずれかを示すポインタ値）が管理されている。書込み面選択手段３３３は、書込み位置ポインタＷＰ（ｍ）の値を更新（インクリメント）してから、書込み位置ポインタＷＰ（ｍ）に対応するバッファ面３３１に１０ｍｓ分のリニア音声データを書込んでいく。書込み位置ポインタＷＰ（ｍ）のポインタ値は、書込みの契機に、１ずつインクリメントされていき、Ｚまで達したら、その次の書込み契機で１となる。すなわち、バッファ面３３１−１〜３３１−Ｚは、書込み面選択手段３３３により循環的に音声データが書き込まれることになる。

読込み位置ポインタ群３３２には、自己（メディア処理スレッド３０−ｍ）以外のメディア処理スレッド３０−（ｍ＋１）〜３０−（ｍ＋Ｍ−１）のそれぞれに対応する読込み位置ポインタＲＰ（すなわちＭ−１個の読込み位置ポインタＲＰ）が配置されている。例えば、図６では、メディア処理スレッド３０−ｍの読込み位置ポインタ群３３２には、読込み位置ポインタＲＰ（１）、ＲＰ（２）、…、ＲＰ（ｍ−１）、ＲＰ（ｍ＋１）、…、ＲＰ（Ｍ）が配置されている。読込み位置ポインタＲＰは対応するメディア処理スレッド３０に対して読み込ませる音声データのポインタ値（バッファ面３３１−１〜３３１−Ｚのいずれかを示すポインタ値）が保持されている。

読込み位置ポインタ選択手段３３５は、いずれかのメディア処理スレッド３０に対応する読込み位置ポインタＲＰを選択し、当該読込み位置ポインタＲＰのポインタ値を更新（インクリメント）してから、選択した読込み位置ポインタＲＰのポインタ値を読込面選択手段３３４に供給する。読込面選択手段３３４は、供給されたポインタ値に対応するバッファ面３３１から音声データを読込んで出力（読込み位置ポインタ選択手段３３５で選択されたメディア処理スレッド３０に出力）する処理を行う。

読込み位置ポインタ選択手段３３５も、書込み面選択手段３３３と同様に、読込みポインタ値ＲＰのポインタ値を、読込みの契機ごとに１ずつインクリメントしていき、Ｚまで達したら、その次の読込み契機で１とする循環的な動作を行う。

例えば、メディア処理スレッド３０−（ｍ−１）では、読込み位置ポインタＲＰ（ｍ−１）を更新してから、読込み位置ポインタＲＰ（ｍ−１）に対応するバッファ面から１単位分（１０ｍｓ分）の音声データ（リニア音声データ）を読み込んでいく。読込み位置ポインタＲＰ（ｍ−１）は、読込みの契機に１ずつインクリメントしていき、Ｚまで達したら、その次の読込み契機で１とする巡回的な動作を行う。メディア処理スレッド３０−１〜３０−（ｍ−２）、３０−（ｍ＋１）〜３０−Ｍで同様の読込み処理が実施されることになる。

加算処理３４は、他のメディア処理スレッド３０（循環バッファ３３）に、音声データ（読込み位置ポインタＲＰのポインタ値に対応するバッファ面３３１で保持された音声データ）の出力を要求して取得し、それらを加算（合成）した音声データを生成して、ミキサ３５に供給するものである。すなわち、加算処理３４−ｍは、メディア処理スレッド３０−ｍ以外の循環バッファ３３（循環バッファ３３−１〜（ｍ−１）および、循環バッファ３３−（ｍ＋１）〜３３−Ｍ）から、１０ｍｓ分のリニア音声データを読込み、加算（合成）し、１０ｍｓ分のリニア音声データをミキサ３５−ｍへ受け渡すものである。なお、加算処理３４が複数の音声データに係る音声を加算（合成）し、加算後（合成後）の音声データを生成する処理については、種々の音声データ加算技術（合成技術）を適用することができるため、詳しい説明は省略する。

次に、ミキサ３５の内部構成について説明する。

図７は、任意のメディア処理スレッド３０−ｍを構成するミキサ３５−ｍの内部構成について示した説明図である。

ミキサ３５−ｍには、音声送信処理３６−ｍ＿１〜３６−ｍ＿Ｎのそれぞれに供給する音声データを合成処理するミキサ部３５１−１〜３５１−Ｎを有している。

ミキサ部３５１−ｎは、音声受信処理３１−ｍ＿（ｎ＋１）〜３１−ｍ＿（ｎ＋Ｎ―１）から供給される音声データと、加算処理３４−ｍから供給される音声データとを合成（ミキシング）した音声データを生成して、対応する音声送信処理３６に供給する。具体的には、例えば、図７に示すように、ミキサ部３５１−１は、音声送信処理３６−ｍ＿１に合成した音声データを供給するものである。したがって、ミキサ部３５１−１は、図７に示すように、音声送信処理３６−ｍ＿２〜３６−ｍ＿Ｎから供給される音声データと、加算処理３４−ｍから供給される音声データとを合成（ミキシング）することになる。なお、ミキサ部３５１が複数の音声データに係る音声を合成し、合成後の音声データを生成する処理については、種々の音声データ合成技術を適用することができるため、詳しい説明は省略する。

これにより、音声送信処理３６−１＿１の送信先の端末２０−１＿１には、自装置（端末２０−１＿１）から送信された音声データ（音声受信処理３１−１＿１に供給された音声データ）以外の全ての端末２０−１−２〜２０−Ｍ＿Ｎの音声データを合成（ミキシング）した音声データが送信されることになる。これは、その他の全ての端末２０−１−２〜２０−Ｍ＿Ｎについても同様である。このように、多地点音声ミキシング装置１０では、Ｍ×Ｎ台の全ての端末２０−１＿１〜２０−Ｍ＿Ｎに対して、各送信先の端末２０を除外した音声データを合成したものを合成（ミキシング）して送信することができる。

（Ａ−２）第１の実施形態の動作
次に、以上のような構成を有する第１の実施形態の多地点音声ミキシング装置１０の動作（実施形態の音声処理方法）を説明する。

図８は、この実施形態の、循環バッファ３３−ｍの書込み／読込みタイミング例について示したタイミングチャートである。

なお、図８に示す例では、メディア処理スレッド３０を構成するバッファ面３３１の数は８個（すなわちＺ＝８）であるものとして図示している。

図８（ａ）では、メディア処理スレッド３０−ｍの周期処理タイミング、循環バッファ３３−ｍの書込みタイミング、書込み位置ポインタＷＰ（ｍ）の変更タイミング及びポインタ値が図示されている、また、図８（ｂ）では、メディア処理スレッド３０−（ｍ−１）の周期処理タイミング、循環バッファ３３−（ｍ−１）の読込みタイミング、読込み位置ポインタＲＰ（ｍ−１）の変更タイミング及びポインタ値が図示されている。さらに、図８（ｃ）では、メディア処理スレッド３０−（ｍ＋１）の周期処理タイミング、循環バッファ３３−（ｍ＋１）の読込みタイミング、読込み位置ポインタＲＰ（ｍ＋１）の変更タイミング及びポインタ値が図示されている。なお、図８（ａ）に示す書込み位置ポインタＷＰは、メディア処理スレッド３０−ｍに属するポインタである。また、図８（ｂ）に示す読込み位置ポインタＲＰ（ｍ−１）及び図８（ｃ）に示す読込み位置ポインタＲＰ（ｍ＋１）は、いずれもメディア処理スレッド３０−ｍの読込み位置ポインタ群３３２に属するものである。

図８では、メディア処理スレッド３０−（ｍ）からメディア処理スレッド３０−（ｍ−１）へのデータ受け渡し、及び、メディア処理スレッド３０−（ｍ）からメディア処理スレッド３０−（ｍ＋１）へのデータ受け渡しについて説明しているが、メディア処理スレッド３０−（ｍ）からメディア処理スレッド３０−１〜３０−（ｍ−２）および３０−（ｍ＋２）〜３０−Ｍへのデータ受渡しについても同様であるので、詳しい説明を省略する。

ここでは、メディア処理スレッド３０−（ｍ）が、例えば、１０ｍｓごとに周期起動し、起動周期の乱れが発生しなかったとする。すると、メディア処理スレッド３０−（ｍ）では、１０ｍｓごとに循環バッファ（ｍ）への書込み契機が発生する。初回の書込み契機では、書込み位置ポインタＷＰ（ｍ）を１に設定し、バッファ面３３１−１へ１０ｍｓ分のリニア音声データを書込む。次回以降の書込み契機では、書込み位置ポインタＷＰ（ｍ）をインクリメントし、対応するバッファ面３３１へ１０ｍｓ分のリニア音声データを書込んでいく。メディア処理スレッド３０−（ｍ）では、書込み位置ポインタＷＰ（ｍ）がバッファ面数と同じ８となった次の書込み契機では、書込み位置ポインタＷＰ（ｍ）が１に設定され、バッファ面１へ１０ｍｓ分のリニア音声データが書込まれる。

ここでは、メディア処理スレッド３０−（ｍ−１）が、メディア処理スレッド３０−（ｍ）と同様に１０ｍｓごとに周期起動し、起動周期の乱れが発生しなかったとする。すると、メディア処理スレッド３０−（ｍ−１）では、１０ｍｓごとに循環バッファ３３−（ｍ）からの読込み契機が発生する。

メディア処理スレッド３０−（ｍ−１）は、例えば、メディア処理スレッド３０−（ｍ）のバッファ面３３１−１へデータ書込み以降に読込み処理を開始する。

メディア処理スレッド３０−（ｍ）がバッファ面３３１−１へ１０ｍｓ分のリニア音声データを書込んだ後、メディア処理スレッド３０−（ｍ−１）の読込み契機が発生すると、これがメディア処理スレッド３０−（ｍ−１）における初回の読込み契機となる。そうすると、メディア処理スレッド３０−（ｍ）では、読込み位置ポインタＲＰ（ｍ−１）が１に設定される。そして、メディア処理スレッド３０−（ｍ）のバッファ面３３１−１で保持されている音声データ（１０ｍｓ分のリニア音声データ）が、メディア処理スレッド３０−（ｍ−１）に読込まれる。メディア処理スレッド３０−（ｍ）では、次回以降のメディア処理スレッド３０−（ｍ−１）による読込み契機で、読込み位置ポインタＲＰ（ｍ−１）をインクリメントし、対応するバッファ面３３１から音声データ（１０ｍｓ分のリニア音声データ）を供給することになる。読込み位置ポインタＲＰ（ｍ−１）は、バッファ面３３１の面数（最大数）と同じ８（＝Ｚ）となった次の読込み契機では、１に設定されることになる。

ここでは、メディア処理スレッド３０−（ｍ＋１）は、メディア処理スレッド３０−（ｍ）、３０−（ｍ−１）と同様に、１０ｍｓごとに周期起動するものとする。しかし、ここでは、図８に示すように、メディア処理スレッド３０−（ｍ＋１）が、メディア処理スレッド３０−（ｍ）のバッファ面３３１−５の音声データを読込む周期で、周期処理に時間がかかったものとする。さらに、ここでは、図８に示すように、メディア処理スレッド３０−（ｍ＋１）において、バッファ面３３１−５、３３１−６、３３１−７、３３１−８を読込む周期で、起動周期の乱れが発生したとする。データ処理部１１におけるソフトウェア（スレッド）での処理においては、例えばハードディスクへのデータ書込み待ちの発生などにより、通常よりも周期処理時聞が長くなり、起動周期が乱れることが有り得る。

この場合、メディア処理スレッド３０−（ｍ＋１）において、バッファ面３３１−５、３３１−６、３３１−７、３３１−８を読込む周期で、起動周期の乱れに伴いＲＴＰ送信処理が遅延して揺らぎが生じるが、所望のミキシング処理を継続することが出来る。

（Ａ−３）第１の実施形態の効果
第１の実施形態によれば、以下のような効果を奏することができる。

上述の通り、多地点音声ミキシング装置１０では、Ｍ×Ｎ台の全ての端末２０−１＿１〜２０−Ｍ＿Ｎに対して、各送信先の端末２０に係る音声データを除外した音声データを合成（ミキシング）したものを送信することができる。

データ処理部１１では、例えば、各メディア処理スレッド３０を、異なるＣＰＵコアで並列動作することが出来るので、従来、１ＣＰＵコアでＮチャネルのミキシング処理が性能限界であったものが、Ｎ×Ｍチャネルのミキシング処理が実行できるようになる。したがって、本発明の多地点音声ミキシング装置１０は、汎用ＯＳ上でソフトウェア的にＮ×Ｍの音声データを処理することが可能となる。特に多地点音声ミキシング装置１０では、各メディア処理スレッド３０に加算処理３２、循環バッファ３３、加算処理３４、及びミキサ３５を備えることにより、他のメディア処理スレッド３０で合成された音声データを収集して、段階的に合成する。これにより多地点音声ミキシング装置１０では、複数のメディア処理スレッド３０の音声データを中央で処理する構成を必要とせず、複数のメディア処理スレッド３０に分散された音声データ処理のみでＮ×Ｍチャネルのミキシング処理を実現している。

（Ｂ）第２の実施形態
以下、本発明による音声処理装置およびミキシングプログラムの第２の実施形態を、図面を参照しながら詳述する。以下では、本発明の音声処理装置およびミキシングプログラムを多地点音声ミキシング装置に適用する例について説明する。

（Ｂ−１）第２の実施形態の構成
第２の実施形態の多地点音声ミキシング装置１０の構成も上述の図１〜図７を用いて示すことができる。以下では、第２の実施形態の多地点音声ミキシング装置１０について第１の実施形態との差異のみを説明する。

各メディア処理スレッド３０の間では、各メディア処理スレッド３０の間で、起動周期の乱れ等により動作タイミングがずれる場合もあり得る。その場合、一部のメディア処理スレッド３０で、いずれかの読込み位置ポインタＲＰの位置が、書込み位置ポインタＷＰの位置を追い越して、時系列的に不正なデータを処理してしまうおそれがある。そこで、第２の実施形態では、起動周期乱れによるメディア処理スレッド３０間の動作タイミング差分を吸収する処理が行われる。

具体的には、第２の実施形態では、例えば、任意の基準となる１又は複数のメディア処理スレッド３０−（ｍ）以外のメディア処理スレッド３０について、メディア処理スレッド３０−（ｍ）の所定数のバッファ面３３１に書込みが行われて以降（この実施形態では、例として、バッファ面３３１−２へデータ書込み以降）に読込み処理を開始するようにする。さらに、第２の実施形態では、各メディア処理スレッド３０の音声データの読込み契機（他のメディア処理スレッド３０の循環バッファ３３からの読込契機）において、当該メディア処理スレッド３０の読込み位置ポインタＲＰが書込み位置ポインタＷＰ（ｍ）を追い越さないようにする処理構成（例えば、追い越す場合にはインクリメントを行わない）が追加されている。

（Ｂ−２）第２の実施形態の動作
次に、以上のような構成を有する第２の実施形態の多地点音声ミキシング装置１０の動作（実施形態の音声処理方法）を説明する。

図９は、第２の実施形態の、循環バッファ３３−ｍの書込み／読込みタイミング例について示したタイミングチャートである。

なお、図９に示す例では、メディア処理スレッド３０を構成するバッファ面３３１の数は８個（すなわちＺ＝８）であるものとして図示している。

図９（ａ）では、メディア処理スレッド３０−（ｍ）の周期処理タイミング、循環バッファ３３−ｍの書込みタイミング、書込み位置ポインタＷＰ（ｍ）の変更タイミング及びポインタ値が図示されている、また、図９（ｂ）では、メディア処理スレッド３０−（ｍ−１）の周期処理タイミング、循環バッファ３３−（ｍ−１）の読込みタイミング、読込み位置ポインタＲＰ（ｍ−１）の変更タイミング及びポインタ値が図示されている。さらに、図９（ｃ）では、メディア処理スレッド３０−（ｍ＋１）の周期処理タイミング、循環バッファ３３−（ｍ＋１）の読込みタイミング、読込み位置ポインタＲＰ（ｍ＋１）の変更タイミング及ポインタ値が図示されている。なお、図９（ａ）に示す書込み位置ポインタＷＰは、メディア処理スレッド３０−（ｍ）に属するポインタである。また、図９（ｂ）に示す読込み位置ポインタＲＰ（ｍ−１）及び図９（ｃ）に示す読込み位置ポインタＲＰ（ｍ＋１）は、いずれもメディア処理スレッド３０−（ｍ）の読込み位置ポインタ群３３２に属するものである。

図９では、メディア処理スレッド３０−（ｍ）からメディア処理スレッド３０−（ｍ−１）へのデータ受け渡し、及び、メディア処理スレッド３０−（ｍ）からメディア処理スレッド３０−（ｍ＋１）へのデータ受け渡しについて説明しているが、メディア処理スレッド３０−（ｍ）からメディア処理スレッド３０−１〜３０−（ｍ−２）および３０−（ｍ＋２）〜３０−Ｍへのデータ受渡しについても同様であるので、詳しい説明を省略する。

メディア処理スレッド３０−ｍは、例えば、１０ｍｓごとに周期起動するが、バッファ面３３１−４を書込む周期で、周期処理に時間がかかり、バッファ面３３１−５、３３１−６、３３１−７、３３１−８、３３１−１を書込む周期で、起動周期の乱れが発生したとする。ソフトウェアでの処理においては、例えばハードディスクへのデータ書込み待ちの発生などにより、通常よりも周期処理時間が長くなり、起動周期が乱れることが有り得る。

メディア処理スレッド３０−（ｍ−１）は、メディア処理スレッド３０−ｍと同様に１０ｍｓごとに周期起動し、起動周期の乱れが発生しなかったとする。すると、メディア処理スレッド３０−（ｍ−１）では、１０ｍｓごとに循環バッファ３３−ｍからの読込み契機が発生する。

また、この実施形態では、メディア処理スレッド３０−ｍ以外のメディア処理スレッド３０は、メディア処理スレッド３０−ｍのバッファ面３３１−２へデータ書込み以降に読込み処理を開始するものとする。したがって、メディア処理スレッド３０−（ｍ−１）は、メディア処理スレッド３０−ｍのバッファ面３３１−２へデータ書込み以降に読込み処理を開始する。したがって、図９に示すように、メディア処理スレッド３０−ｍがバッファ面３３１−２へ１０ｍｓ分の音声データ（リニア音声データ）を書込んだ後、メディア処理スレッド３０−（ｍ−１）の読込み契機が発生すると、これが初回の読込み契機となる。このとき、メディア処理スレッド３０−ｍは、読込み位置ポインタＲＰ（ｍ−１）を１に設定し、バッファ面３３１−１から１０ｍｓ分の音声データ（リニア音声データ）を読込む。メディア処理スレッド３０−ｍは、次回以降の読込み契機において、読込み位置ポインタＲＰ（ｍ−１）をインクリメントし、対応するバッファ面３３１から１０ｍｓ分の音声データ（リニア音声データ）を読込んでいくことになる。

図９に示すように、読込み位置ポインタＲＰ（ｍ−１）が５の時の最初の読込み契機（メディア処理スレッド３０−ｍの読込み契機）では、メディア処理スレッド３０−ｍの書込み位置ポインタＷＰ（ｍ）の値が５である。したがって、この時点で、メディア処理スレッド３０−ｍにおいて、バッファ面３３１−５に最新の音声データが書込まれており、バッファ面３３１−６には、まだ音声データが書き込まれていない。そこで、メディア処理スレッド３０−（ｍ−１）は、この読込み契機において、読込み位置ポインタＲＰ（ｍ−１）を前値保持として(インクリメントを行わず)、バッファ面３３１−５の音声データを読込むようにする。この場合メディア処理スレッド３０−（ｍ−１）は、バッファ面３３１−５の音声データを２回連続で読込むので、この契機では、一瞬、音声の連続性が失われるが、それ以降の音声の連続性を保つことが出来る。

メディア処理スレッド３０−（ｍ−１）では、音声データを２回連続で読込む代わりに、デコーダでのパケットロス補償と同様の処理を実行することにより、過去音声より疑似人工音声（ダミー用音声）を生成してもよい。そうすれば、この契機においても音声の連続性を保つことが出来る。そして、読込み位置ポインタＲＰ（ｍ−１）がバッファ面数と同じ８となった次の読込み契機では、読込み位置ポインタＲＰ（ｍ−１）を１に設定し、メディア処理スレッド３０−ｍのバッファ面３３１−１から１０ｍｓ分の音声データ（リニア音声データ）を読込む。

（Ｂ−３）第２の実施形態の効果
第２の実施形態によれば、第１の実施形態の効果に加えて、以下のような効果を奏することができる。

第２の実施形態の多地点音声ミキシング装置１０では、任意の基準となるメディア処理スレッド３０で複数のバッファ面３３１へのデータ書込み以降に、他のメディア処理スレッド３０の読込み処理を開始するようにしている。また、第２の実施形態の多地点音声ミキシング装置１０では、メディア処理スレッド３０の読込み契機（他のメディア処理スレッド３０からの音声データの読込み契機）において、読込み位置ポインタＲＰが書込み位置ポインタＷＰ（ｍ）を追い越さないようにする処理を追加したので、読込みデータの音声の連続性を保つことができる。

（Ｃ）他の実施形態
本発明は、上記の各実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。

（Ｃ−１）第２実施形態では、読込み位置ポインタＲＰが書込み位置ポインタＷＰ（ｍ）を追い越さないようにする処理について説明した。しかし、書込み位置ポインタＷＰ（ｍ）と読込み位置ポインタＲＰとのバッファ面数差分は、バッファ面数差分×起動周期の伝送遅延となり、この伝送遅延が大きくなり過ぎるのは望ましくない。そこで、各メディア処理スレッド３０において、伝送遅延の遅延回復処理を実施するようにしても良い。例えば、各メディア処理スレッド３０は、「書込み位置ポインタＷＰ（ｍ）−読込み位置ポインタＲＰ≧Ｘ」（例えば、Ｘ＝４）となった時点で、読込み位置ポインタＲＰを２つインクリメントしてから、データ読込みを実施するようにして、伝送遅延の遅延回復処理を実施するようにしても良い。更に、各メディア処理スレッド３０は、「書込み位置ポインタＷＰ（ｍ）−読込み位置ポインタＲＰ≧Ｘ」が成立した時に、音声データが無い無音区間のみで、読込み位置ポインタＲＰを２つインクリメントするようにしても良い。

（Ｃ−２）上記の各実施形態では、本発明の音声処理装置を、多地点音声ミキシング装置に適用する例について説明したが、音声データを受信してミキシングする種々の装置に適用することができる。また、上記の各実施形態では、符号化された音声データのパケットを受信して音声ミキシング処理する例について説明したが、受信する際の音声データの符号化方式や分割形式等は限定されないことは当然である。

１０…多地点音声ミキシング装置、１１…データ処理部、１１１…プロセッサ、１１２…メモリ、１２…通信部、４０…ネットワーク、２０、２０−１＿１〜２０−Ｍ＿Ｎ…端末、２１…通話処理部、２２…通信部、２３…マイク、２４…スピーカ、３０、３０−１〜３０−Ｍ…メディア処理スレッド、３１、３１−１＿１〜３１−Ｍ＿Ｎ…音声受信処理、３１１…ＲＴＰ受信、３１２…ジッタバッファ、３１３…デコーダ、３２、３２−１〜３２−Ｍ…加算処理、３３、３３−１〜３３−Ｍ…循環バッファ、３４、３４−１〜３４−Ｍ…加算処理３４、３５、３５−１〜３５−Ｍ…ミキサ、３６、３６−１＿１〜３６−Ｍ＿Ｎ…音声送信処理、３６１…エンコーダ、３６２…ＲＴＰ送信、３３１、３３１−１〜３３１−Ｚ…バッファ面、３３２…読込み位置ポインタ群、３３３…書込み面選択手段、３３４…読込面選択手段、３３５…読込み位置ポインタ選択手段、３５１、３５１−１〜３５１−Ｎ…ミキサ部。

Claims (7)

1. 複数の音声処理手段を備え、
   それぞれの上記音声処理手段は、
   時系列ごとの受信音に基づいた受信音データを受信する複数の音信号受信手段と、
   上記複数の音信号受信手段が受信した受信音データを合成して第１の合成音声データを生成する第１の合成手段と、
   第１の合成音声データを保持するバッファ手段と、
   他の上記音声処理手段のそれぞれで生成された第１の合成音声データを合成して第２の合成音声データを生成する第２の合成手段と、
   送信先ごとに、複数の上記音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと上記第２の合成音声データとを合成した送信音データを生成する第３の合成手段とを有し、
   上記バッファ手段は、１つの時系列の第１の合成音声データを保持する複数のバッファ部を循環的に配列した循環バッファに、時系列順に第１の合成音声データを記憶させ、
   上記バッファ手段は、上記循環バッファに、所定数の第１の合成音声データを保持した後に、上記循環バッファで保持している第１の合成音声データの出力を開始する
   ことを特徴とする音声処理装置。
2. 上記バッファ手段は、上記循環バッファの読込み位置を管理する読込みポインタと、上記循環バッファの書込み位置を管理する書込みポインタを有し、上記読込みポインタの位置が、上記書込みポインタの位置を追い越さないように、上記読込みポインタの位置を制御することを特徴とする請求項１に記載の音声処理装置。
3. 上記バッファ手段は、上記読込みポインタに対応する第１の合成音声データを読み込む際に、上記読込みポインタの位置と、上記書込みポインタの位置とが同じであった場合、上記読込みポインタの位置をインクリメントしないことを特徴とする請求項２に記載の音声処理装置。
4. 上記バッファ手段は、上記読込みポインタに対応する第１の合成音声データを読み込む際に、上記書込みポインタの位置と、上記読込みポインタの位置との差分が閾値以上だった場合、上記読込み位置ポインタについて２以上の値インクリメントすることを特徴とする請求項２に記載の音声処理装置。
5. それぞれの上記音声処理手段は、コンピュータ上のスレッドで構成されていることを特徴とする請求項１〜４のいずれかに記載の音声処理装置。
6. コンピュータを複数の音声処理手段として機能させ、
   それぞれの上記音声処理手段は、
   時系列ごとの受信音に基づいた受信音データを受信する複数の音信号受信手段と、
   上記複数の音信号受信手段が受信した受信音データを合成して第１の合成音声データを生成する第１の合成手段と、
   第１の合成音声データを保持するバッファ手段と、
   他の上記音声処理手段のそれぞれで生成された第１の合成音声データを合成して第２の合成音声データを生成する第２の合成手段と、
   送信先ごとに、複数の上記音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと上記第２の合成音声データとを合成した送信音データを生成する第３の合成手段とを有し、
   上記バッファ手段は、１つの時系列の第１の合成音声データを保持する複数のバッファ部を循環的に配列した循環バッファに、時系列順に第１の合成音声データを記憶させ、
   上記バッファ手段は、上記循環バッファに、所定数の第１の合成音声データを保持した後に、上記循環バッファで保持している第１の合成音声データの出力を開始する
   ことを特徴とする音声処理プログラム。
7. 音声処理装置が実行する音声処理方法において、
   複数の音声処理手段を備え、
   それぞれの音声処理手段は、複数の音信号受信手段、第１の合成手段、バッファ手段、第２の合成手段、及び第３の合成手段を備え、
   それぞれの上記音信号受信手段は、時系列ごとの受信音に基づいた受信音データを受信し、
   上記第１の合成手段は、上記複数の音信号受信手段が受信した受信音データを合成して第１の合成音声データを生成し、
   上記バッファ手段は、第１の合成音声データを保持し、
   上記第２の合成手段は、他の上記音声処理手段のそれぞれで生成された第１の合成音声データを合成して第２の合成音声データを生成し、
   上記第３の合成手段は、送信先ごとに、複数の上記音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと上記第２の合成音声データとを合成した送信音データを生成し、
   上記バッファ手段は、１つの時系列の第１の合成音声データを保持する複数のバッファ部を循環的に配列した循環バッファに、時系列順に第１の合成音声データを記憶させ、
   上記バッファ手段は、上記循環バッファに、所定数の第１の合成音声データを保持した後に、上記循環バッファで保持している第１の合成音声データの出力を開始する
   ことを特徴とする音声処理方法。

Images