図面 (/)

技術 音声処理装置、プログラム及び方法

出願人 沖電気工業株式会社
発明者 石黒高詩
出願日 2014年11月7日 (6年1ヶ月経過) 出願番号 2014-227163
公開日 2016年5月23日 (4年7ヶ月経過) 公開番号 2016-092679
状態 特許登録済
技術分野 電話通信サービス 可聴帯域変換器の回路等
主要キーワード Nチャネル 分割形式 遅延回復 前値保持 書込み面 人工音声 読込みデータ 周期処理
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年5月23日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (10)

課題

低コストでより多くの音声チャネルについてソフトウェア的にミキシング処理可能な音声処理装置

解決手段

本発明は、音声処理装置に関する。そして、音声処理装置は、複数の音声処理手段を備え、それぞれの音声処理手段は、時系列ごと受信音に基づいた受信音データを受信する複数の音信号受信手段と、複数の音信号受信手段が受信した受信音データを合成して第1の合成音声データを生成する第1の合成手段と、第1の合成音声データを保持するバッファ手段と、他の音声処理手段のそれぞれで生成された第1の合成音声データを合成して第2の合成音声データを生成する第2の合成手段と、送信先ごとに、複数の音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと第2の合成音声データとを合成した送信音データを生成する第3の合成手段とを有することを特徴とする。

概要

背景

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

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

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

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

概要

低コストでより多くの音声チャネルについてソフトウェア的にミキシング処理可能な音声処理装置本発明は、音声処理装置に関する。そして、音声処理装置は、複数の音声処理手段を備え、それぞれの音声処理手段は、時系列ごと受信音に基づいた受信音データを受信する複数の音信号受信手段と、複数の音信号受信手段が受信した受信音データを合成して第1の合成音声データを生成する第1の合成手段と、第1の合成音声データを保持するバッファ手段と、他の音声処理手段のそれぞれで生成された第1の合成音声データを合成して第2の合成音声データを生成する第2の合成手段と、送信先ごとに、複数の音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと第2の合成音声データとを合成した送信音データを生成する第3の合成手段とを有することを特徴とする。

目的

この発明は、音声処理装置、プログラム及び方法に関し、例えば、多地点間をネットワーク接続して会議環境を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

複数の音声処理手段を備え、それぞれの上記音声処理手段は、時系列ごと受信音に基づいた受信音データを受信する複数の音信号受信手段と、上記複数の音信号受信手段が受信した受信音データを合成して第1の合成音声データを生成する第1の合成手段と、第1の合成音声データを保持するバッファ手段と、他の上記音声処理手段のそれぞれで生成された第1の合成音声データを合成して第2の合成音声データを生成する第2の合成手段と、送信先ごとに、複数の上記音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと上記第2の合成音声データとを合成した送信音データを生成する第3の合成手段とを有することを特徴とする音声処理装置

請求項2

上記バッファ手段は、1つの時系列の第1の合成音声データを保持する複数のバッファ部を循環的に配列した循環バッファに、時系列順に第1の合成音声データを記憶させることを特徴とする請求項1に記載の音声処理装置。

請求項3

上記バッファ手段は、上記循環バッファに、複数の第1の合成音声データを保持した後に、上記循環バッファで保持している第1の合成音声データの出力を開始することを特徴とする請求項2に記載の音声処理装置。

請求項4

上記バッファ手段は、上記循環バッファの読込み位置を管理する読込みポインタと、上記循環バッファの書込み位置を管理する書込みポインタを有し、上記読込みポインタの位置が、上記書込みポインタの位置を追い越さないように、上記読込みポインタの位置を制御することを特徴とする請求項2又は3に記載の音声処理装置。

請求項5

上記バッファ手段は、上記読込みポインタに対応する第1の合成音声データを読み込む際に、上記読込みポインタの位置と、上記書込みポインタの位置とが同じであった場合、上記読込みポインタの位置をインクリメントしないことを特徴とする請求項4に記載の音声処理装置。

請求項6

