JP2014067074A - 録音システム、録音プログラム及び録音方法 - Google Patents

Abstract

【課題】メディア処理スレッドの起動周期の乱れを抑えると共に、汎用ＯＳのタスクスケジューリングの増加に伴う負荷を軽減することができるようにする。
【解決手段】本発明は、ＯＳとアプリケーションとの間で、ＯＳのタスクスケジュール制御の下、アプリケーションからの録音指示に従って取得した音声データを記憶手段に保存する録音システムにおいて、所定周期で起動して、取得した音声データに基づいて録音データを生成する録音データ生成処理スレッドと、録音データ処理スレッドにより生成された録音データを一時的に保持するデータ保持手段と、データ保持手段に保持されている録音データを、所定の書込み周期で記憶手段に書き込む書込みスレッドとを備えることを特徴とする録音システムである。
【選択図】 図１

Description

本発明は、録音システム、録音プログラム及び録音方法に関し、例えば、汎用ＯＳ上で動作するメディア処理ミドルウェアによるメディアファイルの録音システム、録音プログラム及び録音方法に適用し得るものである。

例えば、メディアサーバ、通話録音装置、コールセンタ装置、音声応答装置（ＩＶＲ：Interactive Voice Response）、会議サーバ（ＭＣＵ：Multipoint Control Unit）等のメディア装置は、複数のユーザ間の通話や、ユーザとオペレータとの間の通話等を、ハードディスクや又は別サーバ等に録音することが求められている。

上述したようなメディア装置は、汎用ＯＳ上で動作するメディア処理ミドルウェアにおいてメディア処理スレッドが起動して、メディア処理スレッドが、ＲＴＰパケットの送受信処理や録音処理等のメディア処理を実行している。

図２は、従来のメディア装置におけるメディア処理ミドルウェアのメディア処理スレッドの処理を示す構成図である。

図２に示すように、従来のメディア装置１０は、ハードウェア２と、汎用ＯＳ３と、メディア処理ミドルウェア１と、アプリケーションソフト４で構成されている。

メディア処理ミドルウェア１は、上位のアプリケーションソフト４からＡＰＩ（Application Program Interface）により制御される。ＡＰＩ制御は、例えば、ＲＴＰパケット送受信の開始又は停止、ファイル録音の開始又は停止、ファイル再生の開始又は停止、ＤＴＭＦ受信の開始又は停止等である。

また、メディア処理ミドルウェア１は、例えば、ファイル再生完了、ＤＴＭＦ受信等を契機として上位のアプリケーションソフト４にＥｖｅｎｔを通知する。

メディア処理スレッド１１−１〜１１−Ｎは、複数のＳｅｓｓｉｏｎ１〜Ｎが開始すると、それらＳｅｓｓｉｏｎ１〜Ｎのメディア処理をマルチタスク処理により実行するものである。つまり、汎用ＯＳ３は、ＣＰＵの使用時間を所定時間に分割して、各メディア処理スレッド１１−１〜１１−Ｎに割り当てる実行時間を分配するタスクスケジューリングにより、各メディア処理スレッド１１−１〜１１−Ｎを制御する（特許文献１参照）。

例えば、各メディア処理スレッド１１−１〜１１−Ｎに対して割り当てる起動周期の時間を２０ｍｓとすると、汎用ＯＳ３は、２０ｍｓを１周期として、各メディア処理スレッド１１−１〜１１−Ｎを周期起動する。Ｓｅｓｓｉｏｎが開始されると、メディア処理スレッド１１−１〜１１−Ｎが２０ｍｓ毎に周期起動する。そして、その２０ｍｓの間に、メディア処理スレッド１１は、メディア処理としてのＲＴＰパケット送受信処理、ファイル録音処理、ファイル再生処理、ＤＴＭＦ受信処理等を実行する。

