JP2014059606A

JP2014059606A - 信号処理システムおよびプログラム

Info

Publication number: JP2014059606A
Application number: JP2012202797A
Authority: JP
Inventors: Akihiro Miwa; 明宏三輪
Original assignee: Yamaha Corp
Current assignee: Yamaha Corp
Priority date: 2012-09-14
Filing date: 2012-09-14
Publication date: 2014-04-03
Also published as: US20150186108A1; WO2014042122A1; EP2897050A1; CN104718535A; EP2897050A4

Abstract

【課題】リアルタイム用途の音声信号処理を汎用のＰＣで動作するアプリケーションで実行する場合においても、ノイズを極力生じさせない。
【解決手段】入出力機器（Ｉ／Ｏ）１３から音声データを受け取ると、受け取った音声データをＰＣ１０（第１処理エンジン）およびＰＣ１１（第２処理エンジン）に並列に伝送する。ＰＣ１０では第１処理エンジンが信号処理を行うと共に、ＰＣ１１では第２処理エンジン信号処理を行い、信号処理した音声データをネットワークＳＷ１２に返すようになる。ネットワークＳＷ１２は、ＰＣ１０およびＰＣ１１から受け取った音声データが正常であるか否かを判定し、正常であると判定された音声データを、選択的に入出力機器１３へ転送する。
【選択図】図１

Description

この発明は、リアルタイム用途の信号処理において、ノイズの発生を抑えることができる信号処理システムおよびプログラムに関する。

最近、ＣＰＵ（Central Processing Unit：中央処理装置）やソフトウェアの性能向上により、汎用のパーソナルコンピュータ（ＰＣ）で動作するWindows（登録商標）等の汎用オペレーションシステム（ＯＳ）上のアプリケーションソフトウェアにて、音声信号処理を行えるようになってきている（非特許文献１参照）。

Steinberg Media Technologies GmbH 「cubase/details」，［online］, ［平成２４年９月９日検索］，インターネット<http://japan.steinberg.net/jp/products/cubase/details.html>

リアルタイム用途の音声信号の信号処理においては、信号処理がその信号を出力すべきタイミングに間に合わないと音声信号が不連続となってノイズとなる。そのため、音声信号処理には安定性や継続性が求められる。リアルタイム用途の信号処理を汎用のＰＣで動作するソフトウェアで実行する場合は、各種割込処理が信号処理とは無関係に発生するため、その信号処理は、通常のＰＣの使用状態であれば問題が生じない程度のレイテンシと処理負荷に抑える必要がある。しかしながら、割込処理や他のプロセスの処理負荷の関係で、上位である信号処理ソフトウェアの処理が待機され、信号処理に無視できない遅延が生じる場合がある。この際、ソフトウェアで実行されている信号処理が、その信号を出力すべきタイミングまでに完了しない場合には、信号が不連続となりノイズの原因となると云う問題点があった。
そこで、本発明は、リアルタイム用途の音声信号処理を汎用のＰＣで動作するソフトウェアで実行する場合においても、ノイズが極力生じることのない信号処理システムおよびプログラムを提供することを目的としている。

上記目的を達成するために、本発明の信号処理システムは、複数の信号処理エンジンに出力装置が接続されている信号処理システムにおいて、前記各信号処理エンジンは、前記各信号処理エンジンに並列に送られた同一の信号に信号処理を施して出力装置に出力する際に、正常に信号処理が完了したか否かを示す情報を付加し、前記出力装置は、前記各信号処理エンジンから受け取った信号データのうち、正常に処理が完了したことを示す前記情報が付加された信号データを選択的に使用するようにしたことを最も主要な特徴としている。

本発明は、信号処理エンジンを冗長化（多重化）し、出力装置にて“正常に処理が完了した信号データ”を出力するようにしている。これにより、リアルタイム用途の信号処理において、ノイズの発生を抑えることができ、信頼性を向上させることができる。すなわち、割込み処理等に起因する、信号処理には関係の無い処理負荷が、複数の信号処理エンジンで同時に発生する可能性が低いことから、いずれかの信号処理エンジンの信号処理が間に合えばノイズは発生しないようになる。
また、信号処理エンジンを冗長化しているため、例えば１つの信号処理エンジンが一時的あるいは恒常的に機能停止したとしても、信号処理動作を継続することができ、可用性（障害耐性）も向上するようになる。
さらに、外部からは出力装置に対してアクセスすることになり、見掛け上１つの信号処理エンジンとして利用できる。