上記バッファ手段は、上記読込みポインタに対応する第1の合成音声データを読み込む際に、上記書込みポインタの位置と、上記読込みポインタの位置との差分が閾値以上だった場合、上記読込み位置ポインタについて2以上の値インクリメントすることを特徴とする請求項4に記載の音声処理装置。

請求項7

それぞれの上記音声処理手段は、コンピュータ上のスレッドで構成されていることを特徴とする請求項1〜6のいずれかに記載の音声処理装置。

請求項8

コンピュータを複数の音声処理手段として機能させ、それぞれの上記音声処理手段は、時系列ごとの受信音に基づいた受信音データを受信する複数の音信号受信手段と、上記複数の音信号受信手段が受信した受信音データを合成して第1の合成音声データを生成する第1の合成手段と、第1の合成音声データを保持するバッファ手段と、他の上記音声処理手段のそれぞれで生成された第1の合成音声データを合成して第2の合成音声データを生成する第2の合成手段と、送信先ごとに、複数の上記音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと上記第2の合成音声データとを合成した送信音データを生成する第3の合成手段とを有することを特徴とする音声処理プログラム

請求項9

音声処理装置が実行する音声処理方法において、複数の音声処理手段を備え、それぞれの音声処理手段は、複数の音信号受信手段、第1の合成手段、バッファ手段、第2の合成手段、及び第3の合成手段を備え、それぞれの上記音信号受信手段は、時系列ごとの受信音に基づいた受信音データを受信し、上記第1の合成手段は、上記複数の音信号受信手段が受信した受信音データを合成して第1の合成音声データを生成し、上記バッファ手段は、第1の合成音声データを保持し、上記第2の合成手段は、他の上記音声処理手段のそれぞれで生成された第1の合成音声データを合成して第2の合成音声データを生成し、上記第3の合成手段は、送信先ごとに、複数の上記音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと上記第2の合成音声データとを合成した送信音データを生成することを特徴とする音声処理方法。

技術分野

0001

