JP6205689B2

JP6205689B2 - データ処理装置及びプログラム

Info

Publication number: JP6205689B2
Application number: JP2012183503A
Authority: JP
Inventors: 高詩石黒
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2012-08-22
Filing date: 2012-08-22
Publication date: 2017-10-04
Anticipated expiration: 2032-08-22
Also published as: JP2014041480A

Description

本発明は、データ処理装置及びプログラムに関し、例えば、メディアデータをスレッド単位で処理するミドルウェアに適用し得る。

ＳＩＰ端末に係るメディアデータ（例えば、音声や映像等のデータ）のデータ処理を行うサーバは、リアルタイムなメディア通信を行うためのライブラリ（データ処理プログラム）を備えるミドルウェアを用いて構築される場合がある。

例えば、ＩＶＲ（ＩｎｔｅｒａｃｔｉｖｅＶｏｉｃｅＲｅｓｐｏｎｓｅ）装置や、電話会議サーバ等のメディアサーバ機能を用いて動作するサーバを新たに開発する場合、どの製品でも、メディアデータのデータ処理（例えば、符号化方式の変換処理）や、メディアデータの中継処理の基本的な動作自体は共通する処理が多い。そのため、メディアデータのデータ処理については、メディアデータを処理するライブラリを備えたミドルウェアを用いて開発を行うことで、開発期間の短縮、開発コストの低減、開発製品の高品質化等のメリットが得られる。

ところで、ＩＶＲ等の電話音声のデータ処理を行うサーバでは、多数の呼について同時に処理する必要があるため、それぞれの呼にスレッドを割り当てて処理を行う構成が一般的である。スレッド単位で、電話音声のデータ処理を行う従来技術としては、例えば、特許文献１〜３の記載技術がある。

特許文献１では、呼ごとに生成される親スレッド内で生成される子スレッドの効率的な処理を容易に実現するために、子スレッド間で調整して処理を行い、親スレッドでの複雑な排他制御を行わないようにしている。

特許文献２では、シングルＣＰＵを用いたコンピュータにおいて、ＴＳＳ（タイム・シェアリング・システム）を利用したマルチタスク環境を実現するＯＳ上で、音声データの処理を効率的に行うことについて記載されている。特許文献２では、ＴＳＳが各タスクに割り当てるクォンタム（処理単位時間）に依存せず、１つのクォンタムに複数のタスクのデータ処理を混在させることにより、ＴＳＳの仕様（クォンタム）に依存せず、効率的な音声データ処理を行うことができる。

特許文献３では、複数のスレッドが動作するプロセス内で、各スレッドが予め確保した所定の領域外のメモリ利用を行った場合でもプロセスの強制終了を回避することについて記載されている。特許文献３では、所定の領域外のメモリ利用を行うスレッドが発生した場合には、プロセス全体に影響がないと判断した場合のみ当該スレッドのみを削除している。

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

ところで、メディアデータを処理するミドルウェアを利用したサーバでは、当該ミドルウェアと、当該ミドルウェアを利用して動作するアプリケーションとの間で、処理タイミングは同期していることが望ましい。例えば、ＩＶＲ等のサーバで、音声ファイルの再生タイミングを制御する場合には、アプリケーション側での処理待ち時間（実時間）と、ミドルウェア側のスレッドで処理した処理量（例えば、パケット数）が同期していることが望ましい。したがって、このような場合、従来のメディアサーバでは、ミドルウェア側の処理量に応じてアプリケーション側の待ち時間を補正する必要がある。このような問題を解決する方法としては、例えば、ミドルウェア内で動作する多数のスレッドとアプリケーションとで、共通の時計を用いて同期させることが考えられるが、その場合、ミドルウェアの利便性（アプリケーション開発の効率）や汎用性を低下させたり（アプリケーションの仕様を制限させる）、ミドルウェアの処理量の増大につながる。

また、特許文献１〜３の記載技術を、メディアサーバのミドルウェアに適用した場合でも、アプリケーションとミドルウェア内の多数のスレッドとの処理タイミングについて、効率的に同期させる構成については記載されていない。

そのため、メディアデータの処理を行うスレッドについて、処理タイミングを効率的に制御することができるデータ処理装置及びプログラムが望まれている。

第１の本発明のデータ処理装置は、（１）アプリケーション処理手段の制御に応じて、メディアデータの処理を行うメディアデータ処理手段を備え、（２）上記メディアデータ処理手段は、（２−１）周期的に起動して、メディアデータの再生及び再生停止を行うデータ処理手段と、（２−２）上記データ処理手段が起動する度にカウンタ値が加算されるカウンタを用いて時間の計測を行うタイマ手段とを備え、（３）上記データ処理手段は、上記アプリケーション処理手段の制御に応じて、当該データ処理手段が行う上記再生及び上記再生停止に係る時間計測を、上記タイマ手段を用いて行い、（４）上記データ処理手段は、上記アプリケーション処理手段から指定される、メディアデータを再生または再生停止する処理時間に亘り周期的に起動して処理を行うとともに、上記タイマ手段に当該処理時間をタイムアウト時間とする時間の計測を実行させ、上記タイマ手段でタイムアウトが発生した場合のタイムアウトイベントを出力し、（５）上記メディアデータ処理手段は、（６）それぞれの上記データ処理手段で発生した、タイムアウトイベントのみを処理する第１のイベント処理手段と、（７）それぞれの上記データ処理手段で発生したタイムアウトイベント以外のイベントを処理する第２のイベント処理手段と、（８）上記第１のイベント処理手段でタイムアウトイベントが保持されると、当該タイムアウトイベントに係る上記データ処理手段への所定の処理を、上記アプリケーション処理手段に要求するコールバック要求処理手段とをさらに備えることを特徴とする。

