JP5125457B2 - 制御装置、音響信号処理システムおよび音響信号処理装置並びに制御用プログラム - Google Patents

Description

この発明は、プログラム可能な複数の信号処理部を備える音響信号処理装置、音響信号処理装置における信号処理の構成を設定する制御装置および制御用プログラム、音響信号処理装置および制御装置を備える音響信号処理システムに関する。

従来から、プログラムに従って動作可能なＤＳＰ（Digital Signal Processor）を用いて音響信号処理装置を構成すると共に、音響信号処理装置に接続されているＰＣ（パーソナルコンピュータ）において制御用プログラムを実行させることにより制御装置として機能させ、制御装置により設定した信号処理構成に基づいて、音響信号処理装置が音響信号を処理できるようにした音響信号処理システムが知られている。このような、音響信号処理システムの概要の構成を図１６に示す。図１６において、ＤＭＥ１０１は複数のＤＳＰを備える音響信号処理装置であり、ＤＭＥ１０１に通信インタフェースを介して接続されているパーソナルコンピュータとされるＰＣ１００により信号処理構成を設定することができる。ＤＭＥ１０１は、ＰＣ１００により設定された信号処理構成に基づいて信号ソース１０２から入力された音響信号に音響処理を施して図示しないアンプを介してスピーカ（ＳＰ）１０３に音響信号を出力することができる。

ＰＣ１００においてＤＭＥ１０１における信号処理構成を設定する際には、制御用プログラムを起動させて表示手段に図１７に示すＣＡＤ１１０のＣＡＤ（computer-aided design）画面を表示させる。ＣＡＤ１１０の画面には、異なる機能を有する複数の構成要素（以下、「コンポーネント」という）の組み合わせからなるＤＭＥ１０１における信号処理構成の一例が示されている。ＣＡＤ１１０の画面に表示されているような信号処理構成を設定する際には、図示しないウィンドウに予め用意されているコンポーネントのリストから、使用するコンポーネントをＣＡＤ１００の画面上にドラッグ＆ドロップして所定位置に配置し、配置されたコンポーネントの入出力間の結線を行うことにより、図１７に示すような信号処理構成を設定することができる。設定された信号処理構成を示すコンフィグデータはＰＣ１００上に記憶することができると共に、ＤＭＥ１０１に送ることができる。
「DIGITAL MIXING ENGINE DME64N/DME24N 取扱説明書」，ヤマハ株式会社，２００４年 特開２００５−２３４８０１ 特開２００５−２５２６８６

ＤＭＥ１０１においては、信号処理構成に使用している各コンポーネントのリソースを、備えられている複数のＤＳＰにそれぞれ割り当てることにより、信号処理を行えるようになる。この場合、ＤＳＰにおいては実行できるステップ数が例えば１０２４ステップ等の限りがあることから、信号処理構成に使用している各コンポーネントのリソースをどのＤＳＰにどの順番で割り当てるかを決める処理を行うことにより、複数のＤＳＰに各コンポーネントのリソースをそれぞれ割り当てるようにしている。この処理を以下ではコンパイルと云うことにし、コンフィグデータをコンパイルすることによりコンパイル結果ファイルが生成される。コンフィグデータのコンパイルは、ＰＣ１００において実行されてコンパイル結果ファイルがＤＭＥ１０１に送られるようになる。ＤＭＥ１０１は、ＰＣ１００から送られたコンパイル結果ファイルの内容に基づいて各ＤＳＰのマイクロプログラムを生成し、生成したマイクロプログラムを各ＤＳＰが実行することにより、ＰＣ１００により設定された信号処理構成がＤＭＥ１０１において実現される。これにより、ＤＭＥ１０１に入力された音響信号に設定された信号処理構成による信号処理が施されてＤＭＥ１０１から出力されるようになる。

従来のコンパイルでは、通常アルゴリズムに基づいてコンパイルされる。通常アルゴリズムでは、コンフィグで使用される各コンポーネントのリソースを予め想定された割当パターンにより複数の信号処理部へ割り当てるようにする。想定される代表的な割当パターンとしては、
１．コンフィグにおける複数の入力スロット（Input）のコンポーネントに、それぞれ均等に他のコンポーネントが割り当てられる事を想定して、複数の入力スロットを複数のＤＳＰへ分散配置させ、入力スロットから結線をたどってコンポーネントを探索し、探索されたコンポーネントのリソースを各々のＤＳＰがいっぱいになるまでアサインし、あふれたら別のＤＳＰにアサインする割当パターン
２．入出力端子数が32in32outのように入出力端子数の多いコンポーネントを優先的にＤＳＰにアサインする割当パターン
３．コンポーネントの識別番号（ＩＤ）順に、１つ目のＤＳＰからコンポーネントをアサインする割当パターン
などの割当パターンとされる。

従来の通常アルゴリズムによるコンパイル処理のフローチャートを図１８に示す。
ＰＣ１００において設定されたコンフィグデータをコンパイルする指示がされた際に、コンパイル処理が起動されステップＳ１００において想定している全ての割当パターンを試したか否かが判断される。初回においては全ての割当パターンを試していないことからステップＳ１０１に進み想定した最初の割当パターンを用いた通常アルゴリズムによるコンパイルが行われる。次いで、ステップＳ１０２にてコンパイルできたか否かが判断される。ここで、コンフィグで使用される全てのコンポーネントのリソースをＤＳＰに割り当てることができた場合は、コンパイルできたと判断されてステップＳ１０３に進み、各コンポーネントをいずれかのＤＳＰに割り当てた情報からなるコンパイル結果ファイルが作成されてコンパイルは終了する。作成されたコンパイル結果ファイルを備えられた記憶手段に保存することができる。

また、コンフィグにおける全てのコンポーネントのリソースをＤＳＰに割り当てることができず、ステップＳ１０２においてコンパイルできなかったと判断された場合は、ステップＳ１００に分岐して戻り、ステップＳ１００およびステップＳ１０１において次の割当パターンを用いた通常アルゴリズムによるコンパイルが行われる。このような処理が、ステップＳ１０２においてコンパイルできたと判断されるまで繰り返し行われる。そして、コンパイルできたと判断されるとステップＳ１０３に進み、コンパイル結果ファイルが作成されてコンパイルは終了する。また、全ての割当パターンを試してもステップＳ１０２においてコンパイルできたと判断されない場合は、ステップＳ１００において全ての割当パターンを試したと判断されてステップＳ１０４に分岐し、コンパイルが失敗したことがユーザに通知されコンパイルは終了する。このユーザーへの通知は、表示画面にメッセージ等を表示することにより行われる。なお、コンパイル結果のファイルが作成された場合は、当該ファイルがＤＭＥ１０１に送信される。しかし、コンパイルが失敗した場合はＤＭＥ１０１にはコンパイル結果ファイルが送られず、ＤＭＥ１０１では信号処理を行うことができないことになる。