本発明の実施例の信号処理システムの構成を示すブロック図である。本発明にかかる信号処理システムにおけるＰＣのハードウェア構成を示すブロック図である。本発明にかかる信号処理システムにおけるパケットのデータ構造を示す図である。本発明にかかる信号処理システムの動作を示すシーケンス図である。

本発明の実施例の信号処理システムの構成を示すブロック図を図１に示す。
図１に示す信号処理システム１は、第１信号処理エンジンとして機能している汎用のパーソナルコンピュータ（ＰＣ）１０と、第２信号処理エンジンとして機能している汎用のパーソナルコンピュータ（ＰＣ）１１と、この２台のＰＣ１０，１１とレコーダ等の入出力機器１３との間に配置されたネットワークＳＷ１２とから構成されている。２台のＰＣ１０，１１と、ネットワークＳＷ１２と、入出力機器１３とは、例えばEthernet（登録商標）などの通信ネットワークで接続されている。そして、２台のＰＣ１０，１１と、ネットワークＳＷ１２と、入出力機器１３とには、オーディオパケットをリアルタイムで伝送可能なオーディオＩ／Ｏの機能を有するネットワークオーディオカード１０ａ，１１ａ，１２ａ，１３ａがそれぞれ設けられており、相互に任意の通信プロトコル（例えば、Dante, Cobranet, EtherSound等）に従った信号データの授受をすることができる。この場合、少なくとも各ＰＣ１０，１１（第１信号処理エンジンおよび第２信号処理エンジン）とネットワークＳＷ１２とは、信号データ授受を管理・制御するためのクロックおよびタイムスタンプが同期している。具体的には、ネットワークオーディオカード１０ａ，１１ａとネットワークオーディオカード１２ａとのクロックが同期している。なお、この実施例においては、ネットワークオーディオカード１２ａは、３つ以上の入出力ポートを有しているものとする。また、第１信号処理エンジンおよび第２信号処理エンジンは、ＰＣ１０，１１で動作するWindows（登録商標）等の汎用オペレーションシステム（ＯＳ）上で実行されるソフトウェアである。

ＰＣ１０とＰＣ１１のハードウェア構成は同じ構成とされており、代表としてＰＣ１０のハードウェア構成を図２に示す。
図２に示すようにＰＣ１０は、ＣＰＵ（Central Processing Unit）２０でWindows（登録商標）等の汎用オペレーションシステム（ＯＳ）が実行されており、このＯＳ上において信号処理エンジンのソフトウェアを実行することができる。信号処理エンジンのソフトウェアが実行されると、ＰＣ１０は信号処理エンジンとして機能するようになる。メモリ２１は、ＲＡＭ／ＲＯＭ／ＨＤＤ／フラッシュメモリ等の各種記憶デバイスを適宜採用することができ、ＯＳおよび信号処理エンジン等のソフトウェアや他のアプリケーションソフトウェア、ネットワークオーディオカード１０ａを介してオーディオデータの送受信を行うためのオーディオドライバ等の各種ソフトウェアや、各種設定データ，ファイルを記憶している。また、メモリ２１には信号処理やデータ伝送のための一時記憶領域とされる記憶領域が設定されている。オーディオＩ／Ｏ２２は、オーディオ伝送のための機能を備えたネットワークオーディオカード１０ａで実現されており、ＰＣ１１、ネットワークＳＷ１２、入出力機器１３が接続されている通信ネットワーク２５に接続されている。オーディオＩ／Ｏ２２は、設定されたサンプリング周期やフレームサイズに応じた時間間隔で周期的にＣＰＵ２０に対して割込みをかけ、通信ネットワーク２５に接続されている他のオーディオ用の機器と音声信号データの入出力をリアルタイムで行うようにしている。この実施例では、オーディオＩ／Ｏ２２はＰＣ１０の備えるクロック（不図示）とは独立した独自のクロック発振源を有しており、当該クロック発振源のクロックは他の装置のオーディオＩ／Ｏ２２のクロックと同期しているものとする。その他２３は、マウス，キーボード，モニタ等やＵＳＢ等のその他の通信デバイス等であり、ＰＣ１０の目的・仕様・機能に応じて適宜設けられている。各部はバス２４を介してデータの授受を行っている。
ネットワークＳＷ１２のハードウェア構成は、図２に示すＰＣ１０のハードウェア構成と同様とされているので、その説明は省略するが、ネットワークＳＷ１２のハードウェア構成においては、メモリ２１にはネットワークＳＷプログラムや後述する判定のためのプログラムが記憶されると共に、一時記憶領域が設定されている。また、ネットワークＳＷ１２のオーディオＩ／Ｏ２２は通信ネットワークに接続されるが、複数の入出力ポートを有している。