メディア処理スレッド１１−１〜１１−Ｎがファイル録音を実行するとき、汎用ＯＳ３のシステムコールによって、録音データをハードディスク５−１〜５−Ｎに書き込む。このとき、例えばライトバック方式を設定しておくと、ＣＰＵがハードディスクにデータを書き込む際に、ＣＰＵがメモリにデータを書き込んだ時点で、システムコールからリターンし、その後、汎用ＯＳ３が、メモリからハードディスクにデータを転送する。これにより、録音ファイルがハードディスクに保存される。

特開２００６−１８５３０３号公報

しかしながら、多チャネルでファイル録音を実行すると、メモリの空き容量が少なくなっていき、汎用ＯＳのタスクスケジューリングが増加し、ライトバック方式であっても、データ書込みのシステムコールからリターンするまでの時間が長くなることがある。

そうすると、例えばメディア処理スレッドの起動周期が２０ｍｓであり、システムコールからリターンするまでの時間が３秒以上かかってしまうと、その間動作できない時間が３秒以上続いていてしまうことがある。その結果、メディア装置からユーザ端末へのＲＴＰパケットの送信周期が大きく揺らいだり、又は、ユーザ端末からのＤＴＭＦ受信の検出タイミングが遅延してしまったりするという問題が生じ得る。

そのため、多チャネルでファイル録音を実行するときでも、メディア処理スレッドの起動周期の乱れを抑えると共に、汎用ＯＳのタスクスケジューリングの増加に伴う負荷を軽減することができる録音システム、録音プログラム及び録音方法が望まれている。

かかる課題を解決するために、第１の本発明は、ＯＳとアプリケーションとの間で、ＯＳのタスクスケジュール制御の下、アプリケーションからの録音指示に従って取得した音声データを記憶手段に保存する録音システムにおいて、（１）所定周期で起動して、取得した音声データに基づいて録音データを生成する録音データ生成処理スレッドと、（２）録音データ処理スレッドにより生成された録音データを一時的に保持するデータ保持手段と、（３）データ保持手段に保持されている録音データを、所定の書込み周期で記憶手段に書き込む書込みスレッドとを備えることを特徴とする録音システムである。

第２の本発明は、ＯＳとアプリケーションとの間で、ＯＳのタスクスケジュール制御の下、アプリケーションからの録音指示に従って取得した音声データを記憶手段に保存する録音方法において、（１）録音データ生成処理スレッドが、所定周期で起動して、取得した音声データに基づいて録音データを生成し、（２）データ保持手段が、録音データ処理スレッドにより生成された録音データを一時的に保持し、（３）書込みスレッドが、データ保持手段に保持されている録音データを、所定の書込み周期で記憶手段に書き込むことを有することを特徴とする録音方法である。

第３の本発明は、ＯＳとアプリケーションとの間で、ＯＳのタスクスケジュール制御の下、アプリケーションからの録音指示に従って取得した音声データを記憶手段に保存する録音プログラムにおいて、（１）所定周期で起動して、取得した音声データに基づいて録音データを生成する録音データ生成処理スレッド、（２）録音データ処理スレッドにより生成された録音データを一時的に保持するデータ保持手段、（３）データ保持手段に保持されている録音データを、所定の書込み周期で記憶手段に書き込む書込みスレッドとして機能することを特徴とする録音プログラムである。

本発明によれば、多チャネルでファイル録音を実行するときでも、メディア処理スレッドの起動周期の乱れを抑えると共に、汎用ＯＳのタスクスケジューリングの増加に伴う負荷を軽減することができる。

実施形態のメディア装置の構成を示す構成図である。 従来のメディア装置におけるメディア処理ミドルウェアのメディア処理スレッドの処理を示す構成図である。 実施形態に係るメディア通信ネットワークの全体的な構成イメージを示す構成図である。 メディア処理ミドルウェア上に起動するメディア処理スレッドの起動周期を説明する説明図である。 実施形態に係るメディア処理ミドルウェア１で実行される録音処理を示すシーケンス図である。

（Ａ）主たる実施形態
以下では、本発明の録音システム、録音プログラム及び録音方法の実施形態を、図面を参照しながら詳細に説明する。