第２の本発明のデータ処理プログラムは、コンピュータを、（１）アプリケーション処理手段の制御に応じて、メディアデータの処理を行うメディアデータ処理手段として機能させ、（２）上記メディアデータ処理手段は、（２−１）周期的に起動して、メディアデータの再生及び再生停止を行うデータ処理手段と、（２−２）上記データ処理手段が起動する度にカウンタ値が加算されるカウンタを用いて時間の計測を行うタイマ手段とを備え、（３）上記データ処理手段は、上記アプリケーション処理手段の制御に応じて、当該データ処理手段が行う上記再生及び上記再生停止に係る時間計測を、上記タイマ手段を用いて行い、（４）上記データ処理手段は、上記アプリケーション処理手段から指定される、メディアデータを再生または再生停止する処理時間に亘り周期的に起動して処理を行うとともに、上記タイマ手段に当該処理時間をタイムアウト時間とする時間の計測を実行させ、上記タイマ手段でタイムアウトが発生した場合のタイムアウトイベントを出力し、（５）上記メディアデータ処理手段は、（５−１）それぞれの上記データ処理手段で発生した、タイムアウトイベントのみを処理する第１のイベント処理手段と、（５−２）それぞれの上記データ処理手段で発生したタイムアウトイベント以外のイベントを処理する第２のイベント処理手段と、（５−３）上記第１のイベント処理手段でタイムアウトイベントが保持されると、当該タイムアウトイベントに係る上記データ処理手段への所定の処理を、上記アプリケーション処理手段に要求するコールバック要求処理手段とをさらに備えることを特徴とする。

本発明によれば、メディアデータの処理を行うスレッドについて、処理タイミングを効率的に制御することができる。

実施形態に係るデータ処理装置の機能的構成について示したブロック図である。実施形態に係る音声ファイルの再生スケジュールの例（その１）について示したタイミングチャートである。実施形態に係る音声ファイルの再生スケジュールの例（その２）について示したタイミングチャートである。実施形態に係るデータ処理装置の動作について示したシーケンス図（その１）である。実施形態に係るデータ処理装置の動作について示したシーケンス図（その２）である。実施形態に係るデータ処理装置の動作について示したシーケンス図（その３）である。

（Ａ）主たる実施形態
以下、本発明によるデータ処理装置及びプログラムの一実施形態を、図面を参照しながら詳述する。

（Ａ−１）実施形態の構成
図１は、この実施形態のデータ処理装置１及び周辺装置との接続構成を示すブロック図である。

データ処理装置１は、ネットワーク６に接続する端末２（２−１、２−２）に対して、メディアデータ処理サービスを提供するメディアサーバである。この実施形態では、例として、データ処理装置１は、ＩＶＲとして機能するサーバ（メディアサーバ）であるものとして説明するが、データ処理装置１が提供するメディアデータ処理サービスの内容や、提供先については限定されないものである。

図１に示すように、データ処理装置１は、例えば既存のＰＣやワークステーション等のハードウェア１０上に汎用ＯＳ２０を搭載したプラットフォーム上に構築されているものとする。汎用ＯＳ２０は、例えば、Ｌｉｎｕｘ（登録商標）やＷｉｎｄｏｗｓ（登録商標）等の汎用的なＯＳを適用することができる。

そして、汎用ＯＳ２０上には、シグナリング処理を行うシグナリング処理部５０と、スレッド３１を用いてメディアデータ処理を行うメディアデータ処理部３０とが搭載されている。さらに、データ処理装置１には、メディアデータ処理部３０及びシグナリング処理部５０を利用したメディアデータ処理サービスを提供するアプリケーション４０が搭載されている。

すなわち、アプリケーション４０は、メディアデータ処理部３０及びシグナリング処理部５０を利用して、端末２（２−１、２−２）に対してＩＶＲのサービスを提供するアプリケーションとして機能する。

メディアデータ処理部３０は、アプリケーション４０の制御に応じて、ネットワーク６上の通信装置（端末２等）に対するメディアデータサービスを提供するミドルウェアである。メディアデータ処理部３０は、アプリケーション４０から１つの呼（セッション）について、メディアデータサービスが要求されると、当該呼に対するスレッド３１を生成する。そして、メディアデータ処理部３０には、スレッド３１が実行するメディアデータ処理のライブラリ（処理プログラムの集合体）が備えられており、スレッド３１はそれらのライブラリを利用して、アプリケーション４０の制御に応じたメディアデータ処理を実行する。図１では、メディアデータ処理部３０には、Ｎ個のスレッド３１（３１−１〜３１−Ｎ）が生成された状態について示している。なお、メディアデータ処理部３０で、同時に生成されるスレッド３１の数は限定されないものである。