オーディオＩ／Ｏ２２から通信ネットワーク２５に伝送される音声データはパケットで伝送される。図３にパケットのデータ構造を示す。
図３に示すように、パケット３０は、例えばＴＣＰ（Transmission Control Protocol）パケットやＵＤＰ（User Datagram Protocol）パケットとされ、ヘッダ３０ａとデータ部３０ｂとから構成されている。パケット３０におけるヘッダ３０ａは、送信元および送信先の情報やデータ部３０ｂの属性情報などからなり、データ部３０ｂは、音声データの通信プロトコルに従った音声データとされる。この音声データは、例えば１サンプルのデータ長が３２ｂｉｔとされ、サンプリング周波数が４４．１ｋＨｚとされる。ここでは、１パケットに格納される音声データのサイズは、第１信号処理エンジン，第２信号処理エンジンやオーディオＩ／Ｏ２２におけるフレームサイズ（例えば１２８サンプル）と同じとされている。なお、パケットは通信ネットワーク２５を介して伝送されるが、その伝送遅延は、以下の説明では無視できるものとしている。

次に、本発明の信号処理システム１における音声データの１サイクルの流れを図４に示すシーケンス図を参照しながら説明する。
本発明の信号処理システム１においては、少なくとも、ＰＣ１０（第１処理エンジン）およびＰＣ１１（第２処理エンジン）にそれぞれ備えられているオーディオＩ／Ｏ２２は、ネットワークＳＷ１２に備えられているオーディオＩ／Ｏとクロック同期している。ネットワークＳＷ１２は、通信ネットワーク２５を介して接続されている入出力機器（Ｉ／Ｏ）１３からパケット化された１フレームサイズ分の音声データを受け取る（ステップＳ１０）と、受け取った音声データのパケットをＰＣ１０（第１処理エンジン）およびＰＣ１１（第２処理エンジン）に並列に伝送する（ステップＳ１１，Ｓ１２）。この場合、同じオーディオデータがＰＣ１０とＰＣ１１のそれぞれのオーディオＩ／Ｏ２２に並行して送られるようになる。ＰＣ１０（第１処理エンジン）およびＰＣ１１（第２処理エンジン）とが、ネットワークＳＷ１２から受け取った音声データに対してそれぞれ実行する信号処理は、同一の処理内容に予め設定・構成されているものとする。ＰＣ１０（第１処理エンジン）およびＰＣ１１（第２処理エンジン）とネットワークＳＷ１２はクロック同期しているので、各ＰＣ１０（第１処理エンジン）およびＰＣ１１（第２処理エンジン）は、ほぼ同じタイミングで、ネットワークＳＷ１２からの音声データ受取り、ＰＣ１０の第１処理エンジンでの信号処理、ＰＣ１１の第２処理エンジンでの信号処理、信号処理された音声データのネットワークＳＷ１２への送出等の各種処理が行われるようになる（ステップＳ１３，Ｓ１４）。ただし、第１処理エンジンと第２処理エンジンはいずれも汎用ＯＳ上で実行されるソフトウェアであり、それぞれが動作するＰＣ１０あるいはＰＣ１１にて発生する各種割込処理や他のプロセスの処理負荷の状況等により、信号処理が完了するタイミングやネットワークＳＷ１２への送出タイミング等は必ずしも一致しない。また、汎用ＯＳは、その設計あるいは構造上レイテンシの保証が無い（あるいはレイテンシの保証が困難）ことから、上記各種割込処理や他のプロセスの処理負荷の状況次第では第１処理エンジンや第２処理エンジンでの信号処理に無視できない遅延が生じる場合がある。ネットワークＳＷ１２は、ＰＣ１０（第１処理エンジン）およびＰＣ１１（第２処理エンジン）から受け取った音声データが正常であるか否かを判定し、正常であると判定された１フレーム分の音声データ（パケット）を選択的に入出力機器１３へ転送する（ステップＳ１５）。
割込み処理等に起因する信号処理には関係の無い処理負荷が、第１信号処理エンジンが動作するＰＣ１０および第２信号処理エンジンが動作するＰＣ１１で同時に発生する可能性が低いことから、複数の信号処理エンジンにて並行して信号処理を行い、そのうち正常であると判定された音声データを選択的に入出力装置１３へ転送することにより、いずれかの信号処理エンジンの信号処理が間に合えばノイズの発生を防止することができるようになる。また、信号処理エンジンを冗長化しているため、例えば１つの信号処理エンジンが一時的あるいは恒常的に不安定化あるいは機能停止したとしても、信号処理動作を継続することができ、可用性（障害耐性）も向上するようになる。さらに、入出力機器１３からは単一のネットワークＳＷ１２に対してアクセスすることから、入出力機器１３からは見掛け上１つの信号処理エンジンとして利用できる。
上記したＰＣ１０（第１処理エンジン）およびＰＣ１１（第２処理エンジン）の信号送受信に関する動作、および、ネットワークＳＷ１２の信号送受信ないし転送処理の動作は同期したクロックに従い周期的に行われている。