この発明は、音声処理装置プログラム及び方法に関し、例えば、多地点間ネットワーク接続して会議環境を提供する会議ステムを構成する会議サーバ(例えば、MCU(Multipoint Control Unit等の装置)の音声ミキシング処理に適用し得る。

背景技術

0002

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

0003

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

0004

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

0005

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

先行技術

0006

特許公開2008−211291号公報

発明が解決しようとする課題

0007

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

0008

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

課題を解決するための手段

0009

第1の本発明の音声処理装置は、(1)複数の音声処理手段を備え、(1−1)それぞれの上記音声処理手段は、(1−2)時系列ごと受信音に基づいた受信音データを受信する複数の音信号受信手段と、(1−3)上記複数の音信号受信手段が受信した受信音データを合成して第1の合成音声データを生成する第1の合成手段と、(1−4)第1の合成音声データを保持するバッファ手段と、(1−5)他の上記音声処理手段のそれぞれで生成された第1の合成音声データを合成して第2の合成音声データを生成する第2の合成手段と、(1−6)送信先ごとに、複数の上記音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと上記第2の合成音声データとを合成した送信音データを生成する第3の合成手段とを有することを特徴とする。

0010

第2の本発明の音声処理プログラムは、(1)コンピュータを複数の音声処理手段として機能させ、(2)それぞれの上記音声処理手段は、(2−1)時系列ごとの受信音に基づいた受信音データを受信する複数の音信号受信手段と、(2−2)上記複数の音信号受信手段が受信した受信音データを合成して第1の合成音声データを生成する第1の合成手段と、(2−3)第1の合成音声データを保持するバッファ手段と、(2−4)他の上記音声処理手段のそれぞれで生成された第1の合成音声データを合成して第2の合成音声データを生成する第2の合成手段と、(2−5送信先ごとに、複数の上記音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと上記第2の合成音声データとを合成した送信音データを生成する第3の合成手段とを有することを特徴とする。

0011

第3の本発明は音声処理装置が実行する音声処理方法において、(1)複数の音声処理手段を備え、(2)それぞれの音声処理手段は、複数の音信号受信手段、第1の合成手段、バッファ手段、第2の合成手段、及び第3の合成手段を備え、(3)それぞれの上記音信号受信手段は、時系列ごとの受信音に基づいた受信音データを受信し、(4)上記第1の合成手段は、上記複数の音信号受信手段が受信した受信音データを合成して第1の合成音声データを生成し、(5)上記バッファ手段は、第1の合成音声データを保持し、(6)上記第2の合成手段は、他の上記音声処理手段のそれぞれで生成された第1の合成音声データを合成して第2の合成音声データを生成し、(7)上記第3の合成手段は、送信先ごとに、複数の上記音信号受信手段が受信した受信音データから当該送信先に係る受信音データを除外した音声データと上記第2の合成音声データとを合成した送信音データを生成することを特徴とする。

発明の効果

0012

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

図面の簡単な説明

0013

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

実施例

0014

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

0015

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

0016

図2に示すように、多地点音声ミキシング装置10は、N×M台の端末20−1_1〜20−M_N(端末20−1_1、20−1_2、…、20−1_N、20−2_1、20−2_2、…、20−2_N、…20−M_1、20−M_2、…、20−M_N)とネットワーク40を介して接続している。なお、N、Mは、2以上の任意の整数である。また、N×M台の端末20は、多地点音声ミキシング装置10に接続可能な最大の端末20の数であり、多地点音声ミキシング装置10に接続される端末20の数は、N×M台以下であってもよい。

0017

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

0018

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

0019

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

0020

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

0021

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

0022

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

0023

通話処理部21は、多地点音声ミキシング装置10と電話通信の呼の接続を行い、音声データをリアルタイムに送受信する。端末20と多地点音声ミキシング装置10との間の呼制御処理や音声通信プロトコルは限定されないものであるが、例えば、SIP(Session Initiation Protocol)やRTP(Real−time Transport Protocol)等のプロトコルを用いて呼制御処理及び音声通信が可能であるものとする。

0024

通話処理部21は、マイク23で捕捉した音声信号に所定の符号化処理コーデック化)を施した音声データを、多地点音声ミキシング装置10へ送信する。また、通話処理部21は、多地点音声ミキシング装置10から受信した音声データを音声信号に復号して、スピーカ24から出力させる処理を行う。多地点音声ミキシング装置10と端末20との間で用いられる音信号の符号化方式(コーデック)については限定されないものであるが、例えば、例えば、ITU−T G.711、G.729などの符号化方式が適用できる。

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

図1に示すように、多地点音声ミキシング装置10のデータ処理部11(実施形態の音声処理プログラム)は、M個の音声処理手段としてのメディア処理スレッド30(30−1〜30−M)を用いて、NXMチャネル(N×M台の端末20との音声データの送信及び受信するチャネル)の音声ミキシング処理を実現する。

0035

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

0036

各メディア処理スレッド30は、N個の音声受信処理31を有している。図1では、メディア処理スレッド30−1〜30−Mは、それぞれ音声受信処理31−1_1〜31−1_N、31−2_1〜31−2_N、…、31−M_1〜31−M_Nを有している。また、メディア処理スレッド30−1〜30−Mは、それぞれ音声送信処理36−1_1〜36−1_N、36−2_1〜36−2_N、…、36−M_1〜36−M_Nを有している。音声受信処理31−1_1〜31−M_Nは、それぞれ端末20−1_1〜20−M_Nから供給される音声データ(符号化された音声データ)を受信処理するものとなっている。また、音声送信処理36−1_1〜36−M_Nは、それぞれ端末20−1_1〜20−M_Nにミキシング処理した音声データ(符号化された音声データ)を送信するものである。

0037

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

0038

図4に示すように各音声受信処理31は、RTP受信311、ジッタバッファ312およびデコーダ313を有している。RTP受信311は、周期処理までに到来したRTPパケットの受信処理を実行し、RTPペイロード音声符号化データ)をジッタバッファ312に投入する。そして、ジッタバッファ312は、10ms分(所定の処理単位時間分)の符号化された音声データを取出し、デコーダ313で復調リニア音声データに復調)し、10ms分の音声データ(リニア音声データ)を出力する。

0039

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

0040