従来の通常アルゴリズムによるコンパイルでは、コンフィグにおける全てのコンポーネントのリソース量が複数のＤＳＰに割り当てられるリソース量の合計以内であっても、コンパイルできない場合があるという問題点があった。また、膨大なコンポーネントの数からなるコンフィグが設定された場合は、従来の通常アルゴリズムによるコンパイルでは、ほとんどコンパイルすることができないという問題があった。

そこで、本発明は、コンフィグにおける全てのコンポーネントのリソース量が少ない場合でも多い場合でも極力コンパイルできるようにした制御装置、音響信号処理システムおよび音響信号処理装置並びに制御用プログラムを提供することを目的としている。

上記目的を達成するために、本発明は、コンフィグで使用される各コンポーネントのリソースを予め想定された割当パターンにより複数の信号処理部へ割り当てる通常アルゴリズムと、該通常アルゴリズムによるコンパイルに失敗した場合に実行され、コンフィグで使用される各コンポーネントのリソースを複数の信号処理部へ最適化して割り当てる最適化アルゴリズムとを有し、設定されたコンフィグのコンフィグデータおよび複数の信号処理部のいずれに複数のコンポーネントのリソースをそれぞれ割り当てるかの割り当て情報が少なくとも含まれているプロジェクトファイルに、コンパイルに使用したアルゴリズムの種類およびパラメータ値を少なくとも含むコンパイル情報を記録するようにしたことを最も主要な特徴としている。

本発明によれば、予め想定されたコンポーネントの組み合わせのパターンに基づいてコンパイルを行う通常アルゴリズムによるコンパイルに失敗しても、コンフィグで使用される各コンポーネントのリソースを複数の信号処理部へ最適化して割り当てる最適化アルゴリズムによりコンパイルすることができることから、コンフィグにおける全てのコンポーネントのリソース量が少ない場合でも多い場合でも極力コンパイルすることができるようになる。

本発明の実施例にかかる音響信号処理装置（ＤＭＥ）１の構成を示すブロック図を図１に示す。
音響信号処理装置１は、ＣＰＵ１０，ＲＯＭ（Read Only Memory）１１，ＲＡＭ（Random Access Memory）１２，操作子１３，検出回路１４，表示器１５，表示回路１６，通信インタフェース（Ｉ／Ｆ）１７，音声インタフェース（Ｉ／Ｆ）１８，信号処理部（ＤＳＰ：Digital Signal Processor）２１を備え、これらが通信バス２２によって接続されている。音響信号処理装置１は、外部機器１８とされる制御装置から通信Ｉ／Ｆ１７を介して受信した後述するコンパイル結果ファイルの内容に従って、ＤＳＰ２１を制御するためのマイクロプログラムを生成し、そのマイクロプログラムに従ってＤＳＰ２１を動作させることにより、外部機器２０から音声Ｉ／Ｆ１９を介して入力される音響信号に対して種々の信号処理をＤＰ２１において施し、音声Ｉ／Ｆ１９を介して他の外部機器２０に出力する機能を有している。

ＣＰＵ１０は、音響信号処理装置１の全体を制御する制御手段であり、ＲＯＭ１１に記憶された制御用プログラムを実行することにより、表示器１５における表示を表示回路１６により制御したり、操作子１３の操作を検出回路１４により検出して、その操作に従ってパラメータの値を変更する処理を行う。さらに、制御装置から通信Ｉ／Ｆ１７を介して受信したコンパイル結果ファイルの内容に従って、ＤＳＰ２１を制御するためのマイクロプログラムを生成してＤＳＰ２１に設定する処理を行う。ＲＯＭ１１には、ＣＰＵ１０が実行する制御用プログラムや予め用意されているデータ等が記憶されている。このＲＯＭ１１をフラッシュメモリ等の書き換え可能なＲＯＭとすることで、制御用プログラムの書き換えを可能とすることができ、制御用プログラムのバージョンアップを容易に行うことができる。

ＲＡＭ１３には、ＣＰＵ１０のワークメモリや制御装置から受信した信号処理構成を示す情報等のデータを記憶する記憶エリアが設定されている。表示回路１６は、液晶ディスプレイ（ＬＣＤ）等からなる表示器１５に表示を行う表示回路である。検出回路１４は、キー、スイッチ、ロータリーエンコーダ等によって構成される操作子１３を走査することによって操作子１３のイベントを検出して、イベントのあった操作子１３に対応するイベント出力を出力している。操作子１３は、ユーザが音響信号処理装置１を直接操作してシーンの編集等を行うための操作子である。通信Ｉ／Ｆ１７は、外部機器１８として音響信号処理装置１を制御する制御装置を接続し通信を行うためのインタフェースであり、イーサネット（登録商標）などのネットワーク用のインタフェースとされている。音声Ｉ／Ｆ１９は、音響信号を出力したり入力する外部機器２０との間で音響信号を授受するためのネットワーク用のインタフェースである。ＤＳＰ２１は複数のプロセッサからなり、音声Ｉ／Ｆ１９を介して入力される音響信号に対し、複数のプロセッサのそれぞれに設定されているマイクロプログラム及びその処理パラメータに従った信号処理を施して、音声Ｉ／Ｆ１９を介して出力する信号処理部である。

本発明の実施例にかかる音響信号処理装置１を制御する制御装置２の構成を示すブロック図を図２に示す。
制御装置２は、音響信号処理装置１の信号処理構成を設定することができ、設定した信号処理構成を示す情報を音響信号処理装置１に送ることができる。図２に示す制御装置２はパーソナルコンピュータ（ＰＣ）と同様の構成とされており、ＣＰＵ（Central Processing Unit）２３は制御装置２の全体の動作を制御すると共に、制御用プログラム等の動作ソフトウェアを実行している。ＲＯＭ２５には、ＣＰＵ２３が実行する制御用プログラム等の動作ソフトウェアが格納されており、ＲＡＭ２４には、ＣＰＵ２３のワークエリアや設定した信号処理構成を示すコンフィグデータやコンフィグデータを含むプロジェクトファイル等を記憶する記憶エリアが設定されている。このＲＯＭ２５をフラッシュメモリ等の書き換え可能なＲＯＭとすることで、動作ソフトウェアの書き換えを可能とすることができ、制御用プログラムや動作ソフトウェアのバージョンアップを容易に行うことができる。なお、図示されていないがハードディスク装置等の大容量記憶装置を備えており大容量記憶装置にオペレーションシステム等の基本ソフトウェアやアプリケーション等のソフトウェアが記憶されている。