ＰＣ１０，ＰＣ１１における「処理」と「応答」についてさらに説明する。それぞれのオーディオＩ／Ｏ２２は自身のクロック発振源が生成するクロックに従い周期的にＣＰＵ２０に割込みをかける。これに応じて、ＣＰＵ２０で実行されているオーディオドライバは、オーディオＩ／Ｏ２２にて受信されている音声データを取り込んで第１信号処理エンジン、第２信号処理エンジンに渡す処理や、第１信号処理エンジン、第２信号処理エンジンから信号処理した音声データを取得しオーディオＩ／Ｏ２２から送信する処理を行う。ＰＣ１０，１１におけるＣＰＵ２０で実行されるソフトウェアである第１信号処理エンジン、第２信号処理エンジンは、渡された音声データに対してフィルタ処理，ＥＱ処理，ミキシング処理等の各種信号処理を施して、オーディオドライバに返す。オーディオドライバは“処理完了フラグ”を持っており、オーディオドライバは、１の割込みに応じた信号データが次の割込みのタイミングより前に第１信号処理エンジン、第２信号処理エンジンから取得できたとき、すなわち、正常状態の場合（間に合っている場合）は、処理完了フラグを“０”に、取得できなかった場合（間に合わなかった場合）は処理完了フラグを“１”にセットする。また、オーディオドライバは、第１信号処理エンジン、第２信号処理エンジンにおける信号処理が間に合えばその信号処理後の音声データを、間に合わなかった場合は出力すべき音声データが無いことから、ダミーデータをネットワークＳＷ１２に返す処理を行う。この場合、間に合わなくても、ともかく所定のタイミングで音声データを返すが、返すダミーデータは、例えばオール“０”のデータや受信したデータそのもの等とされる。

ネットワークＳＷ１２のオーディオＩ／Ｏ２２の動作についてさらに説明する。ネットワークＳＷ１２のオーディオＩ／Ｏ２２は、複数の入出力ポートを有しており、各入出力ポートに何が接続されているかを認識している。図１に示す信号処理システム１では、第１信号処理エンジンが動いているＰＣ１０および第２信号処理エンジンが動いているＰＣ１１と、レコーダ等の入出力機器（Ｉ／Ｏ）１３とが、各入出力ポートに接続されていることを認識している。そして、オーディオＩ／Ｏ２２は周期的にネットワークＳＷ１２のＣＰＵ２０に割込みをかける。これに応じて、ネットワークＳＷ１２のＣＰＵ２０は、入出力機器１３が接続されている入出力ポートから受け取った１フレームの音声データ（パケット）を第１信号処理エンジンのＰＣ１０が接続されている入出力ポートと、第２信号処理エンジンのＰＣ１１が接続されている入出力ポートとに並列して伝送する。また、第１信号処理エンジンのＰＣ１０が接続されている入出力ポート、第２信号処理エンジンのＰＣ１１が接続されている入出力ポートから戻ってきた音声データが正常であるか否かを判定し、正常であると判定された音声データを選択的に入出力機器１３へ転送する。