図5に示すように、音声送信処理36は、エンコーダ361およびRTP送信362を有している。エンコーダは、10ms分(所定の処理単位時間分)の符号化された音声データをRTP送信362に供給する。そして、RTP送信362は、RTPパケット化周期分の符号化された音声データが蓄積できたらRTPパケットを生成し、RTPパケットを送信する。この実施形態では、例として、RTPパケット化周期が、20msであるものとして説明する。なお、RTPパケット化周期は20msに限定されないものである。

0041

また、各メディア処理スレッド30(30−1〜30−M)は、加算処理32(32−1〜32−M)、循環バッファ33(33−1〜33−M)、加算処理34(34−1〜34−M)、及びミキサ35(35−1〜35−M)を有している。例えば、メディア処理スレッド30−1は、加算処理32−1、循環バッファ33−1、加算処理34−1、及びミキサ35−1を有している。

0042

以下では、メディア処理スレッド30−1〜30−Mを、それぞれ1〜M番目のメディア処理スレッド30と呼ぶものとする。そして、以下では、任意のm番目(mは、1〜Mの任意の整数)のメディア処理スレッド30を、メディア処理スレッド30−mと表すものとする。また、以下では、(m−1)番目のメディア処理スレッド30をメディア処理スレッド30−(m−1)と呼び、(m+1)番目のメディア処理スレッド30をメディア処理スレッド30−(m+1)と呼ぶものとする。したがって、メディア処理スレッド30−mは、メディア処理スレッド30−m、音声受信処理31−m_1〜31−m_N、加算処理32−m、循環バッファ33−m、加算処理34−m、ミキサ35−m、及び音声送信処理36−m_1〜36−m_Nを有していることになる。

0043

また、メディア処理スレッド30−1〜30−Mの順序循環的に管理されるものとして説明する。例えば、メディア処理スレッド30−1に順序が隣接するメディア処理スレッド30は、メディア処理スレッド30−2と、メディア処理スレッド30−Mであるものとする。したがって、例えば、メディア処理スレッド30−(m+1)〜30−(m+M−1)とした場合は、メディア処理スレッド30−1〜30−Mのうちメディア処理スレッド30−m以外を表すことになる。例えば、m=3とした場合、メディア処理スレッド30−(m+1)〜30−(m+M−1)は、メディア処理スレッド30−1〜30−2及びメディア処理スレッド30−4〜30−Mを表すことになる。

0044

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

0045

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

0046

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

0047

循環バッファ33は、Z個のバッファ面331−1〜331−Z、読込位置ポインタ群332、書込み面選択手段333、読込面選択手段334、及び読込み位置ポインタ選択手段335を有している。また、循環バッファ33−mは、書込み位置ポインタWP(m)を保持している。各バッファ面331は、メディア処理スレッド30で、音声データを処理する際の1単位分(この実施形態では10ms分の音声データ(リニア音声データ))を保持可能なバッファであるものとする。以下では、バッファ面331−1〜331−Zに対応するポインタ値アドレス値)を、それぞれ1〜Zとする。

0048

書込み位置ポインタWP(m)には、音声データを書き込むポインタ値(バッファ面331−1〜331−Zのいずれかを示すポインタ値)が管理されている。書込み面選択手段333は、書込み位置ポインタWP(m)の値を更新インクリメント)してから、書込み位置ポインタWP(m)に対応するバッファ面331に10ms分のリニア音声データを書込んでいく。書込み位置ポインタWP(m)のポインタ値は、書込みの契機に、1ずつインクリメントされていき、Zまで達したら、その次の書込み契機で1となる。すなわち、バッファ面331−1〜331−Zは、書込み面選択手段333により循環的に音声データが書き込まれることになる。

0049

読込み位置ポインタ群332には、自己(メディア処理スレッド30−m)以外のメディア処理スレッド30−(m+1)〜30−(m+M−1)のそれぞれに対応する読込み位置ポインタRP(すなわちM−1個の読込み位置ポインタRP)が配置されている。例えば、図6では、メディア処理スレッド30−mの読込み位置ポインタ群332には、読込み位置ポインタRP(1)、RP(2)、…、RP(m−1)、RP(m+1)、…、RP(M)が配置されている。読込み位置ポインタRPは対応するメディア処理スレッド30に対して読み込ませる音声データのポインタ値(バッファ面331−1〜331−Zのいずれかを示すポインタ値)が保持されている。