（Ａ−１）実施形態の構成
（Ａ−１−１）全体構成
図３は、この実施形態に係るメディア通信ネットワークの全体的な構成イメージを示す構成図である。

図３において、この実施形態のメディア通信ネットワーク９は、ネットワークに接続可能な、メディア装置１０、複数台の通話端末２０−１〜２０−Ｎを有して構成される。

メディア装置１０は、複数の通話端末２０−１〜２０−Ｎとの間で授受するメディアデータに基づいてメディア処理を行うものである。メディア装置１０は、運用システムの種類に応じて、例えば、メディアサーバ、通話録音装置、コールセンタ装置、音声応答装置（ＩＶＲ）、会議サーバ（ＭＣＵ）等として機能するものを適用することができる。

メディア装置１０は、図３に示すように、例えば、通話端末２０−１〜２０−Ｎとの間でＲＴＰパケットの送受信をしたり、ハードディスク等にファイル録音をしたり、ハードディスク等に録音されている音声データを通話端末２０−１〜２０−Ｎで聴かせるために再生をしたりするものである。なお、メディア装置１０の機能は、上記に例示した機能に限定されるものではない。

通話端末２０−１〜２０−Ｎは、ユーザやオペレータ等が使用するものであり、ネットワークを介して、ＲＴＰパケットの送受信を行うものである。通話端末２０−１〜２０−Ｎは、例えば、ＶｏＩＰ端末、電話機等の電話端末、パーソナルコンピュータに搭載されてソフトウェア処理により実現される通話機能（いわゆるソフトフォン機能）、会議端末、メディア受信端末等を適用することができる。

例えば、コールセンタシステムの場合、通話端末２０−１〜２０−Ｎは、ユーザ側の端末及びオペレータ側の端末が該当し、コールセンタの規模にもよるが、通話端末２０−１〜２０−Ｎは、例えば数台〜１０００台程度とすることができる。この場合、ユーザ側の通話端末２０−１〜２０−Ｎは、音声データやＤＴＭＦを含むＲＴＰパケットを、オペレータ側の通話端末２０−１〜２０−Ｎに送信する。逆にオペレータ側の通話端末２０−１〜２０−Ｎは、ユーザ側の通話端末２０−１〜２０−ＮにＲＴＰパケットを送信する。メディア装置１０は、例えばＲＴＰパケットをミラーリングするミラー装置（図示しない）と接続されており、ミラー装置を介して、通話端末２０−１〜２０−Ｎ間で授受されるＲＴＰパケットを取得できるようにしてもよい。

また例えば、会議システムの場合、会議に参加する複数のユーザ端末が該当する。この場合、メディア装置１０が会議サーバとして機能し、メディア装置１０は、複数の通話端末２０−１〜２０−Ｎからのメディアデータをミキシングして、送信すべき通話端末２０−１〜２０−Ｎに会議データを送信する。

上記では、コールセンタや会議システムの場合を例示したが、これら以外のシステムにも勿論適用することができる。その場合、システム種類に応じた通話端末２０−１〜２０−Ｎを適用できる。

（Ａ−１−２）メディア装置１０の詳細な構成
図１は、この実施形態のメディア装置１０の構成を示す構成図である。

図１において、この実施形態のメディア装置１０は、ハードウェア２、汎用ＯＳ３、メディア処理ミドルウェア１、アプリケーションソフト４、ハードディスク５（５−１〜５−Ｎ）を有する。

メディア装置１０は、マルチタスク処理が実装されたものであり、多数のＲＴＰパケットを取り扱うメディア装置である。

ハードウェア２は、メディア装置１０のハードウェア構成であり、例えば、ＣＰＵ、メモリ、通信インタフェース等であり、また図１のハードディスク５は、ハードウェア２に内蔵されるＨＤＤ等の大容量記憶装置である。