ここで、第１信号処理エンジンと第２信号処理エンジンとからいずれも正常な（間に合った）パケットが伝送されて来なかった場合は、出力すべき音声データが無いことから、ネットワークＳＷ１２はダミーデータを入出力機器１３に送る。このダミーデータは、例えばオール“０”のデータや受信したデータそのもの等とされる。
ネットワークＳＷ１２における「判定」のポリシーには次に述べる先着優先と後着優先とがあり、いずれでも採用することが可能とされている。
（１）先着優先
パケットを受信する毎に逐次判定を行い、正常と判定された音声データのパケットを直ちに転送する。以降は、他の信号処理エンジンから受信する（同タイミングの）音声データのパケットは破棄する（受け取っても転送はしない）。
（２）後着優先
全ての信号処理エンジン（ＰＣ）から音声データのパケットを受信した時点で、各パケットを判定し、正常と判定された音声データのパケットを転送する。正常と判定されたパケットが複数ある場合は、先着順あるいは予め設定された優先順位で採用された音声データのパケットを転送する。

上記した処理完了フラグはパケット３０のヘッダ３０ａに添付して伝送することができる。この場合は、第１信号処理エンジンのＰＣ１０および第２信号処理エンジンのＰＣ１１の各オーディオＩ／Ｏ２２はオーディオドライバから音声データとともに“処理完了フラグ”を取得する。“処理完了フラグ”を取得したオーディオＩ／Ｏは、パケット３０のヘッダ３０ａ中の所定位置に処理完了フラグを添付してネットワークＳＷ１２に音声データのパケット３０を送る。なお、ここで言うヘッダとは、データ部３０ｂの音声データ本体より前に記述されている情報を指しており、ＴＣＰヘッダやＵＤＰヘッダに限らず、音声データの通信プロトコルにて規定されているデータヘッダも含む。
そして、ネットワークＳＷ１２は受け取ったパケット３０のヘッダ３０ａを解析し、受け取ったパケットが正常の処理が出来ていた音声データを含むものか否かを判別する。ヘッダの解析では、処理完了フラグはヘッダの所定位置に格納されていることから、当該所定位置の情報が“０”か“１”かを検出することで、パケットが正常の処理が出来ていた音声データを含むものか否かを判別することができる。ネットワークＳＷ１２は、第１信号処理エンジンのＰＣ１０および第２信号処理エンジンのＰＣ１１のから受け取った音声データのパケット３０のうちの正常を示す処理完了フラグが付された音声データのパケット３０を、選択的に入出力機器１３へ送る。

また、処理完了フラグは伝送する音声データを利用して伝送することができる。この場合は、第１信号処理エンジンのＰＣ１０および第２信号処理エンジンのＰＣ１１のオーディオドライバは、“間に合わなかった”場合、伝送する音声データのサンプルの最下位ビットを“１”にする。例えば、サンプルのビット数が３２ｂｉｔの場合は、３１ｂｉｔを本来の音声データに、最下位の１ｂｉｔを処理完了フラグとして使う。この場合、最下位の１ｂｉｔを処理完了フラグとして使うのは、全サンプルデータでも良いし、一部の（例えば、先頭の）サンプルデータのみの最下位の１ｂｉｔを処理完了フラグとして用い、他のサンプルデータは３２ｂｉｔの全てを音声データとしてもよい。
そして、ネットワークＳＷ１２は、受け取ったパケット３０のデータ部３０ｂを解析し、受け取ったパケット３０が正常の処理が出来ていた音声データを含むものか否かを判別する。次いで、ネットワークＳＷ１２は、第１信号処理エンジンのＰＣ１０および第２信号処理エンジンのＰＣ１１から受け取った音声データのパケット３０のうちの正常を示す処理完了フラグが付された音声データのパケット３０を、選択的に入出力機器１３へ送る。