なお、メディアデータ処理部３０は、プロセッサやメモリ等を有するコンピュータ（ハードウェア１０）に、実施形態のデータ処理プログラムを実行させることにより実現することができる。

ＡＰＩ処理部３２は、ＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）により、アプリケーション４０からの制御指示を受付ける（機能呼出を受付ける）ためのインタフェースである。アプリケーション４０は、ＡＰＩ処理部３２の仕様（ＡＰＩの仕様）に基づいた制御指示を供給することにより、メディアデータ処理部３０を利用したメディアデータ処理を実行することができる。ＡＰＩの機能は、例えば、セッション開始／停止、音声ファイル再生開始／停止などがある。

メディアデータ処理部３０では、アプリケーション４０からＡＰＩ処理部３２にセッション開始が指示された場合に、当該セッションに対応するスレッド３１が生成される。そして、アプリケーション４０では、各セッションのＩＤと、各セッションに対応するスレッド３１のＩＤが紐づけて管理されることになる。

そして、アプリケーション４０から、いずれかのスレッド３１に対する制御指示があった場合には、ＡＰＩ処理部３２は、その制御指示に対応するスレッド３１（例えば、スレッドのＩＤ等により特定する）に、当該制御指示を伝達する。

また、この実施形態では、ＡＰＩ処理部３２と各スレッド３１との間は、直接通信する構成ではなく、共有メモリ３６を媒体として情報伝達する構成となっている。これは、すべてのスレッド３１が常に起動しているわけではないため、ＡＰＩ処理部３２と各スレッド３１との間で、効率的に情報伝達するための構成である。したがって、アプリケーション４０からの制御指示をいずれかのスレッド３１に伝達する場合、ＡＰＩ処理部３２は、共有メモリ３６にスレッドのＩＤを付した情報（指示内容を記述した情報）を共有メモリ３６に格納する。そして、各スレッド３１は、起動する度に共有メモリ３６を確認して、自己への指示の情報が格納されていれば、その情報を取得して処理を行う。

イベントキュー３３は、各スレッド３１で発生したイベント（例えば、セッション開始等）を一旦保持して、アプリケーション４０に報告する処理を行うキューである。

イベントキュー３５は、スレッド３１で所定時間を計時（計測）する処理（以下、「タイマ処理」と呼ぶ）によるタイムアウト（タイマ満了）に伴って発生するイベント（以下、「タイムアウトイベント」と呼ぶ）を一旦保持して、コールバックスレッド３４に供給する処理を行うキューである。コールバックスレッド３４は、スレッド３１からのタイムアウトイベントの供給を受けると、アプリケーション４０のコールバック処理部４１に、当該スレッド３１に対応するコールバック処理を実行させるものである。コールバック処理とは、スレッド３１で、タイムアウトイベントが発生した場合に、アプリケーション４０から当該スレッド３１に対して実行されるべき次のステップの処理（例えば、音声ファイルの再生停止の制御指示等）について、メディアデータ処理部３０側（コールバックスレッド３４）から実行を促す処理である。

そして、コールバックスレッド３４は、タイムアウトイベントが供給されると、アプリケーション４０のコールバック処理部４１に、当該タイムアウトイベントに対応するコールバック処理（当該タイムアウトイベントの発行元のスレッド３１に対する制御指示の処理）を実行させる。例えば、アプリケーション４０では、スレッド３１に対してタイマ処理を実行させる際に、当該タイマ処理に対応するコールバック処理を定義した情報をコールバック処理部４１に設定しておくものとする。そして、コールバック処理部４１は、当該スレッド３１で、当該タイマ処理に対応するタイムアウトイベントが発行されると、予め設定されたコールバック処理（当該スレッド３１に対する制御指示）をアプリケーション４０本体に実行させるものとする。

このように、データ処理装置１では、スレッド３１からアプリケーション４０へのタイマイベントに伴うコールバック処理専用の伝達経路（コールバックスレッド３４及びイベントキュー３５）が設定されているものとする。

この実施形態では、ＡＰＩ処理部３２と、スレッド３１とは、共有リソース（メモリや変数等）ヘのアクセスが生じるため、排他制御により、同時に動作することが出来ない構成となっているものとする。そのため、データ処理装置１では、ＡＰＩ処理部３２とスレッド３１との処理が競合してデッドロックしないように、スレッド３１とは別にコールバックスレッド３４を追加している。

この実施形態では、メディアデータ処理部３０において、各スレッド３１は、定期的に起動（以下、「周期起動」と呼ぶ）して処理を行うものとする。この実施形態では、例として、スレッド３１は、メディアデータ処理に係る呼（セッション）が起動すると、２０ｍｓ周期で周期起動し、周期起動したときに、メディアデータ処理として、メディアデータの処理などを実行する。

ここでは、各スレッド３１は、周期起動した場合、その周期起動のインターバル分のメディアデータの処理を実行するものとする。例えば、スレッド３１が音声データファイルから、音声データの符号化及びＲＴＰ（Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）パケット生成・送信処理を行う場合を想定する。この場合、スレッド３１は、周期起動する度に、２０ｍｓ分の音声データについて符号化及びＲＴＰパケットの生成・送信処理を行うことになる。