検出回路２７は、制御装置２に設けられているキーボードやマウス等の操作子２６を走査することによって操作子２６のイベントを検出して、イベントのあった操作子２６に対応するイベント出力を出力している。表示回路２９は、起動されたアプリケーションに応じたアプリケーション画面を液晶表示器（ＬＣＤ）等の表示器２８に表示させており、制御用プログラムが起動された際には信号処理構成を設定できる画面等のＣＡＤ画面が表示器２８に表示される。通信インターフェース（Ｉ／Ｆ）３０は、イーサネット（登録商標）等のネットワークのインタフェースでありネットワーク通信ケーブルを介してネットワーク上の外部機器３２とされる音響信号処理装置１等に接続可能とされている。制御装置２はネットワークに存在する外部機器３２と通信を行うことにより、制御装置２と外部機器３２との間で各種データの授受を行うことができる。これらの各部は通信バス３１に接続されて、通信バス３１を介してデータの授受を行っている。

次に、本発明の実施例にかかる音響信号処理システムの構成例を示すブロック図を図３に示す。図３においては、上記した音響信号処理装置を構成しているそれぞれのデバイスをＤＭＥとして表し、上記した制御装置をＰＣとして表している。
図３に示す音響信号処理システムはゾーンを１つだけ有しており、ＰＣ２と３台のＤＭＥ＃１、ＤＭＥ＃２、ＤＭＥ＃３が接続されているネットワークを備えている。このゾーンにはＤＭＥ＃１、ＤＭＥ＃２、ＤＭＥ＃３の３台が属しており、３台のＤＭＥ＃１〜＃３が１台の音響信号処理装置として動作することで、入力される音響信号に対して種々の信号処理が施されて出力されるようになる。ネットワークは、一般的に用いられているイーサネットにより構築されており、ＰＣ２と３台のＤＭＥ＃１〜＃３はネットワーク上のハブ３に接続されている。ＰＣ２には本発明の実施例にかかる制御用プログラムがインストールされており、ＰＣ２において制御用プログラムを起動することにより、３台のＤＭＥ＃１〜＃３からなる音響信号処理装置における信号処理構成、すなわちコンフィグレーション（以下、「コンフィグ」という。）の設定をすることができる。この設定は、ＰＣ２の表示器２８に表示されたコンフィグ設定のＣＡＤ画面において行われ、３台のＤＭＥ＃１〜＃３からなる音響信号処理装置のコンフィグが作成されるようになる。

次に、本発明の実施例にかかる音響信号処理システムの他の構成例を示すブロック図を図４に示す。図４においても、上記した音響信号処理装置を構成しているそれぞれのデバイスをＤＭＥとして表し、上記した制御装置をＰＣとして表している。
図４に示す音響信号処理システムは、ネットワークに接続されたＰＣ２と３つのゾーンとを備えている。第１のゾーン（Ｚｏｎｅ１）では、ルータ４に接続されているハブ３ａにＤＭＥ＃１−１、ＤＭＥ＃１−２、ＤＭＥ＃１−３が接続されて第１のゾーンの音響信号処理装置が構成され、第２のゾーン（Ｚｏｎｅ２）では、ルータ４に接続されているハブ３ｂにＤＭＥ＃２−１、ＤＭＥ＃２−２が接続されて第２のゾーンの音響信号処理装置が構成され、第３のゾーン（Ｚｏｎｅ３）では、ルータ４に接続されているハブ３ｃにＤＭＥ＃３−１、ＤＭＥ＃３−２、ＤＭＥ＃３−３が接続されて第３のゾーンの音響信号処理装置が構成されている。また、ＰＣ２はルータ４に接続されている。ネットワークは、一般的に用いられているイーサネットにより構築されている。ＰＣ２には本発明の実施例にかかる制御用プログラムがインストールされており、ＰＣ２において制御用プログラムを起動することにより、３台のＤＭＥ＃１−１〜＃１−３からなる第１のゾーンの音響信号処理装置におけるコンフィグの設定、２台のＤＭＥ＃２−１〜＃２−２からなる第２のゾーンの音響信号処理装置におけるコンフィグの設定、３台のＤＭＥ＃３−１〜＃３−３からなる第３のゾーンの音響信号処理装置におけるコンフィグの設定をすることができる。この設定は、ＰＣ２の表示器２８に表示されたコンフィグ設定のＣＡＤ画面において各ゾーンのＤＭＥ毎に行われ、それぞれのゾーンにおける音響信号処理装置のコンフィグデータが作成されるようになる。各ゾーンでは、当該ゾーンに属する複数台のＤＭＥからなる音響信号処理装置が独立して動作するようになり、各ゾーンにおいて入力される音響信号に対して種々の信号処理が施されて当該ゾーンの音響信号処理装置から出力されるようになる。

ＰＣ２において音響信号処理装置のコンフィグの設定を行う際には、まず、図５に示すコンフィグの概要を設定する画面ＣＡＤ１が表示器２８に表示されるようになる。図５に示す画面ＣＡＤ１では、ｎ本のマイクＭＩＣ１〜ＭＩＣｎからの音響信号およびミキサＭＩＸからの複数の音響信号の信号処理を第１ＤＭＥ＃１で行うように設定されている。そして、第１ＤＭＥ＃１において信号処理が施された第１の複数チャンネルの音響信号の信号処理を第２ＤＭＥ＃２で行うように設定されていると共に、第１ＤＭＥ＃１において信号処理が施された第２の複数チャンネルの信号処理を第３ＤＭＥ＃３で行うように設定されている。さらに、第２ＤＭＥ＃２において信号処理が施されたｍ系統の出力は、ステレオのアンプ１ａ〜１ｍでそれぞれ増幅され、増幅された音響信号は左スピーカＳＰ１Ｌａ〜ＳＰ１Ｌｍおよび右スピーカＳＰ１Ｒａ〜ＳＰ１Ｒｍにそれぞれ出力されている。このような画面ＣＡＤ１に示すようなコンフィグの設定が行われることにより、設定されたコンフィグに使用するＤＭＥの台数が、第１ＤＭＥ＃１〜第３ＤＭＥ＃３の３台と決定される。なお、画面ＣＡＤ１で設定される構成はＤＭＥの使い方を示すだけの設定であり、使用されるＤＭＥ数は決定されるが、画面ＣＡＤ１に表示された構成はコンフィグデータには反映されない。