以上説明した本発明の信号処理システムにおいては、第１信号処理エンジンと第２信号処理エンジンの２台としたが、これに限ることはなく信号処理エンジンは３台以上を用意しても良い。また、ＰＣやネットワークＳＷやその他の装置は、それぞれ仮想マシンであってもよい。例えば、信号処理エンジンを、１台のＰＣを仮想化して構築した複数の仮想ＰＣでそれぞれ動作させてもよい。あるいは各ＰＣを、複数の物理的なコンピュータ装置にて提供される仮想サーバ上に構築して、各仮想サーバにて信号処理エンジンを動作させてもよい。
また、本発明にかかる通信ネットワークの伝送路も物理的なケーブルで接続された伝送路に限らず、仮想化された伝送路であってよい。例えば、複数の仮想ＰＣ間での物理メモリを介したデータ転送等の仮想伝送路であってもよい。さらに、１パケットのフレームサイズを、信号処理エンジンやオーディオＩ／Ｏにおけるフレームサイズとは独立に設定してよい。例えば、１パケットのフレームサイズを８サンプルとし、信号処理エンジンあるいはオーディオＩ／Ｏのフレームサイズを１２８サンプル等としてもよい。

以上説明した本発明の信号処理システムでは、オーディオＩ／Ｏが周期的にＣＰＵに割込みをかける例を示したが、これに限らず、ＣＰＵがオーディオＩ／Ｏの状態をポーリングしてもよい。また、信号処理が間に合ったかどうかの判定や音声データのパケットに処理完了フラグを添付させる処理等をＰＣのＣＰＵで行う例を示したが、これに限らず、その一部あるいはすべての処理をオーディオＩ／Ｏにて行っても良い。あるいは、ＰＣのＣＰＵとオーディオＩ／ＯのＣＰＵとの両方で処理させてもよい。このようにすると、ＰＣのＣＰＵがハングアップした場合でも、オーディオＩ／Ｏ側で一部あるいは全ての処理が行えるようになる。
また、本発明の信号処理システムでは、通信ネットワークの伝送遅延は、無視できるものとしたが、通信ネットワークの伝送遅延を考慮する場合は、例えば、パケットに付加されているタイムスタンプをみて、同じタイムスタンプのついているパケットについて、以上説明したパケットの判定および選択する処理を行うようにしてもよい。なお、本発明の信号処理システムで採用することのできるオーディオ伝送プロトコルでは、多くの場合、伝送するオーディオデータを含むパケット等にはタイムスタンプが付加されており、これを用いることができる。
さらに、本発明の信号処理システムでは、Ethernet 、および、Ethernet を介してデータの伝送を行う通信プロトコルを前提としたが、通信規格やプロトコルはこれに限ることはなく、S/PDIF（Sony Philips Digital Interface）や AES/EBU（Audio Engineering Society/European Broadcasting Union ）等、他の通信規格やプロトコルを用いることができる。データの伝送路は電気的に信号を伝達するケーブル線のほか、光ファイバあるいは無線を用いても良い。また、処理完了フラグを付加する単位をパケット単位としたが、これに限ることはなく、例えば、転送フレーム（例えばEthernetのフレーム）単位で処理完了フラグを付加してもよい。さらにまた、伝送する信号は音声データに限らず映像データであってもよく、リアルタイム用途の信号・データ伝送および処理を行うシステムであれば適用が可能である。

さらにまた、本発明の信号処理システムにおいては、ネットワークＳＷで行うとした“判定”を、例えば、レコーダ等の入出力機器において行っても良い。この場合は、ネットワークＳＷは汎用のネットワークスイッチとすることができ、レコーダ等の入出力機器が、直接複数の信号処理エンジン（ＰＣ）と音声データの授受を行うことになる。
さらにまた、本発明にかかるパケットに付加される処理完了フラグのバリエーションとして、次のような態様がある。
（１）音声サンプルデータの値をオール“０”等の所定のパターンのデータとすることで、“間に合っていない状態”を表現する。すなわち、間に合っていないときに伝送されるダミーデータ自体が、処理完了フラグとなる。
（２）音声データのサンプルをカットし、パケットのデータ部の本体データが“０”であることにより、“間に合っていない状態”を表現する。この場合は、ヘッダに記述されるパケットのデータ長がヘッダ分しかないことになる。すなわち、データ長が０であることが処理完了フラグとなる。
（３）ステガノグラフィな処理完了フラグを含む所定のコード情報を、音声データに埋め込む。この場合、埋め込むデータは１ビットのデータに限らず、処理完了フラグやその他の状態情報等を電子透かしとして埋め込むようにする。