ハードウェア２において、ＣＰＵは、システムバスを介してメモリに接続されており、又、システムバス及び入出力デバイス等を介してハードディスク（大容量記憶装置）５等と接続されている。

なお、図１では、多チャネルの録音ファイルがハードディスク５に保存される様子を分かり易く示すために、複数のハードディスク５−１〜５−Ｎがあるように示しているが、実際は１個のハードディスク５でよい。

汎用ＯＳ３は、例えば、Ｌｉｎｕｘ（登録商標）やＷｉｎｄｏｗｓ（登録商標）等の汎用マルチタスクＯＳを適用することができる。図１に示すように、汎用ＯＳ３は、カーネル３１内にマルチタスク処理のスケジューリングを行うスケジューラ３２を有する。

スケジューラ３２は、ＣＰＵの使用時間を所定時間毎に分割して、スレッド処理ミドルウェア１のメディア処理スレッド１１−１〜１１−Ｎに割り当て管理を行うものである。メディア処理スレッド１１−１〜１１−Ｎに対して割り当てる起動周期の時間は、特に限定されないが、この実施形態では２０ｍｓを１周期とする場合を例示する。

アプリケーションソフト４は、メディア装置１０の機能処理を行うアプリケーションソフトウェアである。アプリケーションソフト４は、ＡＰＩによりメディア処理ミドルウェア１を制御することができる。例えば、ＡＰＩ制御としては、ＲＴＰパケットの送受信の開始又は停止、ファイル録音の開始又は停止、ファイル再生の開始又は停止、ＤＴＭＦ受信の開始又は停止等がある。

メディア処理ミドルウェア１は、汎用ＯＳ３とアプリケーションソフト４との間でメディア処理を行うメディア処理エンジンである。メディア処理ミドルウェア１は、上位のアプリケーションソフト４からＡＰＩ制御を受けて各種所定の処理を実行し、それぞれの処理で決められた動作を契機に、上位アプリケーションソフト４にＥｖｅｎｔを上げる。

メディア処理ミドルウェア１は、メディア処理スレッド１１−１〜１１−Ｎ、録音データキュー１２−１〜１２−Ｎ、書込みスレッド１３−１〜１３−Ｎを有する。

メディア処理スレッド１１−１〜１１−Ｎは、各種所定のメディア処理を行うものである。メディア処理スレッド１１−１〜１１−Ｎは、所定の起動周期で起動して、ＡＰＩ制御を受けて、その周期時間でメディア処理を行う。

メディア処理スレッド１１−１〜１１−Ｎが行うメディア処理としては、例えば、メディア処理スレッド１１−１〜１１−Ｎは、ＲＴＰパケットの送受信処理、ファイル録音処理、ファイル再生処理、ＤＴＭＦ受信処理等がある。これらメディア処理は、自由に組み合わせて同時に処理しても良い。つまり、Ｓｅｓｓｉｏｎ毎の複数のメディア処理スレッド１１−１〜１１−Ｎが同じ処理を同時に行うようにしてもよいし、又は、それぞれのメディア処理フレッド１１−１〜１１−Ｎが実行する処理を自由に設定するようにしてもよい。

また、この実施形態では、メディア処理のうちファイル録音処理について詳細に説明する。メディア処理スレッド１１−１〜１１−Ｎは、上位のアプリケーションソフト４からファイル録音の開始又は停止の指示を受けると、ＲＴＰパケットに含まれるＲＴＰデータに基づいて録音データを生成し、その録音データを録音データキュー１２−１〜１２−Ｎに投入するものである。

ここで、メディア処理スレッド１１−１〜１１−Ｎは、汎用ＯＳ３の制御によりスケジューリングされた周期時間２０ｍｓで周期起動し、ＡＰＩ制御によりファイル録音の開始又は停止を受けて、制御内容に従って録音データを生成する。