0050

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

0051

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

0052

例えば、メディア処理スレッド30−(m−1)では、読込み位置ポインタRP(m−1)を更新してから、読込み位置ポインタRP(m−1)に対応するバッファ面から1単位分(10ms分)の音声データ(リニア音声データ)を読み込んでいく。読込み位置ポインタRP(m−1)は、読込みの契機に1ずつインクリメントしていき、Zまで達したら、その次の読込み契機で1とする巡回的な動作を行う。メディア処理スレッド30−1〜30−(m−2)、30−(m+1)〜30−Mで同様の読込み処理が実施されることになる。

0053

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

0054

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

0055

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

0056

ミキサ35−mには、音声送信処理36−m_1〜36−m_Nのそれぞれに供給する音声データを合成処理するミキサ部351−1〜351−Nを有している。

0057

ミキサ部351−nは、音声受信処理31−m_(n+1)〜31−m_(n+N—1)から供給される音声データと、加算処理34−mから供給される音声データとを合成(ミキシング)した音声データを生成して、対応する音声送信処理36に供給する。具体的には、例えば、図7に示すように、ミキサ部351−1は、音声送信処理36−m_1に合成した音声データを供給するものである。したがって、ミキサ部351−1は、図7に示すように、音声送信処理36−m_2〜36−m_Nから供給される音声データと、加算処理34−mから供給される音声データとを合成(ミキシング)することになる。なお、ミキサ部351が複数の音声データに係る音声を合成し、合成後の音声データを生成する処理については、種々の音声データ合成技術を適用することができるため、詳しい説明は省略する。

0058

これにより、音声送信処理36−1_1の送信先の端末20−1_1には、自装置(端末20−1_1)から送信された音声データ(音声受信処理31−1_1に供給された音声データ)以外の全ての端末20−1−2〜20−M_Nの音声データを合成(ミキシング)した音声データが送信されることになる。これは、その他の全ての端末20−1−2〜20−M_Nについても同様である。このように、多地点音声ミキシング装置10では、M×N台の全ての端末20−1_1〜20−M_Nに対して、各送信先の端末20を除外した音声データを合成したものを合成(ミキシング)して送信することができる。

0059

(A−2)第1の実施形態の動作
次に、以上のような構成を有する第1の実施形態の多地点音声ミキシング装置10の動作(実施形態の音声処理方法)を説明する。

0060

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

0061

なお、図8に示す例では、メディア処理スレッド30を構成するバッファ面331の数は8個(すなわちZ=8)であるものとして図示している。

0062

図8(a)では、メディア処理スレッド30−mの周期処理タイミング、循環バッファ33−mの書込みタイミング、書込み位置ポインタWP(m)の変更タイミング及びポインタ値が図示されている、また、図8(b)では、メディア処理スレッド30−(m−1)の周期処理タイミング、循環バッファ33−(m−1)の読込みタイミング、読込み位置ポインタRP(m−1)の変更タイミング及びポインタ値が図示されている。さらに、図8(c)では、メディア処理スレッド30−(m+1)の周期処理タイミング、循環バッファ33−(m+1)の読込みタイミング、読込み位置ポインタRP(m+1)の変更タイミング及びポインタ値が図示されている。なお、図8(a)に示す書込み位置ポインタWPは、メディア処理スレッド30−mに属するポインタである。また、図8(b)に示す読込み位置ポインタRP(m−1)及び図8(c)に示す読込み位置ポインタRP(m+1)は、いずれもメディア処理スレッド30−mの読込み位置ポインタ群332に属するものである。

0063

図8では、メディア処理スレッド30−(m)からメディア処理スレッド30−(m−1)へのデータ受け渡し、及び、メディア処理スレッド30−(m)からメディア処理スレッド30−(m+1)へのデータ受け渡しについて説明しているが、メディア処理スレッド30−(m)からメディア処理スレッド30−1〜30−(m−2)および30−(m+2)〜30−Mへのデータ受渡しについても同様であるので、詳しい説明を省略する。