必要とするＤＭＥの台数が画面ＣＡＤ１により決まると、音響信号処理装置におけるコンフィグの詳細を各ＤＭＥ毎に設定する図６に一例を示す画面ＣＡＤ２が表示器２８に表示されるようになる。
図６に示すように、画面ＣＡＤ２には第１ＤＭＥ＃１のコンフィグの詳細を設定する画面が表示され、コンポーネントウィンドウ（Component）Ｗ−１とデザイナーウィンドウ（Designer）Ｗ−２と、リソースメータウィンドウ（Resource Meter）Ｗ−３とが表示されている。リソースメータウィンドウＷ−３では、ＤＭＥ本体のＤＳＰメモリの合計使用率の目安がパーセント表示されると共に、デザイナーウィンドウＷ−２に配置したリバーブ、ディレイ、モジュレーション系エフェクト等のエフェクト用のコンポーネントとされるＳＰＸコンポーネントのリソース使用率がパーセント表示される。このリソースメータウィンドウＷ−３で表示される使用されるリソース使用量の目安を確認しながらコンフィグの設計を行っていく。デザイナーウィンドウＷ−２の初期画面には、出力端子のみ備えるスロットインSlot#1（Slot Input）と入力端子のみ備えるスロットアウトSlot#2（Slot Output）とスロットアウトSlot#3（Slot Output）とが表示される。スロットインSlot#1は、コンフィグを設定する第１ＤＭＥ＃１が備える物理的な入力端子および出力端子に相当しており、スロットアウトSlot#2，Slot#3は、コンフィグを設定する第１ＤＭＥ＃１が備える物理的な出力端子に相当している。

そして、スロットインSlot#1とスロットアウトSlot#2との間、および、スロットインSlot#1とスロットアウトSlot#3との間に使用するコンポーネントを配置していく。この場合、複数種類のコンポーネントがコンポーネントウィンドウＷ−１に用意されており、使用するコンポーネントをコンポーネントウィンドウＷ−１から選択してデザイナーウィンドウＷ−２の所定位置にドラッグ＆ドロップすることにより使用するコンポーネントが決定される。そして、決定されたコンポーネント間の出力端子と入力端子間の結線を行う。このような操作を使用する全てのコンポーネントについて行うと、図６のデザイナーウィンドウＷ−２に示すような信号処理の構成が設定される。この設定例の構成では、スロットインSlot#1から出力される４チャンネルの音響信号は４入力４出力の第１ミキサコンポーネント（Matrix Mixer）＃１に入力され、ミキシングされた２系統のステレオ信号が出力される。第１ミキサコンポーネント＃１からの１系統のステレオの出力は第１グラフィックイコライザコンポーネント（ＧＥＱ）＃１に入力されて、ステレオ信号の周波数特性およびレベルが調整される。第１ＧＥＱ＃１から出力されたステレオ信号は、第１ディレイコンポーネント（Delay）＃１に入力され、ディレイ効果の与えられたステレオ信号がスロットアウトSlot#2に出力される。

また、第１ミキサコンポーネント＃１からのもう１系統のステレオの出力は第２グラフィックイコライザコンポーネント（ＧＥＱ）＃２に入力されて、ステレオ信号の周波数特性およびレベルが調整される。第２ＧＥＱ＃２から出力されたステレオ信号は、第２ディレイコンポーネント（Delay）＃２に入力されて、ディレイ効果の与えられたステレオ信号がスロットアウトSlot#2に出力される。さらに、スロットインSlot#1から出力される残りの４チャンネルの音響信号は４入力８出力の第２ミキサコンポーネント（Matrix Mixer）＃２に入力され、８通りにミキシングされた８チャンネルが出力される。第２ミキサコンポーネント＃２からの８チャンネルのミキシング出力はスロットアウトSlot#3に出力される。このデザイナーウィンドウＷ−２で設定された第１ＤＭＥ＃１のコンフィグで使用される全てのコンポーネントの配置情報と、コンポーネント間の結線の情報からなるコンフィグデータはＲＡＭ２４やＰＣ２に接続されている外部記憶手段に保存することができる。なお、図示されている設定例のコンフィグにおいては、リソースメータウィンドウＷ−３に示されているように第１ＤＭＥ＃１本体のＤＳＰメモリの合計使用率が約７０％、ＳＰＸリソースの使用率が約５０％となっている。また、デザイナーウィンドウＷ−２に表示されているコンポーネント上にカーソルを置いてダブルクリックする等により、コンポーネントエディタのウィンドウが開いて当該コンポーネントのパラメータを編集することができる。

このようにしてＰＣ２において設定された第１ＤＭＥ＃１のコンフィグデータは第１ＤＭＥ＃１に送られる。第１ＤＭＥ＃１は、複数のＤＳＰを備えておりコンフィグデータに基づいて各コンポーネントのリソースを複数のＤＳＰのいずれかにそれぞれ割り当てることになる。この場合、各ＤＳＰにおいては実行できるステップ数が例えば１０２４ステップ等の限りがあることから、使用する各コンポーネントのリソースをどのＤＳＰにどの順番で割り当てるかを決めて割り当てないと、すべてのコンポーネントのリソースがＤＳＰに割り当てられないことが生じるおそれがある。そこで、コンフィグに使用されるすべてのコンポーネントのリソースを、第１ＤＭＥ＃１における複数のＤＳＰのいずれかにそれぞれ割り当てる処理を予め行うようにしている。この処理が、前述したようにコンパイルであり、コンフィグデータをコンパイルすることにより使用する全てのコンポーネントのリソースを複数のＤＳＰのいずれかにそれぞれ割り当てた情報からなるコンパイル結果ファイルが生成される。コンフィグデータのコンパイルは、ＰＣ２において実行されてコンパイル結果ファイルが、ネットワークを介してＰＣ２から第１ＤＭＥ＃１に送られるようになる。第１ＤＭＥ＃１では、ＰＣ２から送られたコンパイル結果ファイルの内容に基づいて各ＤＳＰのマイクロプログラムが生成され、生成されたマイクロプログラムを各ＤＳＰが実行することにより、ＰＣ２により設定されたコンフィグの通りの信号処理の構成が第１ＤＭＥ＃１において実現される。これにより、第１ＤＭＥ＃１のスロットインSlot#1に入力された音響信号に、デザイナーウィンドウＷ−２に示す構成により信号処理が施されて第１ＤＭＥ＃１のスロットアウトSlot#2，Slot#3から出力されるようになる。