さらにまた、本発明の信号処理システムでは、各パケットの処理完了フラグの状態やパケット自体の到達状況をモニタすることで各信号処理エンジンの動作状態を間接的にモニタすることができる。例えば、ある信号処理エンジン（ＰＣ）にて“間に合っていない状態”や、パケットを受信していない状態が継続するような場合（例えば１分以上）、その信号処理エンジンは何らかのトラブルや設定ミス等が発生している可能性が高いと判断できる。ネットワークＳＷがこういった状況をモニタし、必要に応じて警告等を行うようにしてもよい。

さらにまた、本発明の信号処理システムでは、伝送される音声データはデジタル信号であり、パケット転送されるものとして説明したが、アナログ信号であってもよい。この場合、ＰＣやネットワークＳＷや入出力機器間は単方向通信を行う伝送路にて各双方向の接続を行う。処理完了フラグは本出願人が提案する国際公開第2010/016589号パンフレットに記載したような音響透かしとして所定の時間間隔（例えば１０ｍｓ）を単位としてアナログ音響信号に重畳し、各装置ではこれの符号化・復号化を行うようにすればよい。ネットワークＳＷ１２は、アナログ音響信号から音響透かしとして付加された処理完了フラグを復号（抽出）し、これに基づきＰＣ１０からのアナログ音響信号とＰＣ１１からのアナログ音響信号とを択一的に出力する信号選択スイッチとして構成すればよい。

１信号処理システム、１０，１１ＰＣ、１０ａ，１１ａ，１２ａ，１３ａネットワークオーディオカード、１２ネットワークＳＷ、１３入出力機器、２０ＣＰＵ、２１メモリ、２２オーディオＩ／Ｏ、２３その他、２４バス、２５通信ネットワーク、３０パケット、３０ａヘッダ、３０ｂデータ部

Claims

複数の信号処理エンジンに出力装置が接続されている信号処理システムにおいて、
前記各信号処理エンジンは、前記各信号処理エンジンに並列に送られた同一の信号に信号処理を施して出力装置に出力する際に、正常に信号処理が完了したか否かを示す情報を付加し、前記出力装置は、前記各信号処理エンジンから受け取った信号データのうち、正常に処理が完了したことを示す前記情報が付加された信号データを選択的に使用することを特徴とする信号処理システム。
前記各信号処理エンジンと前記出力装置とは、相互に通信ネットワークで接続されており、前記出力装置はネットワークスイッチとされて、前記各信号処理エンジンから受け取った信号データのうち正常に処理が完了したことを示す前記情報が付された信号データを、選択的に他の装置へ転送することを特徴とする請求項１記載の信号処理システム。
前記出力装置は、前記複数の信号処理エンジンから前記信号データを受け取り、該受け取った信号データそれぞれに付加された情報に基づき、各信号データが正常なものかどうかを判定して、正常と判定された信号データを出力することを特徴とする請求項１または２記載の信号処理システム。
前記信号処理エンジンは、周期的に信号処理を行うとともに信号処理を行った信号データを出力しており、信号処理が正常に完了したか否かを判定して、その判定結果を出力する信号データに付加することを特徴とする請求項１ないし３のいずれかに記載の信号処理システム。
複数の信号処理エンジンと出力装置とが接続された信号処理システムにおける前記出力装置として機能しているコンピュータに、
前記複数の信号処理エンジンから前記信号データを受け取る受け取りステップと、
該受け取りステップで受け取った信号データそれぞれに付加された情報に基づき、各信号データが正常なものかどうかを判定する判定ステップと、
該判定ステップにおいて、正常と判定された信号データを選択的に使用するステップと、
を実行させることを特徴とするプログラム。
複数の信号処理エンジンと出力装置とが接続された信号処理システムにおける前記信号処理エンジンとして機能しているコンピュータに、
周期的に信号処理を行う信号処理ステップと、
該信号処理ステップにおいて、信号処理が正常に完了したか否かを判定して、その判定結果を信号データに付加する判定ステップと、
該判定ステップにおいて前記判定結果が付加された信号データを出力する出力ステップと、
を実行させることを特徴とするプログラム。