各スレッド３１が処理するメディアデータの保存先は限定されないものであり、例えば、汎用サーバなどのハードディスクに保存されているものでも良いし、ネットワーク６で接続されている別サーバ上のファイルであっても良いし、メモリ上に展開されていても良い。各スレッド３１は、セッション開始、セッション停止、音声ファイル再生開始、音声ファイル再生停止などの契機でイベント生成して、イベントキュー３３に供給（アタッチ）する。この実施形態では、例として、各スレッド３１は、アプリケーション４０が保持している音声ファイルＦ１を取得し、音声ファイルＦ１の音声データを符号化（例えば、Ｇ．７１１などのＣｏｄｅｃでエンコード）して、ＲＴＰパケットのペイロードに挿入し、端末２に向けて送出する処理を行うものとする。以下では、各スレッド３１が音声ファイルＦ１からＲＴＰパケット生成して送信する処理を「再生処理」とも呼ぶものとする。

各スレッド３１は、周期起動する度にインクリメントされるカウンタを用いて時間計測を行うタイマ処理部３１１を有している。各スレッド３１では、このタイマ処理部３１１に基づいたタイミングで、アプリケーション４０から指示されたタイマ処理を行う。例えば、アプリケーション４０から１秒間の音声ファイル再生処理（１秒間を計時するタイマ処理及び音声ファイルの再生処理）の制御指示があった場合には、５０回の周期起動（２０ｍｓ×５０＝１ｓ）が行われたときに、１秒間分のメディアデータが処理されたものとして取り扱う。

（Ａ−２）実施形態の動作
次に、以上のような構成を有するこの実施形態のデータ処理装置１の動作を説明する。上述の通り、この実施形態では、データ処理装置１はＩＶＲとして機能するものである。そして、ここでは、例として、データ処理装置１から、端末２−１に対して音声ファイルＦ１の再生処理（音声データを挿入したＲＴＰパケットの送信処理）を行う場合について説明する。具体的には、スレッド３１−１が、アプリケーション４０からの制御指示（ＡＰＩを用いた制御指示）に基づいて音声ファイルの再生処理を行うものとする。

図２では、タイミングＴ１００からタイミングＴ１０１までの１０秒間音声ファイルＦ１を再生した後、タイミングＴ１０１からタイミングＴ１０２までの５秒間無音状態とし、さらにタイミングＴ１０２からタイミングＴ１０３までの間音声ファイルＦ１を再度再生する処理を行うことについて示している。言い換えると、図２では、音声ファイルＦ１を再生する動作を２回行い、再生間隔（無音期間）を５秒としている。なお、音声ファイルＦ１の再生時間については、１０ｓｅｃの音声ファイルを準備しておき再生完了を契機として制御するようにして良いが、この実施形態では、タイマ処理で制御するものとして説明する。

アプリケーション４０内で、図２に示すような音声ファイルの再生タイミングを記述する形式（記述言語）については限定されないものであるが、例えば、ＭＳＣＭＬ（ＩＥＴＦＲＦＣ５０２２：（ＭｅｄｉａＳｅｒｖｅｒＣｏｎｔｒｏＩＭａｒｋｕｐＬａｎｇｕａｇｅ（ＭＳＣＭＬ）ａｎｄＰｒｏｔｏｃｏｌ））を利用するようにしてもよい。

ＭＳＣＭＬでは、ｄｅｌａｙ、ｒｅｐｅａｔ、ｄｕｒａｔｉｏｎといったパラメータを用いて再生タイミングを記述することができる。「ｄｅｌａｙ」は、ファイル再生前に指定の時間分再生を遅延させることを示すパラメータである（ただし、初回の再生前には適用されない）。また、ｄｅｌａｙの期間中は無音となる。「ｒｅｐｅａｔ」は、音声ファイルの再生回数を示すパラメータである。なお、「ｒｅｐｅａｔ」に所定のパラメータを設定することにより、無制限（∞）のリピート再生の指定も可能である。「ｄｕｒａｔｉｏｎ」は、音声ファイルの再生する時間（位置）を示すパラメータである。セッション（呼）開始からｄｕｒａｔｉｏｎに示される時間に達したとき、自動的にセッション（呼）が切断され、音声ファイル再生も終了する。

したがって、図２のタイミングチャートに示されるタイミングをＭＳＣＭＬのパラメータで記述すると、「音声ファイル再生時間：１０ｓｅｃ、ｄｅｌａｙ：５ｓｅｃ、ｒｅｐｅａｔ：２、ｄｕｒａｔｉｏｎ：−（無し）」となる。

また、図３では、「音声ファイル再生時間：１０ｓｅｃ、ｄｅｌａｙ：５ｓｅｃ、ｒｅｐｅａｔ：無制限（∞）、ｄｕｒａｔｉｏｎ：３５ｓｅｃ」とした場合の再生タイミングについて示したタイミングチャートとなっている。

この実施形態のアプリケーション４０では、ＭＳＣＭＬにより記述された再生タイミングの制御情報に基づいて、スレッド３１−１に対する制御内容（制御指示の内容や、次回のタイムアウトに伴うコールバック処理として設定する内容）の決定が行われる。