ところで、上記した従来の通常アルゴリズムによるコンパイルでは、コンフィグにおける全てのコンポーネントのリソース量が複数のＤＳＰに割り当てられるリソース量の合計以内であっても、コンパイルできない場合があったり、膨大なコンポーネントの数からなるコンフィグが設定された場合は、従来の通常アルゴリズムではコンパイルすることがほぼ不可能になる。そこで、本発明にかかるＰＣ２において実行されるコンパイルでは、まず、従来の通常アルゴリズムによるコンパイルを試し、通常アルゴリズムによりコンパイルができた場合はコンパイルを終了させる。また、通常アルゴリズムによりコンパイルができない場合は、割り当ての最適化を行う最適化アルゴリズムによりコンパイルを行う。最適化アルゴリズムによるコンパイルでは、通常アルゴリズムに比べ多くの時間を要するが、通常アルゴリズムではコンパイルできなかったコンフィグでもコンパイルすることができる可能性が飛躍的に増大する。

そして、第２ＤＭＥ＃２および第３ＤＭＥ＃３においても、画面ＣＡＤ２に第２ＤＭＥ＃２，第３ＤＭＥ＃３のコンフィグの詳細を設定する画面を表示し、上記したように使用するコンポーネントを配置し、コンポーネント間の出力端子と入力端子間の結線を行うことによりコンフィグを設定していく。そして、設定された第２ＤＭＥ＃２，第３ＤＭＥ＃３におけるコンフィグデータは、それぞれコンパイルされコンパイル結果ファイルが、ネットワークを介してＰＣ２からそれぞれ送られる。第２ＤＭＥ＃２，第３ＤＭＥ＃３では、コンパイル結果ファイルの内容に基づいて各ＤＳＰのマイクロプログラムがそれぞれ生成される。そして、生成されたマイクロプログラムを各ＤＳＰが実行することにより、ＰＣ２により設定されたコンフィグの通りの構成が第２ＤＭＥ＃２，第３ＤＭＥ＃３において実現される。これにより、図５に示す第１ＤＭＥ＃１〜第３ＤＭＥ＃３を備える音響信号処理装置が実現される。ただし、第１ＤＭＥ＃１〜第３ＤＭＥ＃３間の結線およびマイク、ミキサ、アンプ、スピーカの外部機器との間の結線は物理的な結線であることから、ユーザがその結線を行うようにしている。

次に、ＰＣ２で実行されるコンパイル処理のフローチャートを図７に示す。
ＰＣ２において設定されたコンフィグデータをコンパイルする指示あるいはコンフィグデータを音響信号処理装置を構成しているＤＭＥに送る指示がされた際に、図７に示すコンパイル処理が起動されステップＳ１０において想定している全ての割当パターンを試したか否かが判断される。初回においては全ての割当パターンを試していないことからステップＳ１１に進み想定した最初の割当パターンを用いる上記した通常アルゴリズムによるコンパイルが行われる。次いで、ステップＳ１２にて通常アルゴリズムによりコンパイルできたか否かが判断される。ここで、使用する全てのコンポーネントのリソースを、備えられている複数のＤＳＰのいずれかにそれぞれ割り当てることができた場合は、コンパイルできたと判断されてステップＳ１５に進み、各コンポーネントのリソースをいずれのＤＳＰにいずれの順番で割り当てたかの情報からなるコンパイル結果ファイルが作成されてコンパイルは終了する。作成されたコンパイル結果ファイルはＲＡＭ２４上のキャッシュメモリに格納されるが、さらに他の記憶手段に保存することができる。

また、使用する全てのコンポーネントのリソースを複数のＤＳＰに割り当てることができず、ステップＳ１２において通常アルゴリズムではコンパイルできなかったと判断された場合は、ステップＳ１０に分岐して戻り、ステップＳ１０およびステップＳ１１において次の割当パターンを用いる通常アルゴリズムによるコンパイルが行われる。このような処理が、ステップＳ１２においてコンパイルできたと判断されるまで繰り返し行われる。そして、通常アルゴリズムによりコンパイルできたと判断されるとステップＳ１３に進み、コンパイル結果ファイルが作成されてコンパイルは終了する。また、全ての割当パターンを試してもステップＳ１２においてコンパイルできたと判断されない場合は、ステップＳ１０において全ての割当パターンを試してもコンパイルできなかったと判断されてステップＳ１３に分岐する。この場合は、通常アルゴリズムによるコンパイルができなかったことから、ステップＳ１３では最適化アルゴリズムによるコンパイル処理が実行される。最適化アルゴリズムとしてはアニーリング（焼きなまし）法、山登り法、遺伝的アルゴリズム等を用いることができる。なお、一般に、アニーリング法は、山登り法に比べ探索効率がよいとされるうえ、遺伝的アルゴリズムなどの他の最適化アルゴリズムに比べ、実装が比較的容易であるというメリットがある。

そして、ステップＳ１４にて最適化アルゴリズムによりコンパイルできたか否かが判断される。この場合、評価関数としてリソース用と結線用の２種類の評価関数が用意され、両方の評価関数においてそれぞれの評価値がクリアされた場合は、最適化アルゴリズムによりコンパイルできたと判断されてステップＳ１５に進み、各コンポーネントをいずれのＤＳＰにいずれの順番で割り当てたかの情報からなるコンパイル結果ファイルが作成されてコンパイルは終了する。作成されたコンパイル結果ファイルはＲＡＭ２４上のキャッシュメモリに格納されるが、さらに他の記憶手段に保存することができる。また、両方の評価関数における評価値の一方がクリアされず、ステップＳ１６において最適化アルゴリズムでもコンパイルできなかったと判断された場合は、ステップＳ１６に分岐してコンパイルが失敗したことがユーザに通知されコンパイルは終了する。このユーザーへの通知は、表示器２８にメッセージ等を表示することにより行われる。なお、コンパイル結果ファイルが作成された場合は、当該ファイルが音響信号処理装置を構成しているＤＭＥに送信される。