0064

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

0065

ここでは、メディア処理スレッド30−(m−1)が、メディア処理スレッド30−(m)と同様に10msごとに周期起動し、起動周期の乱れが発生しなかったとする。すると、メディア処理スレッド30−(m−1)では、10msごとに循環バッファ33−(m)からの読込み契機が発生する。

0066

メディア処理スレッド30−(m−1)は、例えば、メディア処理スレッド30−(m)のバッファ面331−1へデータ書込み以降に読込み処理を開始する。

0067

メディア処理スレッド30−(m)がバッファ面331−1へ10ms分のリニア音声データを書込んだ後、メディア処理スレッド30−(m−1)の読込み契機が発生すると、これがメディア処理スレッド30−(m−1)における初回の読込み契機となる。そうすると、メディア処理スレッド30−(m)では、読込み位置ポインタRP(m−1)が1に設定される。そして、メディア処理スレッド30−(m)のバッファ面331−1で保持されている音声データ(10ms分のリニア音声データ)が、メディア処理スレッド30−(m−1)に読込まれる。メディア処理スレッド30−(m)では、次回以降のメディア処理スレッド30−(m−1)による読込み契機で、読込み位置ポインタRP(m−1)をインクリメントし、対応するバッファ面331から音声データ(10ms分のリニア音声データ)を供給することになる。読込み位置ポインタRP(m−1)は、バッファ面331の面数(最大数)と同じ8(=Z)となった次の読込み契機では、1に設定されることになる。

0068

ここでは、メディア処理スレッド30−(m+1)は、メディア処理スレッド30−30−(m)、30−(m−1)と同様に、10msごとに周期起動するものとする。しかし、ここでは、図8に示すように、メディア処理スレッド30−(m+1)が、メディア処理スレッド30−(m)のバッファ面331−5の音声データを読込む周期で、周期処理に時間がかかったものとする。さらに、ここでは、図8に示すように、メディア処理スレッド30−(m+1)において、バッファ面331−5、331−6、331−7、331−8を読込む周期で、起動周期の乱れが発生したとする。データ処理部11におけるソフトウェア(スレッド)での処理においては、例えばハードディスクへのデータ書込み待ちの発生などにより、通常よりも周期処理時聞が長くなり、起動周期が乱れることが有り得る。

0069

この場合、メディア処理スレッド30−(m+1)において、バッファ面331−5、331−6、331−7、331−8を読込む周期で、起動周期の乱れに伴いRTP送信処理遅延して揺らぎが生じるが、所望のミキシング処理を継続することが出来る。

0070

(A−3)第1の実施形態の効果
第1の実施形態によれば、以下のような効果を奏することができる。

0071

上述の通り、多地点音声ミキシング装置10では、M×N台の全ての端末20−1_1〜20−M_Nに対して、各送信先の端末20に係る音声データを除外した音声データを合成(ミキシング)したものを送信することができる。

0072

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

0073

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

0074

(B−1)第2の実施形態の構成
第2の実施形態の多地点音声ミキシング装置10の構成も上述の図1図7を用いて示すことができる。以下では、第2の実施形態の多地点音声ミキシング装置10について第1の実施形態との差異のみを説明する。

0075

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

0076

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

0077

(B−2)第2の実施形態の動作
次に、以上のような構成を有する第2の実施形態の多地点音声ミキシング装置10の動作(実施形態の音声処理方法)を説明する。

0078

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

0079

なお、図9に示す例では、メディア処理スレッド30を構成するバッファ面331の数は8個(すなわちZ=8)であるものとして図示している。

0080