メディア処理スレッド１１−１〜１１−Ｎによる録音データ（通話データ）の生成について説明する。例えば、メディア装置１０に受信されたＲＴＰパケットは図示しないバッファ（例えばジッタバッファ等）に一時的に保持される。メディア処理スレッド１１−１〜１１−Ｎは、シーケンス番号に基づいてＲＴＰパケットの並び替えを行い、ＲＴＰフレームのタイムスタンプの順に従ってＲＴＰデータを正しい順番に通話データ（録音データ）を形成する。

このとき、メディア処理スレッド１１−１〜１１−Ｎは、所定時間毎に、所定時間内の通話に係る録音データを生成する。例えば、上記の所定時間が１０秒である場合には、メディア処理スレッド１１−１〜１１−Ｎは、１０秒毎に、１０秒の時間内の録音データを生成する。このメディア処理スレッド１１−１〜１１−Ｎが録音データを生成する時間は、予め設定されていても良いし、又はＡＰＩ制御により任意に設定されるようにしても良いし、又はｓｅｓｓｉｏｎ毎に異なる時間としても良い。

録音データキュー１２−１〜１２−Ｎは、メディア処理スレッド１１−１〜１１−Ｎから投入された録音データを保持するものである。録音データキュー１２−１〜１２−Ｎは、メディア処理スレッド１１−１〜１１−Ｎと書込みスレッド１３−１〜１３−Ｎとの間で録音データを受け渡すものである。録音データキュー１２−１〜１２−Ｎが保持するデータ容量は、予め決められているものであってもよいし、又は可変であってもよい。

書込みスレッド１３−１〜１３−Ｎは、録音データキュー１２−１〜１２−Ｎに保持される、所定時間分（例えば１０秒分等）の録音データを読み出してメモリへの書き込み処理を行うものである。

ここで、書込みスレッド１３−１〜１３−Ｎ、メディア処理スレッド１１−１〜１１−Ｎから録音データの生成及び投入に係るシグナル受信時又はＲＴＰパケットの受信時等を契機として起動し、録音データキュー１２−１〜１２−Ｎに保持される、所定時間分の録音データを読み出して書き込みを行う。

つまり、書込みスレッド１３−１〜１３−Ｎは、所定時間分のまとまった録音データの書き込みを行い、かつ、その書き込み周期がメディア処理スレッド１１−１〜１１−Ｎの起動周期時間よりも大きくなるため、録音データの書き込み頻度が従来よりも少なくなる。

例えば、メディア処理スレッド１１−１〜１１−Ｎの起動周期時間が２０ｍｓであり、書込みスレッド１３−１〜１３−Ｎの録音データの書込み周期が１０秒毎であるとすると、書込みスレッド１３−１〜１３−Ｎの起動頻度は、メディア処理スレッド１１−１〜１１−Ｎの起動頻度の１／５００となる。

これにより、メディア処理スレッド１１−１〜１１−Ｎの起動周期の乱れを回避できるため、メディア処理スレッド１１−１〜１１−Ｎを周期時間で起動させることができる。つまり、従来のようにシステムコールからリターンまでに時間がかかっていたために、メディア処理スレッドを起動させることができず、滞っていたＲＴＰパケットの送信処理やＤＴＭＦ受信の検出処理を行うことができる。その結果、ＲＴＰパケットの送信周期の揺らぎやＤＴＭＦ受信の検出タイミングの遅延等を小さくすることができる。

また、録音データの書き込み頻度が従来よりも少なくなるため、汎用ＯＳ３のタスクスケジューリングの増加を軽減でき、汎用ＯＳ３の負荷を軽減することができる。

なお、書込みスレッド１３−１〜１３−Ｎは、起動時に、録音データキュー１２−１〜１２−Ｎにキューイングされている所定時間分の録音データをまとめて読み取る場合を例示したが、キューイングされている録音データを数回に分けて読み取るようにしてもよい。

（Ａ−２）実施形態の動作
次に、この実施形態のメディア装置１０における録音処理の動作を、図面を参照しながら詳細に説明する。