次に、上述の図３のようなタイミングで音声ファイル再生が行われた場合のデータ処理装置１内部の詳細な動作について、図４〜図６のシーケンス図を用いて説明する。

図４〜図６では、スレッド３１−１で２０ｍｓｅｃ間隔で発生する各周期起動についてそれぞれＢ１０１〜Ｂ１３５１のいずれかの符号を付している。そして、図４〜図６において、各周期起動に係る破線の内部に図示されたステップの処理は、スレッド３１−１において、当該周期起動で実行される処理であることを示している。

また、図４〜図６のフローチャートの初期状態として、アプリケーション４０の制御指示（セッション開始）に基づいて、メディアデータ処理部３０にスレッド３１−１が生成されているものとして説明する。

そして、アプリケーション４０から、ＡＰＩ処理部３２に対して、スレッド３１−１に係る１０ｓｅｃを計時するタイマ処理の起動、及び、音声ファイルＦ１の再生開始の制御指示があったものとする。そして、ＡＰＩ処理部３２は、その制御指示の内容を記述した制御指示を共有メモリ３６に格納したものとする（Ｓ１０１、Ｓ１０２）。

その後、スレッド３１−１は、周期起動して周期起動Ｂ１０１の処理（ステップＳ１０３〜Ｓ１０６の処理）が実行される。

周期起動Ｂ１０１において、スレッド３１−１は、まず、共有メモリ３６の内容を確認して自己への制御指示が格納されていることを認識して、当該制御指示を取得する（Ｓ１０３）。

そして、スレッド３１−１は、取得した制御指示の内容に基づいて、タイマ処理部３１１のカウンタ値を初期化（０）して起動し、１０ｓｅｃの計時（カウンタ値が５００となるまでの計時）を行うタイマ処理を開始させる（Ｓ１０４）。

そして、スレッド３１−１は、取得した制御指示の内容に基づいて、音声ファイルＦ１の再生処理を開始する。スレッド３１−１は、周期起動Ｂ１０１の段階では、音声ファイルＦ１の２０ｍｓｅｃ分の音声の音声データについて再生処理を行う。また、スレッド３１−１は、タイマ処理部３１１のカウンタ値をインクリメントする処理を行う（Ｓ１０５）。そして、音声ファイルＦ１の再生処理を開始すると、スレッド３１−１は、イベントキュー３３に、再生処理を開始した旨のイベントを通知する（Ｓ１０６）。以上で、スレッド３１−１による周期起動Ｂ１０１での処理が終了する。

そして、再生開始処理のイベントが通知されたイベントキュー３３は、そのイベントを保持して、アプリケーション４０に通知する（Ｓ１０７）。

そして、次の周期起動Ｂ１０２のタイミングを迎えると、スレッド３１−１は、音声ファイルＦ１の次の２０ｍｓｅｃ分の音声の音声データについて再生処理を行い、さらに、タイマ処理部３１１のカウンタ値をインクリメントする処理を行う（Ｓ１０８）。

そして、スレッド３１−１は、周期起動Ｂ１０２と同様の処理（ステップＳ１０６）の処理について繰り返し、タイマ処理部３１１のカウンタ値が４９９に達した状態で、周期起動Ｂ１０１から数えて５００回目の周期起動Ｂ６００を迎えたものとする。周期起動Ｂ６００において、スレッド３１−１は、後述するステップＳ２０２〜Ｓ２０３の処理を実行する。

周期起動Ｂ６００では、スレッド３１−１は、音声ファイルＦ１の、次の２０ｍｓｅｃ分の音声の音声データについて再生処理を行い、さらに、タイマ処理部３１１のカウンタ値をインクリメントする処理を行う（Ｓ２０１）。そして、この時点で、スレッド３１−１において、タイマ処理部３１１のカウンタ値は５００となり、タイマ処理部３１１のタイムアウトを検出することになる（Ｓ２０２）。そして、スレッド３１−１は、タイマ処理部３１１のタイムアウトを検出すると、タイムアウトイベントを、イベントキュー３５に供給する（Ｓ２０３）。以上で、スレッド３１−１による周期起動Ｂ６００での処理が終了する。

そして、イベントキュー３５は、供給されたタイムアウトイベントを、コールバックスレッド３４に供給する（Ｓ２０３）。そして、コールバックスレッド３４は、供給されたタイムアウトイベントに対応するコールバック処理を、アプリケーション４０（コールバック処理部４１）に要求する（Ｓ２０４）。ここでは、アプリケーション４０（コールバック処理部４１）には、スレッド３１−１に対する次のコールバック処理として、音声ファイルの再生停止の制御、及び、５ｓｅｃを計時するタイマ処理の起動制御が設定されているものとする。

そして、アプリケーション４０（コールバック処理部４１）は、次のコールバック処理の定義に従って、ＡＰＩ処理部３２に対して、スレッド３１−１に係る音声ファイルＦ１の再生停止、及び、５ｓｅｃを計時するタイマ処理の起動の制御指示を行う（Ｓ２０５、Ｓ２０７）。そして、ＡＰＩ処理部３２は、その制御指示の内容を記述した制御指示を共有メモリ３６に格納する（Ｓ２０６、Ｓ２０８）。