図７に示すコンパイル処理においてステップＳ１３で実行される最適化アルゴリズムによるコンパイル処理のフローチャートを図８に示す。
最適化アルゴリズムによるコンパイル処理が起動されると、ステップＳ２０にて前回最適化アルゴリズムによりコンパイルした時からコンフィグに変化があったか否かが判断される。ここで、コンフィグが前回と同様とされて変化がないと判断された場合は、ステップＳ２１に分岐して前回最適化アルゴリズムによりコンパイルしたコンパイル結果ファイルのデータがキャッシュに保存されているか否かが判断される。ここで、前回のコンパイル結果ファイルのデータがキャッシュに保存されていると判断された場合は、ステップＳ２２に進みキャッシュ内の前回のコンパイル結果ファイルのデータがコンパイル結果とされて最適化アルゴリズムによるコンパイル処理は終了し、図７に示すコンパイル処理におけるステップＳ１４に戻りコンパイルできたと判断される。

また、ステップＳ２０でコンフィグが前回と変化していると判断された場合、あるいは、ステップＳ２１で前回コンパイルしたコンパイル結果ファイルのデータがキャッシュに保存されていないと判断された場合は、ステップＳ２３にて、コンパイルするコンフィグに対応するＤＭＥにおける現在のリソース使用量がネットワークを介して取得される。このリソース使用量は、図６に示すリソースメータウィンドウＷ−３におけるＤＳＰメモリの合計使用率とＳＰＸコンポーネントのリソース使用率とされる。次いで、ステップＳ２４にて取得されたりソース使用量に応じて最適化アルゴリズムにおける初期パラメータがセットされる。この場合、アニーリング法の最適化アルゴリズムとされる場合は、状態遷移確率を制御する変数である温度パラメータＴがリソース使用量に応じて設定される。

次いで、ステップＳ２５にて最適化アルゴリズムによるコンパイルが行われ、ステップＳ２６にてコンパイルできたか否かが判断される。ステップＳ２５における最適化アルゴリズムでは、解を繰り返し求め直すことにより最適な解を求めていくが、ステップＳ２５における解を繰り返し求める繰り返し回数はＮ回までとされる。そして、解を繰り返し求めていく過程において、ＤＳＰにアサインできた使用するコンポーネントのリソースの割合［%］であるリソース用評価関数と、ＤＳＰにアサインできた結線の割合［%］である結線用評価関数の両方の評価値を満たす解が見つかった際には、ステップＳ２６にてコンパイルすることができたと判断され、ステップＳ２９に分岐する。なお、コンパイルできたときにはコンフィグ内で使用されている全てのコンポーネントの全ての種類のリソースがＤＳＰに割り当てられるようになる。ステップＳ２９では、コンパイルが成功とされて最適化アルゴリズムによるコンパイル処理は終了し、図７に示すコンパイル処理におけるステップＳ１４に戻りコンパイルできたと判断される。なお、２種類の評価関数においては、リソース用評価関数が結線用評価関数より優先度が大きくされている。

また、解を繰り返し求める繰り返し回数がＮ回に達しても両方の評価値を満たす解が見つからなかった場合は、ステップＳ２６にてコンパイルできなかったと判断されてステップＳ２７に進み繰り返し回数がＮ回で１試行回数とされる試行回数が、指定された試行回数Ｍに達しているか否かが判断される。この場合は、試行回数が１回目とされていることからステップＳ２７において試行回数はまだＭ回に達していないと判断されて、ステップＳ２８に進む。ステップＳ２８では試行回数が１だけインクリメントされ、ステップＳ２５に戻り乱数の種をふり直すことにより初期パラメータ値が変更されて最適化アルゴリズムによるコンパイルが再度行われる。ステップＳ２５ないしステップＳ２８の処理はステップＳ２６にてコンパイルできたと判断されるまで繰り返し行われ、繰り返し行われている際にコンパイルすることができたと判断された場合はステップＳ２６からステップＳ２９に分岐して、コンパイルが成功とされて最適化アルゴリズムによるコンパイル処理は終了し、図７に示すコンパイル処理におけるステップＳ１４に戻りコンパイルできたと判断される。また、試行回数が指定されたＭ回に達してもコンパイルできたと判断されない場合は、ステップＳ２７からステップＳ３０に分岐してコンパイル失敗とされ、最適化アルゴリズムによるコンパイル処理は終了し、図７に示すコンパイル処理におけるステップＳ１４に戻りコンパイルできなかったと判断される。

ここで、最適化アルゴリズムとしてのアニーリング法について概略説明すると、アニーリング法では、探索空間の各点が物理システムの「状態」に対応し、最小化すべき関数が物理状態の「内部エネルギー」に対応する。そして、「初期状態」からエネルギーが極力最小になる状態にすることが目標とされる。ここで、ステップＳ２５においてアニーリング法によるコンパイルが行われる際には、現在状態のいくつかの近傍を検討し、現在状態のままがよいか、いずれかの近傍状態に遷移するのがよいかを確率的に決定する。その際に最終的にエネルギーの低い状態へ向かうよう考慮して解を求める。解を求める回数は上記Ｎ回まで繰り返されるが、途中において上記両方の評価値を満たす解が見つかった際には、ステップＳ２６にてコンパイルすることができたと判断される。

なお、解を求めていく際の現在状態から新たな状態候補への遷移確率は、温度パラメータＴの関数となる。この遷移確率では、ときにはエネルギーの高い状態へも遷移可能とされる。これは、エネルギーが真の極小には遠いが、近傍とだけ比べれば極小であるような状態に張り付いてしまうのを防ぐためである。また、状態の変化は温度パラメータＴに大きく依存するようになり、温度パラメータＴが大きいときには状態は急激に変化し、温度パラメータＴが小さくなると状態はゆるやかに変化するようになる。そこで、解が繰り返し求められて行くにつれて温度パラメータＴは所定のスケジュールに従って徐々に下げられていく。このように、アニーリング法による最適化アルゴリズムでは、まず探索空間の広い領域から解を求めるようにされ、次第にエネルギーの低い領域に向かって探索範囲を狭めていき、最もエネルギーの低い状態に降りて最適解を求めるようにしている。また、アニーリング法における初期パラメータとしては温度パラメータＴの値や各コンポーネントのリソースのＤＳＰへの振り分けとなる。この振り分けでは、一意に振られたコンポーネント番号を一意なＤＳＰ番号に対応させることにより行われ、コンポーネント番号に対するＤＳＰ番号を振り直すことにより初期パラメータ値を変更することができる。