図４は、メディア処理ミドルウェア１上に起動するメディア処理スレッド１１−１〜１１−Ｎの起動周期を説明する説明図である。図４に示すように、汎用ＯＳ３のタイムスケジューラ３２により、所定時間（例えば２０ｍｓ）毎に、メディア処理スレッド１１−１〜１１−Ｎが順番に起動し、その周期内で、メディア処理スレッド１１−１〜１１−Ｎは、所定のメディア処理を実行する。

図５は、メディア処理ミドルウェア１で実行される録音処理を示すシーケンス図である。

まず、メディア処理ミドルウェア１において、メディア処理スレッド１１−１〜１１−Ｎは、所定の起動周期で起動する（Ｓ１０１、Ｓ１０２）。

上位のアプリケーションソフト４からＡＰＩによりファイル録音の開始の指示がなされると、メディア処理スレッド１１−１〜１１−Ｎは、ファイル録音を開始する（Ｓ１０３）。

このとき、メディア処理スレッド１１−１〜１１−Ｎは、ファイル録音の開始の指示を受けてから所定時間（例えば１０秒）毎に、所定時間（例えば１０秒）毎の録音データを生成し（Ｓ１０４）、生成した録音データを録音データキュー１２−１〜１２−Ｎに投入する（Ｓ１０５）。

メディア処理スレッド１１−１〜１１−Ｎは、録音データキュー１２−１〜１２−Ｎに録音データを投入すると、書込みスレッド１３−１〜１３−Ｎに起動シグナルを通知する（Ｓ１０６）。なお。メディア処理スレッド１１−１〜１１−Ｎは、ファイル録音の停止の指示を受けるまで、Ｓ１０４〜Ｓ１０６の処理を繰り返し行う。

書込みスレッド１３−１〜１３−Ｎは起動シグナルを受信すると起動し（Ｓ１０７）、書込みスレッド１３−１〜１３−Ｎは、録音データキュー１２−１〜１２−Ｎにキューイングされている所定時間分の録音データを読み出して（Ｓ１０８）、書込み処理を行う（Ｓ１０９）。

すなわち、書込みスレッド１３−１〜１３−Ｎは、汎用ＯＳ３のシステムコールにより、録音データキュー１２−１〜１２−Ｎから読み出した録音データをメモリに書き込みを行う。そして、システムコールのリターンが戻ってきてから、汎用ＯＳ３がメモリ上の録音データをハードディスク５にデータ転送する。これにより、録音ファイルがハードディスク５に保存される。

録音データキュー１２−１〜１２−Ｎに録音データが無くなると、書込みスレッド１３−１〜１３−ＮはＷＡＩＴ状態となり、次の起動契機を待つ。

なお、書込み処理スレッド１３−１〜１３−Ｎは、録音データキュー１２−１〜１２−Ｎに録音データが残っている場合には、続けて、残っている録音データの書き込み処理を行うようにしても良い。また、別の方法として、所定時間経過後に、改めて、書込み処理スレッド１３−１〜１３−Ｎが書込み処理を行うようにしても良い。

また、メディア処理スレッド１１−１〜１１−Ｎは、ＡＰＩによりファイル録音の停止の指示があるまで録音データの生成及び録音データキュー１２−１〜１２−Ｎへの投入を繰り返し行う。

ここで、例えば、ファイル録音の開始から停止までが２５秒であり、１０秒毎に録音データを形成する場合、終盤の５秒間の録音データが残ってしまう。しかし、メディア処理スレッド１１−１〜１１−ｎは、最後の５秒間について同様にして録音データを形成して録音データキュー１２−１〜１２−Ｎに投入する。

この場合、書込みスレッド１３−１〜１３−Ｎは、録音データキュー１２−１〜１２−Ｎにキューリングされる最後の５秒間の録音データを読み出して、録音ファイルに書込み、録音ファイルをクローズする。