その後、スレッド３１−１は、周期起動して周期起動Ｂ６０１の処理（ステップＳ２０９〜Ｓ２１２の処理）を実行する。

周期起動Ｂ６０１において、スレッド３１−１は、まず、共有メモリ３６の内容を確認して自己への制御指示が格納されていることを認識し、当該制御指示を取得する（Ｓ２０９）。

そして、スレッド３１−１は、取得した制御指示の内容に基づいて、音声ファイルＦ１の再生停止処理を行う（Ｓ２１０）。そして、音声ファイルＦ１の再生停止処理を行うと、スレッド３１−１は、イベントキュー３３に、再生停止処理を実行した旨のイベントを通知する（Ｓ２１１）。

そして、スレッド３１−１は、取得した制御指示の内容に基づいて、タイマ処理部３１１のカウンタ値を初期化（０）して起動し、５ｓｅｃの計時（カウンタ値が２５０となるまでの計時）を行うタイマ処理を開始させる（Ｓ２１２）。以上で、スレッド３１−１による周期起動Ｂ６０１での処理が終了する。

そして、再生処理停止のイベントが通知されたイベントキュー３３は、そのイベントを保持して、アプリケーション４０に通知する（Ｓ２１３）。

そして、スレッド３１−１は、その後周期起動を繰り返し、周期起動の度にタイマ処理部３１１のカウンタ値をインクリメントする。そして、スレッド３１−１は、タイマ処理部３１１のカウンタ値が２４９に達した状態で、周期起動Ｂ６０１から数えて２４９回目の周期起動Ｂ８５０を迎えたものとする。周期起動Ｂ８５０において、スレッド３１−１は、後述するステップＳ３０１、Ｓ３０２の処理を実行する。

周期起動Ｂ８５０では、スレッド３１−１は、タイマ処理部３１１のカウンタ値をインクリメントする処理を行う。そして、この時点で、スレッド３１−１において、タイマ処理部３１１のカウンタ値は２５０となり、タイマ処理部３１１のタイムアウトを検出することになる（Ｓ３０１）。そして、スレッド３１−１は、タイマ処理部３１１のタイムアウトを検出すると、タイムアウトイベントを、イベントキュー３５に供給する（Ｓ３０２）。以上で、スレッド３１−１による周期起動Ｂ８５０での処理が終了する。

なお、周期起動Ｂ６０１〜Ｂ８５０の間は、スレッド３１−１は、無音の音声データの再生処理（周期起動ごとに２０ｍｓｅｃ分の無音の音声データの再生処理）を行うようにしてもよい。ただし、端末２−１側で、ＲＴＰパケットが供給されない間無音の音声を出力する構成となっている場合には、上述のようなスレッド３１−１からの無音の音声に係る再生処理は必要ない。

そして、イベントキュー３５は、供給されたタイムアウトイベントを、コールバックスレッド３４に供給する。そして、コールバックスレッド３４は、供給されたタイムアウトイベントに対応するコールバック処理を、アプリケーション４０（コールバック処理部４１）に要求する（Ｓ３０３）。ここでは、アプリケーション４０（コールバック処理部４１）には、スレッド３１−１に対する次のコールバック処理として、音声ファイルＦ１の再生開始の制御、及び、１０ｓｅｃを計時するタイマ処理の起動制御が設定されているものとする。

そして、アプリケーション４０（コールバック処理部４１）は、次のコールバック処理の設定に従って、ＡＰＩ処理部３２に対して、音声ファイルＦ１の再生開始の制御、及び、１０ｓｅｃを計時するタイマ処理の起動制御の制御指示を行う（Ｓ３０４、Ｓ３０６）。そして、ＡＰＩ処理部３２は、その制御指示の内容を記述した制御指示を共有メモリ３６に格納する（Ｓ３０５、Ｓ３０７）。

その後、スレッド３１−１は、周期起動して周期起動Ｂ８５１の処理（ステップＳ３０８〜Ｓ３１０の処理）が実行される。

周期起動Ｂ８５１において、スレッド３１−１は、まず、共有メモリ３６の内容を確認して自己への制御指示が格納されていることを認識し、当該制御指示を取得する（Ｓ３０８）。

そして、スレッド３１−１は、取得した制御指示の内容に基づいて、タイマ処理部３１１のカウンタ値を初期化（０）して起動し、１０ｓｅｃの計時（カウンタ値が５００となるまでの計時）を行うタイマ処理を開始させる（Ｓ３０９）。

そして、スレッド３１−１は、取得した制御指示の内容に基づいて、音声ファイルＦ１の再生処理を開始し、音声ファイルＦ１の最初の２０ｍｓｅｃ分の音声の音声データについて再生処理を行う。また、スレッド３１−１は、タイマ処理部３１１のカウンタ値をインクリメントする処理を行う（Ｓ３１０）。

そして、音声ファイルＦ１の再生処理を開始すると、スレッド３１−１は、イベントキュー３３に、再生処理を開始した旨のイベントを通知する（Ｓ３１１）。以上で、スレッド３１−１による周期起動Ｂ８５１での処理が終了する。