図9(a)では、メディア処理スレッド30−(m)の周期処理タイミング、循環バッファ33−mの書込みタイミング、書込み位置ポインタWP(m)の変更タイミング及びポインタ値が図示されている、また、図9(b)では、メディア処理スレッド30−(m−1)の周期処理タイミング、循環バッファ33−(m−1)の読込みタイミング、読込み位置ポインタRP(m−1)の変更タイミング及びポインタ値が図示されている。さらに、図9(c)では、メディア処理スレッド30−(m+1)の周期処理タイミング、循環バッファ33−(m+1)の読込みタイミング、読込み位置ポインタRP(m+1)の変更タイミング及ポインタ値が図示されている。なお、図9(a)に示す書込み位置ポインタWPは、メディア処理スレッド30−(m)に属するポインタである。また、図9(b)に示す読込み位置ポインタRP(m−1)及び図9(c)に示す読込み位置ポインタRP(m+1)は、いずれもメディア処理スレッド30−(m)の読込み位置ポインタ群332に属するものである。

0081

図9では、メディア処理スレッド30−(m)からメディア処理スレッド30−(m−1)へのデータ受け渡し、及び、メディア処理スレッド30−(m)からメディア処理スレッド30−(m+1)へのデータ受け渡しについて説明しているが、メディア処理スレッド30−(m)からメディア処理スレッド30−1〜30−(m−2)および30−(m+2)〜30−Mへのデータ受渡しについても同様であるので、詳しい説明を省略する。

0082

メディア処理スレッド30−mは、例えば、10msごとに周期起動するが、バッファ面331−4を書込む周期で、周期処理に時間がかかり、バッファ面331−5、331−6、331−7、331−8、331−1を書込む周期で、起動周期の乱れが発生したとする。ソフトウェアでの処理においては、例えばハードディスクへのデータ書込み待ちの発生などにより、通常よりも周期処理時間が長くなり、起動周期が乱れることが有り得る。

0083

メディア処理スレッド30−(m−1)は、メディア処理スレッド30−mと同様に10msごとに周期起動し、起動周期の乱れが発生しなかったとする。すると、メディア処理スレッド30−(m−1)では、10msごとに循環バッファ33−mからの読込み契機が発生する。

0084

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

0085

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

0086

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

0087

(B−3)第2の実施形態の効果
第2の実施形態によれば、第1の実施形態の効果に加えて、以下のような効果を奏することができる。

0088

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

0089

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

0090

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

0091

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

0092

10…多地点音声ミキシング装置、11…データ処理部、111…プロセッサ、112…メモリ、12…通信部、40…ネットワーク、20、20−1_1〜20−M_N…端末、21…通話処理部、22…通信部、23…マイク、24…スピーカ、30、30−1〜30−M…メディア処理スレッド、31、31−1_1〜31−M_N…音声受信処理、311…RTP受信、312…ジッタバッファ、313…デコーダ、32、32−1〜32−M…加算処理、33、33−1〜33−M…循環バッファ、34、34−1〜34−M…加算処理34、35、35−1〜35−M…ミキサ、36、36−1_1〜36−M_N…音声送信処理、361…エンコーダ、362…RTP送信、331、331−1〜331−Z…バッファ面、332…読込み位置ポインタ群、333…書込み面選択手段、334…読込面選択手段、335…読込み位置ポインタ選択手段、351、351−1〜351−N…ミキサ部。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 大日本印刷株式会社の「 ネットワーク通信システム」が 公開されました。( 2020/10/29)

    【課題・解決手段】接続仲介処理の負荷を軽減しつつ、端末間の直接通信に問題がある場合にも支障なく通信を行う。予め各端末(203A,203B)が利用するルータのNATタイプを確認し、これを接続仲介装置(1... 詳細

  • アルパイン株式会社の「 オーディオ装置」が 公開されました。( 2020/10/29)

    【課題】 ミュート回路による暗電流を抑制しつつミュート回路を迅速に起動することができるオーディオ装置を提供する。【解決手段】 本発明のオーディオ装置は、オーディオ信号を生成するオーディオソースと、... 詳細

  • シャープ株式会社の「 音声処理装置及び音声処理方法」が 公開されました。( 2020/10/29)

    【課題】複数のユーザにより利用される音声処理装置において、発話者の音声を適切に取得すること。【解決手段】音声処理装置は、マイクにより集音される音声を受け付ける音声受付部と、撮像部により撮像される撮像画... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