次に、コンフィグで使用されるコンポーネントのメモリイメージを図９に示す。
図９に示すコンポーネントのメモリイメージのように、リソース情報、パラメータ情報等からコンポーネントの情報が構成されている。リソース情報は、マイクロプログラムにおける必要とされるステップ数、レジスタの大きさを示すＲＡＭ使用量、入力数および出力数等から構成される。この場合、ＤＳＰにおいては、ステップ数は例えば１０２４ステップと限られたりソースであり、ＲＡＭとされるＤＳＰメモリの大きさも限られたりソースであり、入力数および出力数はＤＳＰの実際のピン数で限られたりソースとされることから、ステップ数、ＲＡＭ使用量、入力数および出力数がリソース情報とされる。なお、コンパイルされた際には、リソース情報で示す全ての種類のリソースがＤＳＰに割り当てられるようになる。

次に、図１０にプロジェクトファイルのメモリイメージを図１０ないし図１３に示す。プロジェクトファイルには、他のＰＣでコンパイルしても同じ結果が得られるようにコンパイル結果ファイル、使用アルゴリズム、初期値なども記録されている。図１０に示すように、プロジェクトファイルはエリアデータ（Area）とシーンデータ（Scene）等から構成されている。
エリアデータ（Area）は、図１１に示すように第１ゾーンデータ（Zone1）、第２ゾーンデータ（Zone2）、・・・の複数のゾーンのデータから構成可能とされ、各ゾーンデータは複数のコンフィグデータから構成することができる。例えば、第１ゾーンデータは第１コンフィグデータ（Config1）、第２コンフィグデータ（Config2）、・・・から構成される。そして、各コンフィグデータは、当該ゾーンを構成する各ＤＭＥのコンフィグデータから構成することができる。例えば、第１のＤＭＥ＃１のコンフィグデータ（DME#1）、第２のＤＭＥ＃２のコンフィグデータ（DME#2）、・・・から構成される。ＤＭＥのコンフィグデータは、当該ＤＭＥのコンフィグで使用される第１コンポーネントデータ（Component1）、第２コンポーネントデータ（Component2）、・・・からなる全てのコンポーネントデータと、コンパイル結果ファイル（Compile）から構成される。各コンポーネントデータは、一意に振られた識別番号（ID）、コンポーネントに設定されている各種のパラメータ情報（Parameter）、リソース情報（Resource）等から構成される。リソース情報は図９に示すように、ステップ数、ＲＡＭ使用量、入力数および出力数から構成される。

また、シーンデータ（Scene）は、図１２に示すように複数のシーンデータ(Scene1,Scene2,…)を設定することができ、各シーンデータにはコンフィグデータ（Config）が含まれている。このコンフィグデータは、複数のＤＭＥのコンフィグデータから構成することができる。例えば、コンフィグデータは、第１のＤＭＥ＃１のコンフィグデータ（DME#1）、第２のＤＭＥ＃２のコンフィグデータ（DME#2）、・・・から構成される。ＤＭＥのコンフィグデータは、当該ＤＭＥのコンフィグで使用される第１コンポーネントデータ（Component1）、第２コンポーネントデータ（Component2）、・・・からなる全てのコンポーネントデータから構成される。そして、各コンポーネントデータは、当該コンポーネントに設定される複数のパラメータセット（Parameter1,Parameter2,…）から構成され、各パラメータセットは、パラメータ名（Name）、パラメータ値（Value）等から構成される。

さらに、コンパイル結果ファイル（Compile）は、図１３に示すようにコンポーネントのリソースの割り当て情報と、ＤＳＰ間の結線情報と、コンパイルに使用したアルゴリズム情報とから構成される。割り当て情報は、コンパイルするコンフィグデータにおいて使用されている全てのコンポーネントデータ（Component1,Component2,…）から構成され、各コンポーネントデータは、一意に振られた識別番号（ID）、割り当てられるＤＳＰの番号、割り当てられるＤＳＰにおける割り当て順序等のデータから構成される。また、結線情報は、２つのＤＳＰにまたがる結線がある場合の物理的な結線の結線情報とされる。例えば、「DSP1-3,DSP3-5」という情報はＤＳＰ１のピン３とＤＳＰ３のピン５とを結線するという情報であり、「DSP1-4,DSP4-12」という情報はＤＳＰ１のピン４とＤＳＰ４のピン１２とを結線するという情報である。また、アルゴリズム情報は、通常アルゴリズムや最適化アルゴリズムにおけるアニーリング法、山登り法、遺伝的アルゴリズム等の使用アルゴリムと、そのアルゴリズムにおいて代表的なパラメータ種類および設定値のパラメータ情報とされる。

なお、上記したように最適化アルゴリズムを用いるコンパイルに切り替えられる際には、最適化アルゴリズムでのコンパイルを行うかどうかをユーザに問い合わせる図１４に示すウィンドウＷ−４が表示器２８に表示されるようになる。ウィンドウＷ−４において、「はい」のラジオボタンを選択して「ＯＫ」をクリックすると、最適化アルゴリズムを用いたコンパイルが行われるようになる。また、「いいえ」を選択して「ＯＫ」をクリックした場合および「キャンセル」をクリックした場合は、最適化アルゴリズムを用いたコンパイルは行なわれない。これは、コンパイルモードが切り替わった事をユーザに知らせると共に、最適化アルゴリズムは時間がかかるため、途中でＰＣ２が止まったとユーザに勘違いさせないためである。
また、上記したように最後のコンパイル結果ファイルはＲＡＭ２４にキャッシュされ、最後のコンパイル結果ファイルのコンパイル時以降にコンフィグに変更がなければ、図１５に示すウィンドウＷ−５を表示器２８に表示して、コンフィグに変更がないことからキャッシュ内のコンパイル結果を使用する旨をユーザに通知する。そして、コンパイルが指示された際にキャッシュされているコンパイル結果ファイルを使用する。

以上説明した本発明においては、１台以上の音響信号処理装置と制御装置とはネットワークを介して制御情報の授受を行うようにし、音響信号は音声Ｉ／Ｆにより音響信号処理装置から入出力するようにしている。この場合、高速なネットワークを別に設けて１台以上の音響信号処理装置とアンプを高速ネットワークに接続して、音響信号を高速ネットワークを介して授受するようにしてもよい。また、１台以上の音響信号処理装置と制御装置とアンプを１つのネットワークに接続して、このネットワークにより制御信号の授受および音響信号の授受を行うようにしてもよい。
なお、最適化アルゴリズムによるコンパイルには時間がかかることから、進捗ウィンドウを表示してコンパイルの進捗状況を表示するようにしてもよい。