そして、再生開始処理のイベントが通知されたイベントキュー３３は、そのイベントを保持して、アプリケーション４０に通知する（Ｓ３１２）。

そして、スレッド３１−１は、周期起動により再生処理を繰り返し、タイマ処理部３１１のカウンタ値が４９９に達した状態で、周期起動Ｂ８５１から数えて５００回目の周期起動Ｂ１３５０を迎えたものとする。周期起動Ｂ１３５０において、スレッド３１−１は、後述するステップＳ４０１〜Ｓ４０３の処理を実行する。

周期起動Ｂ１３５０では、スレッド３１−１は、音声ファイルＦ１の、次の２０ｍｓｅｃ分の音声の音声データについて再生処理を行い、さらに、タイマ処理部３１１のカウンタ値をインクリメントする処理を行う（Ｓ４０１）。そして、この時点で、スレッド３１−１において、タイマ処理部３１１のカウンタ値は５００となり、タイマ処理部３１１のタイムアウトを検出することになる（Ｓ４０２）。そして、スレッド３１−１は、タイマ処理部３１１のタイムアウトを検出すると、タイムアウトイベントを、イベントキュー３５に供給する（Ｓ４０３）。以上で、スレッド３１−１による周期起動Ｂ１３５０での処理が終了する。

そして、イベントキュー３５は、供給されたタイムアウトイベントを、コールバックスレッド３４に供給する。そして、コールバックスレッド３４は、供給されたタイムアウトイベントに対応するコールバック処理を、アプリケーション４０（コールバック処理部４１）に要求する（Ｓ４０４）。ここでは、アプリケーション４０（コールバック処理部４１）には、スレッド３１−１に対する次のコールバック処理として、音声ファイルＦ１の再生停止の制御が設定されているものとする。

そして、アプリケーション４０（コールバック処理部４１）は、次のコールバック処理の定義に従って、ＡＰＩ処理部３２に対して、音声ファイルＦ１の再生停止の制御指示を行う（Ｓ４０５）。そして、ＡＰＩ処理部３２は、その制御指示の内容を記述した制御指示を共有メモリ３６に格納する（Ｓ４０６）。

その後、スレッド３１−１は、周期起動して周期起動Ｂ１３５１の処理（ステップＳ４０７〜Ｓ４０９の処理）が実行される。

周期起動Ｂ１３５１において、スレッド３１−１は、まず、共有メモリ３６の内容を確認して自己への制御指示が格納されていることを認識し、当該制御指示を取得する（Ｓ４０７）。

そして、スレッド３１−１は、取得した制御指示の内容に基づいて、音声ファイルＦ１の再生停止処理を行う（Ｓ４０８）。そして、音声ファイルＦ１の再生停止処理を行うと、スレッド３１−１は、イベントキュー３３に、再生停止処理を実行した旨のイベントを通知する（Ｓ４０９）。以上で、スレッド３１−１による周期起動Ｂ６０１での処理が終了する。

そして、再生処理停止のイベントが通知されたイベントキュー３３は、そのイベントを保持して、アプリケーション４０に通知する（Ｓ４１０）。

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

（Ａ−３−１）データ処理装置１では、スレッド３１の側で、タイマ処理部３１１のカウンタを用いたタイマ処理を実行するようにしたので、正確な再生タイミング制御が可能である。

また、スレッド３１のタイマ処理部３１１において、周期起動ごとにカウンタをインクリメントしていくだけでタイマ処理を行うことができる。すなわち、データ処理装置１では、アプリケーション４０側で、タイマ処理に係る処理を実装する必要がなく、タイマ処理の追加による処理負荷増加はほとんど発生しない。

（Ａ−３−２）データ処理装置１では、スレッド３１からアプリケーション４０へのタイマイベントに伴うコールバック処理専用の伝達経路（コールバックスレッド３４及びイベントキュー３５）が設定されている。これにより、データ処理装置１では、シンプルな構成で迅速にタイムアウトイベントに伴うコールバック処理を実行することができる。すなわち、データ処理装置１では、効率的にタイムアウトイベントに伴うコールバック処理を実行することができる。

なお、データ処理装置１において、上述のコールバック処理専用の伝達経路を省略するようにしてもよいが、その場合、コールバック処理と同様の処理の効率が低下することになる。例えば、スレッド３１から、イベントキュー３３を介して、アプリケーション４０にタイムアウトイベントの発生（例えば、音声ファイルの再生開始後にタイムアウトが発生した旨のイベント）を通知し、アプリケーション４０側でそのイベントの内容を解析して次の処理（例えば、音声ファイル再生の停止の処理）を決定して、ＡＰＩ処理部３２経由でスレッド３１に命令するようにしてもよい。しかし、この場合、アプリケーション４０でのイベント解析や、判断処理が必要になるため、上述のコールバック処理に係る伝達経路の方が、少ない処理量で高速に次の処理を実行することが可能になる。