（Ａ−３）実施形態の効果
以上のように、この実施形態によれば、従来のようにシステムコールからのリターンに数秒以上もの時間がかかる可能性のあるファイル書込み処理を、書込みスレッドが実行するようにしたので、メディア処理スレッドの起動周期が大きく乱れないようにできる。それによって、ＲＴＰパケット送信周期の大きな揺らぎや、ＤＴＭＦ受信検出タイミングの遅延等の問題を回避できる。

また、この実施形態によれば、書込み処理の周期を、メディア処理スレッドの起動周期より大きくして、書込みスレッドの起動頻度を少なくしているため、従来よりも汎用ＯＳのタスクスケジューリング増加に伴う負荷を軽減することができる。

（Ｂ）他の実施形態
上述した実施形態においても、本発明の種々の変形実施形態を説明したが、その他の変形実施形態についても本発明は適用することができる。

（Ｂ−１）上述した実施形態のメディア処理ミドルウェアにおいて、メディア処理スレッドは、それぞれのＳｅｓｓｉｏｎ毎のメディア処理を行う場合を例示した。しかし、１個のメディア処理スレッドが、複数のＳｅｓｓｉｏｎについてのメディア処理を実行するようにしてもよい。例えば、メディア処理スレッドが、複数ＳｅｓｓｉｏｎのＲＴＰパケットの送信処理の実行と、複数Ｓｅｓｓｉｏｎのファイル録音処理を実行するようにしてもよい。つまり、メディア処理スレッドは所定周期で起動しているので、メディア処理スレッドの各周期での実行処理をスケジューリングすることにより実現することができる。

（Ｂ−２）上述した実施形態のメディア処理ミドルウェアにおいて、各メディア処理スレッドが実行するメディア処理として、ＲＴＰパケットの送受信処理、ファイル録音処理等を例示した。しかし、上述した実施形態で例示したメディア処理の種類の他に、メディア処理スレッドは、以下のようなメディア処理を実行するようにしてもよい。

例えば、メディア処理スレッドは、ＲＴＰデータの符号化方式（圧縮方式）の変換処理を行うようにしても良い。メディア処理スレッドは、ＲＴＰパケットのペイロードタイプに基づいてＲＴＰデータの符号化方式を確認し、ＲＴＰデータを所定の圧縮方式に変換するようにしてもよい。例えば、ＲＴＰデータがＩＴＵ Ｇ．７１１方式である場合に、Ｇ．７１１→Ｇ．７２９に変換するようにしてもよい。

なお、変換に係る符号化方式は、特に限定されるものではなく、様々な符号化方式間で行うようにしてもよい。これにより、録音データを圧縮することで、ハードディスクに保存する録音ファイルのデータ量を小さくすることができるため、大量の録音ファイルを保存することができる。また、上記のように録音データを圧縮すると録音データの音質が低下してしまい、再生時に音声が聞き取りにくい場合もあるため、圧縮方式を選択できるようにしても良い。

また例えば、メディア処理スレッドは、メディア装置が会議サーバとして機能するときに、複数の通話端末からのＲＴＰデータ（通話データ）のミキシング処理を実行するようにしてもよい。つまり、メディア処理スレッドが、複数のＳｅｓｓｉｏｎについてメディア処理を実行するものであり、複数のＳｅｓｓｉｏｎ先からのＲＴＰデータを加算することで実現できる。

さらに例えば、メディア処理スレッドは、メディア装置がコールセンタ装置等として機能する場合に、例えば、コールセンタの管理者（いわゆるスーパーバイザー）の端末からのモニタリング処理やウィスパリング（お客様端末には送信せず、オペレータ端末にのみ音声を送信する）処理を行うようにしてもよい。

また、メディア処理スレッドが、ファイル録音についても、複数のＳｅｓｓｉｏｎを対象に、複数のファイル録音を実行するようにしてもよい。さらに、メディア処理スレッドが、ミキシング処理を実行した後の音声データをファイル録音するようにしても良い。

（Ｂ−３）上述した実施形態は、メディア処理スレッドと、録音データキューと、書込みスレッドとがそれぞれ対応するものであり、それぞれ同じ数ずつ備える場合を例示した。