本発明の実施例にかかる音響信号処理装置（ＤＭＥ）の構成を示すブロック図である。 本発明の実施例にかかる音響信号処理装置を制御する制御装置の構成を示すブロック図である。 本発明の実施例にかかる音響信号処理システムの構成例を示すブロック図である。 本発明の実施例にかかる音響信号処理システムの他の構成例を示すブロック図である。 本発明にかかる制御装置に表示されるコンフィグの概要を設定する画面を示す図である。 本発明にかかる制御装置に表示されるコンフィグの詳細を設定する画面を示す図である。 本発明にかかる制御装置で実行されるコンパイル処理のフローチャートである。 図７に示すコンパイル処理において実行される最適化アルゴリズムによるコンパイル処理のフローチャートである。 本発明にかかる制御装置で設定されるコンフィグで使用されるコンポーネントのメモリイメージを示す図である。 本発明にかかるプロジェクトファイルのメモリイメージを示す図である。 本発明にかかるプロジェクトファイルにおけるエリアデータのメモリイメージを示す図である。 本発明にかかるプロジェクトファイルにおけるシーンデータのメモリイメージを示す図である。 本発明にかかるプロジェクトファイルにおけるコンパイル結果ファイルのメモリイメージを示す図である。 本発明にかかる制御装置に表示される最適化アルゴリズムでのコンパイルを行うかどうかをユーザに問い合わせるウィンドウを示す図である。 本発明にかかる制御装置に表示されるコンフィグに変更がないことからキャッシュ内のコンパイル結果を使用する旨をユーザに通知するウィンドウを示す図である。 従来の音響信号処理システムの概要の構成を示す図である。 従来の制御装置に表示されるＤＭＥの信号処理構成を設定する画面を示す図である。 従来のコンパイルのアルゴリズムを示すフローチャートである。

符号の説明

１ 音響信号処理装置（ＤＭＥ）、２ 制御装置（ＰＣ）、３ ハブ、３ａ ハブ、３ｂ ハブ、３ｃ ハブ、４ ルータ、１０ ＣＰＵ、１１ ＲＯＭ、１２ ＲＡＭ、１３ 操作子、１４ 検出回路、１５ 表示器、１６ 表示回路、１７ 通信Ｉ／Ｆ、１８ 外部機器、１９ 音声Ｉ／Ｆ、２０ 外部機器、２１ ＤＳＰ、２２ 通信バス、２３ ＣＰＵ、２４ ＲＡＭ、２５ ＲＯＭ、２６ 操作子、２７ 検出回路、２８ 表示器、２９ 表示回路、３０ 通信Ｉ／Ｆ、３１ 通信バス、３２ 外部機器、１００ ＰＣ、１０１ ＤＭＥ、１０２ 信号ソース、１０３ スピーカ

Claims (3)

1. 音響信号に信号処理を施す複数のコンポーネントを組み合わせて構成され、該複数のコンポーネントとしてプログラム可能な複数の信号処理部が機能している音響信号処理装置の信号処理構成であるコンフィグを設定することが可能とされ、ネットワークを介して前記音響信号処理装置に接続可能な制御装置であって、
   前記複数のコンポーネントの組み合わせの設定、および、組み合わせた前記コンポーネントにおける出力端子と入力端子との間の結線の設定を行う設定手段と、
   該設定手段により設定された前記音響信号処理装置におけるコンフィグに基づいて、前記複数の信号処理部のいずれに前記複数のコンポーネントのリソースをそれぞれ割り当てるかを決めるよう所定のアルゴリズムに従ってコンパイルするコンパイル手段と、
   前記音響信号処理装置において、前記複数の信号処理部を前記複数のコンポーネントとして機能させる設定を行えるように、前記コンパイル手段によりコンパイルされたコンパイル結果ファイルを、前記音響信号処理装置に前記ネットワークを介して送る送信手段とを備えており、
   前記コンパイル手段は、前記コンフィグで使用される各コンポーネントのリソースを予め想定された割当パターンにより前記複数の信号処理部へ割り当てる通常アルゴリズムと、該通常アルゴリズムによるコンパイルに失敗した場合に実行され、前記コンフィグで使用される各コンポーネントのリソースを前記複数の信号処理部へ最適化して割り当てる最適化アルゴリズムとを有し、
   設定されたコンフィグのコンフィグデータおよび前記複数の信号処理部のいずれに前記複数のコンポーネントのリソースをそれぞれ割り当てるかの割り当て情報が少なくとも含まれているプロジェクトファイルに、コンパイルに使用したアルゴリズムの種類およびパラメータ値を少なくとも含むコンパイル情報を記録するようにしたことを特徴とする制御装置。
2. 前記最適化アルゴリズムの主要パラメータを、設定された前記コンフィグにおいて前記複数の信号処理部で使用されるリソース使用量に基づいて定められるようにしたことを特徴とする請求項１記載の制御装置。
3. コンピュータを、音響信号に信号処理を施す複数のコンポーネントを組み合わせて構成され、該複数のコンポーネントとしてプログラム可能な複数の信号処理部が機能している音響信号処理装置の信号処理構成であるコンフィグを設定することができるネットワークを介して前記音響信号処理装置に接続可能な制御装置として機能させる制御用プログラムであって、
   コンピュータを、
   前記複数のコンポーネントの組み合わせの設定、および、組み合わせた前記コンポーネントにおける出力端子と入力端子との間の結線の設定を行う設定手段、
   該設定手段により設定された前記音響信号処理装置におけるコンフィグに基づいて、前記複数の信号処理部のいずれに前記複数のコンポーネントのリソースをそれぞれ割り当てるかを決めるよう所定のアルゴリズムに従ってコンパイルするコンパイル手段、
   前記音響信号処理装置において、前記複数の信号処理部を前記複数のコンポーネントとして機能させる設定を行えるように、前記コンパイル手段によりコンパイルされたコンパイル結果ファイルを、前記音響信号処理装置に前記ネットワークを介して送る送信手段として機能させ、
   前記コンパイル手段は、前記コンフィグで使用される各コンポーネントのリソースを予め想定された割当パターンにより前記複数の信号処理部へ割り当てる通常アルゴリズムと、該通常アルゴリズムによるコンパイルに失敗した場合に実行され、前記コンフィグで使用される各コンポーネントのリソースを前記複数の信号処理部へ最適化して割り当てる最適化アルゴリズムとを有し、
   設定されたコンフィグのコンフィグデータおよび前記複数の信号処理部のいずれに前記複数のコンポーネントのリソースをそれぞれ割り当てるかの割り当て情報が少なくとも含まれているプロジェクトファイルに、コンパイルに使用したアルゴリズムの種類およびパラメータ値を少なくとも含むコンパイル情報を記録するようにしたことを特徴とする制御用プログラム。

Images