また、タイムアウトイベント以外のイベントについてもイベントキュー３３に集中させる場合、イベントキュー３３がボトルネックとなって処理が遅延する可能性がある。しかし、データ処理装置１のようにタイムアウトイベント専用の伝達経路を備えることにより、シンプルな構成で迅速にタイムアウトイベントに伴うコールバック処理を実行することができる。さらに、コールバック処理に対応する処理をメディアデータ処理部３０内部だけで行う構成としてもよいが、アプリケーション４０からＡＰＩを用いてコールバックする伝達経路の方が、メディアデータ処理部３０内の構成をシンプルにすることができる。

言い換えると、データ処理装置１では、コールバックスレッド３４を追加したことにより、コールバック処理部４１からＡＰＩ制御を実行することができるので、アプリケーション４０の実装が容易である。特に、メディアデータ処理部３０をミドルウェアとして実現した場合、アプリケーション４０に影響を与えずに、ミドルウェア（メディアデータ処理部３０）のバージョンアップを行うことが容易となる。

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

（Ｂ−１）上記の実施形態では、データ処理装置１において、音声ファイルの再生タイミングの制御を例として説明したがそれ以外のタイミング制御（例えば、動画像の再生タイミング等）に利用するようにしてもよい。

（Ｂ−２）上記の実施形態では、イベントキュー３５は、タイムアウトイベント専用のキューとして説明したが、イベントキュー３３とイベントキュー３５の割り振りは異なるものであってもよい。例えば、イベントキュー３３を省略した構成としてもよい。

また、上記の実施形態では、コールバックスレッド３４は１つの構成として説明したが複数としてもよい。

（Ｂ−３）上記の実施形態では、メディアデータ処理部３０、アプリケーション４０、及びシグナリング処理部５０が同じコンピュータ上に構築された例について説明したが、それぞれ異なるコンピュータ上に構築するようにしてもよい。すなわち、データ処理装置１を構築する際の分散処理の構成は限定されないものである。

１…データ処理装置、１０…ハードウェア、２０…汎用ＯＳ、３０…メディアデータ処理部、３１…スレッド、３１１…タイマ処理部、３１、３１−１〜３１−Ｎ…スレッド、３２…ＡＰＩ処理部、３３…イベントキュー、３４…コールバックスレッド、３５…イベントキュー、３６…共有メモリ、４０…アプリケーション、４１…コールバック処理部、５０…シグナリング処理部。

Claims

アプリケーション処理手段の制御に応じて、メディアデータの処理を行うメディアデータ処理手段を備え、
上記メディアデータ処理手段は、
周期的に起動して、メディアデータの再生及び再生停止を行うデータ処理手段と、
上記データ処理手段が起動する度にカウンタ値が加算されるカウンタを用いて時間の計測を行うタイマ手段とを備え、
上記データ処理手段は、上記アプリケーション処理手段の制御に応じて、当該データ処理手段が行う上記再生及び上記再生停止に係る時間計測を、上記タイマ手段を用いて行い、
上記データ処理手段は、上記アプリケーション処理手段から指定される、メディアデータを再生または再生停止する処理時間に亘り周期的に起動して処理を行うとともに、上記タイマ手段に当該処理時間をタイムアウト時間とする時間の計測を実行させ、上記タイマ手段でタイムアウトが発生した場合のタイムアウトイベントを出力し、
上記メディアデータ処理手段は、
それぞれの上記データ処理手段で発生した、タイムアウトイベントのみを処理する第１のイベント処理手段と、
それぞれの上記データ処理手段で発生したタイムアウトイベント以外のイベントを処理する第２のイベント処理手段と、
上記第１のイベント処理手段でタイムアウトイベントが保持されると、当該タイムアウトイベントに係る上記データ処理手段への所定の処理を、上記アプリケーション処理手段に要求するコールバック要求処理手段をさらに備えることを特徴とするデータ処理装置。
コンピュータを、
アプリケーション処理手段の制御に応じて、メディアデータの処理を行うメディアデータ処理手段として機能させ、
上記メディアデータ処理手段は、
周期的に起動して、メディアデータの再生及び再生停止を行うデータ処理手段と、
上記データ処理手段が起動する度にカウンタ値が加算されるカウンタを用いて時間の計測を行うタイマ手段とを備え、
上記データ処理手段は、上記アプリケーション処理手段の制御に応じて、当該データ処理手段が行う上記再生及び上記再生停止に係る時間計測を、上記タイマ手段を用いて行い、
上記データ処理手段は、上記アプリケーション処理手段から指定される、メディアデータを再生または再生停止する処理時間に亘り周期的に起動して処理を行うとともに、上記タイマ手段に当該処理時間をタイムアウト時間とする時間の計測を実行させ、上記タイマ手段でタイムアウトが発生した場合のタイムアウトイベントを出力し、
上記メディアデータ処理手段は、
それぞれの上記データ処理手段で発生した、タイムアウトイベントのみを処理する第１のイベント処理手段と、
それぞれの上記データ処理手段で発生したタイムアウトイベント以外のイベントを処理する第２のイベント処理手段と、
上記第１のイベント処理手段でタイムアウトイベントが保持されると、当該タイムアウトイベントに係る上記データ処理手段への所定の処理を、上記アプリケーション処理手段に要求するコールバック要求処理手段と
をさらに備えることを特徴とするデータ処理プログラム。