しかし、複数のメディア処理スレッドと、１個の録音データキューと、１個の書込みスレッドとを備えるようにしてもよい。つまり、複数のメディア処理スレッドが、録音データキューを共用し、書込みスレッドが１個の録音データキューから読み出した録音データを録音ファイルの書き込むようにしてもよい。これにより、録音データキューの数が減るので、メディア装置のコストを抑えることができる。

また、例えば２個のメディア処理スレッドが、１個の録音データキュー及び書込みスレッドを備える等して、録音データキュー及び書込みスレッドの個数が、メディア処理スレッドの個数よりも少なくなるようにしてもよい。

さらに、１個のメディア処理スレッドが、複数個の録音データキュー及び書込みスレッドを備えるようにしても良い。例えば、メディア処理スレッドが、複数の録音データキューにキューイングする場合、所定の順番に従って録音データキューにキューイングし、所定の順番に従って書込み処理スレッドが書込み処理を行うようにしても良い。

１０…メディア装置、１…メディア処理ミドルウェア、
１１−１〜１１−Ｎ…メディア処理スレッド、
１２−１〜１２−Ｎ…録音データキュー、
１３−１〜１３−Ｎ…書込みスレッド、
２…ハードウェア、３…汎用ＯＳ、４…アプリケーションソフト、
５−１〜５−Ｎ…ハードディスク。

Claims (7)

1. ＯＳとアプリケーションとの間で、ＯＳのタスクスケジュール制御の下、アプリケーションからの録音指示に従って取得した音声データを記憶手段に保存する録音システムにおいて、
   所定周期で起動して、上記取得した音声データに基づいて録音データを生成する録音データ生成処理スレッドと、
   上記録音データ処理スレッドにより生成された録音データを一時的に保持するデータ保持手段と、
   上記データ保持手段に保持されている録音データを、所定の書込み周期で記憶手段に書き込む書込みスレッドと
   を備えることを特徴とする録音システム。
2. 上記書込みスレッドの書込み周期が、上記録音データ生成処理スレッドの起動周期よりも大きいことを特徴とする録音システム。
3. 複数の上記録音データ生成処理スレッドが、１個の上記データ保持手段及び１個の書込みスレッドと関連付けて設けられるものであることを特徴とする請求項１又は２に記載の録音システム。
4. Ｎ個の上記録音データ生成処理スレッドが、Ｍ（Ｎ＞Ｍ）個の上記データ保持手段及びＭ個の書込みスレッドと関連付けて設けられるものであることを特徴とする請求項１又は２に記載の録音システム。
5. 上記録音データ生成処理スレッドが、生成する録音データの符号化形式を変換する機能を有することを特徴とする請求項１〜４のいずれかに記載の録音システム。
6. ＯＳとアプリケーションとの間で、ＯＳのタスクスケジュール制御の下、アプリケーションからの録音指示に従って取得した音声データを記憶手段に保存する録音方法において、
   録音データ生成処理スレッドが、所定周期で起動して、上記取得した音声データに基づいて録音データを生成し、
   データ保持手段が、上記録音データ処理スレッドにより生成された録音データを一時的に保持し、
   書込みスレッドが、上記データ保持手段に保持されている録音データを、所定の書込み周期で記憶手段に書き込む
   ことを有することを特徴とする録音方法。
7. ＯＳとアプリケーションとの間で、ＯＳのタスクスケジュール制御の下、アプリケーションからの録音指示に従って取得した音声データを記憶手段に保存する録音プログラムにおいて、
   所定周期で起動して、上記取得した音声データに基づいて録音データを生成する録音データ生成処理スレッド、
   上記録音データ処理スレッドにより生成された録音データを一時的に保持するデータ保持手段、
   上記データ保持手段に保持されている録音データを、所定の書込み周期で記憶手段に書き込む書込みスレッド
   として機能することを特徴とする録音プログラム。

Images