(57)【要約】【課題】複数のデータ処理における冗長度を低減させることにより、開発コストやテスト工数を減少させることのできるデータ送受信装置を提供することを目的とする。【解決手段】データ送受信装置１１において、Ｎ個の処理部Ｐｄ＿１〜Ｐｄ＿Ｎが介在し、パイプライン方式でデータ転送を行う。データ送受信装置１１において、（Ｎ−１）個以上の中継部２１は、データの送受信を制御する送受信制御部２３と、バッファ２７とを備え、隣接する第１のデータ処理部Ｐｄ＿１と第２のデータ処理部Ｐｄ＿２とを接続して、第１のデータ処理部Ｐｄ＿１による処理結果であるデータを第２のデータ処理部に伝送させる。第１のデータ処理部Ｐｄ＿１において、送信ＡＰＩ３５ａは、第２のデータ処理部Ｐｄ＿２にデータを送信する。第２のデータ処理部Ｐｄ＿２において、受信ＡＰＩ３７ｂは、第２のデータ処理部Ｐｄ＿２から送信されたデータを受信する。【選択図】        図３
2004310545.tif 000002
【特許請求の範囲】
【請求項１】
それぞれデータ処理を行う、２以上の第１の所定数の処理手段を介在させて、パイプライン方式でデータ転送を行うデータ送受信装置であって、
前記複数のデータ処理手段の内で隣接する第１のデータ処理手段と第２のデータ処理手段とを接続して、第１のデータ処理手段による処理結果であるデータを第２のデータ処理部に伝送させる、前記第１の所定数より１だけ小さい第２の所定数以上の中継手段を備え、
前記第１のデータ処理手段は、前記中継手段に接続されて、前記第２のデータ処理手段に対して前記データを送信する送信手段を備え、
前記第２のデータ処理手段は、前記中継手段に接続されて、前記第２のデータ処理手段から送信されたデータを受信する受信手段を備え、
前記中継手段は、前記データの送受信を制御する送受信制御手段と
前記データを一時的に保持するバッファとを備える、データ送受信装置。
【請求項２】
前記送信手段は、前記バッファにおいてデータが保持されていないアドレスを取得して、当該アドレスにデータの書き込みを行う書込手段を備え、
前記受信手段は、前記バッファにおいてデータが保持されているアドレスを取得して、当該アドレスからデータを読み出す読出手段とを備える請求項１に記載のデータ送受信装置。
【請求項３】
前記第１の所定数のデータ処理手段のそれぞれは、互いに独立に動作する能動処理手段および互いに同期して動作する受動処理手段の少なくとも一方を備え、
前記中継手段は、前記第１のデータ処理手段と前記第２のデータ処理手段が前記能動処理手段と前記受動手段の何れを備えているかを検出してデータキューを生成するか否かを判定するデータキュー生成判定手段を備え、
前記データキューが生成されない場合に、前記中継手段は前記第１のデータ処理手段からのデータ送信要求と同時に、前記第２のデータ処理手段にデータを受信させることを特徴とする請求項１に記載のデータ送受信装置。
【請求項４】
前記第１のデータ処理手段および前記第２のデータ処理手段が共に同一のタスク或いは同一のスレッドで動作する場合は、前記データキューは生成されないことを特徴とする請求項３に記載のデータ送受信装置。
【請求項５】
前記データ送信要求および前記データ受信要求は、前記データキューが生成されるか否かに関わらず共通であることを特徴とする、請求項３および請求項４のいずれかにに記載のデータ送受信装置。
【請求項６】
前記第２の所定数が２以上の場合、前記第２の所定数の中継手段は、同一の機能を有することを特徴とする、請求項１乃至５に記載のデータ送受信装置。
【請求項７】
請求項１に記載のデータ送受信装置において、データ伝送を実現する方法であって、
前記第１のデータ処理手段を、前記中継手段に接続させる第１の接続ステップと、
前記第２のデータ処理手段を、前記中継手段に接続される第２の接続ステップと、
前記バッファにおけるデータが保持されていない第１のアドレスを取得する未記録アドレス取得ステップと、
前記第１のアドレスに、前記第１のデータ処理部からのデータを書き込む送信ステップと、
前記バッファにおいてデータが保持されている第２のアドレスを取得する既記録アドレス取得ステップと、
前記第２のアドレスから、保持されているデータを読み出す受信ステップとを備えるデータ送受信方法。
【請求項８】
請求項３に記載のデータ送受信装置において、データ伝送を実現する方法であって、
前記第１のデータ処理手段と前記第２のデータ処理手段が前記能動処理手段と前記受動手段の何れを備えているかを判定する能動／受動判定ステップと、
前記能動／受動判定ステップにおける判定結果に基づいて、データキューを生成するか否かを判定するデータキュー生成判定ステップと、
前記データキューが生成されないと判定された場合に、前記第１のデータ処理手段からのデータ送信要求と同時に、前記第２のデータ処理手段にデータを受信させる第１の送受信制御ステップとを備える請求項７に記載のデータ送受信方法。
【請求項９】
前記データキューが生成されないと判定された場合に、前記第１のデータ処理手段からのデータ送信要求と同時に、前記第２のデータ処理手段にデータを受信させる第２の送受信制御ステップを
備える請求項８に記載のデータ送受信方法。
【請求項１０】
前記第１のデータ処理手段および前記第２のデータ処理手段が共に同一のタスク或いは同一のスレッドで動作する場合は、前記データキューは生成されないと判定されることを特徴とする請求項８に記載のデータ送受方法。
【請求項１１】
請求項７、請求項８、請求項９および請求項１０のいずれかに記載のデータ伝送方法を実行するコンピュータプログラムが記録された記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、マルチメディアデータ変換技術に関し、より特定的には、パイプライン方式により、データを変換するための技術に関する。
【０００２】
【従来の技術】
映像や音声等のマルチメディアデータを保存あるいは伝送する場合、一般的に、データの形態変換が行われる。データの形態変換には、例えば、圧縮、多重化、および符号化の種々の処理が含まれる。これらデータの形態変換を、処理ごとにコンポーネント化し、連続的に処理する方式をパイプライン方式という。パイプライン方式においては、他のコンポーネントとデータの送受信をするために、データ送受信の末端に位置するコンポーネントは、それぞれ送信制御部または受信制御部のいずれかを備える。そして、末端に位置しないコンポーネントは送信制御部および受信制御部の両方を備える必要がある。
【０００３】
図１３に、マルチメディアデータの形態変換の機能をソフトウェアで実現する従来のデータ送受信装置のハードウェア構成を示す。データ送受信装置１１１は、ＣＰＵ１１３と、ＲＯＭ１１７と、ＲＡＭ１１５とを含む。ＲＯＭ１１７には、マルチメディアデータの形態変換を含む種々の機能を実現するプログラムが格納されている。ＣＰＵ１１３は、ＲＯＭ１１７からマルチメディアデータ変換機能の実装プログラムを読み出す。そして、ＣＰＵ１１３は、読み出したマルチメディアデータ変換機能の実装プログラムを、ＲＡＭ１１５に展開して、データ送受信装置をソフトウェア的に実現する。
【０００４】
なお、説明の簡便化のために、ＲＯＭ１１７に格納されているマルチメディアデータ変換機能の実装プログラムをデータ送受信装置実装プログラムＰＧｏと呼称し、ＲＡＭ１１５に展開されたマルチメディアデータ変換機能をデータ送受信装置展開プログラムＰＧｒと呼称する。
【０００５】
図１４に、ＲＯＭ１１７に格納されているデータ送受信装置実装プログラムＰＧｏを模式的に示す。データ送受信装置実装プログラムＰＧｏは、上述の処理ごとのコンポーネントにそれぞれ対応するＮ個のデータ処理部Ｐｄｃ＿１〜Ｐｄｃ＿Ｎを含む。なお、Ｎは任意の自然数であり、Ｎ個のデータ処理部Ｐｄｃ＿１〜Ｐｄｃ＿Ｎをデータ処理部Ｐｄｃと総称する。
【０００６】
データ処理部Ｐｄｃはそれぞれ、基本的に、送信部１５１と受信部１５３を含む。しかしながら、末端に位置するデータ処理部Ｐｄｃ＿１およびＰｄｃ＿Ｎはそれぞれ、送信部１５１＿１と受信部１５３＿Ｎのみを含む。つまり、データ送受信装置実装プログラムＰＧｏには、（Ｎ−１）個の送信部１５１＿１〜１５１＿（Ｎ−１）と（Ｎ−１）個の受信部１５３＿２〜１５３＿Ｎが含まれる。言い換えれば、データ送受信装置実装プログラムＰＧｏには、実質的には、Ｎ個ではなく（Ｎ−１）個のデータ処理部Ｐｄｃが含まれる。なお、データ送受信装置展開プログラムＰＧｒも、図１３に示したデータ送受信装置実装プログラムＰＧｏと全く同様にＲＡＭ１１５に展開されるので、説明を省く。
【０００７】
図１５を参照して、ＲＯＭ１１７に格納されたデータ送受信装置実装プログラムＰＧｏと、ＲＡＭ１１５に展開されたデータ送受信装置展開プログラムＰＧｒの詳細について説明する。同図においては、説明の簡便化の為に、データ送受信装置実装プログラムＰＧｏは、第１のデータ処理部Ｐｄｃ＿１、第２のデータ処理部Ｐｄｃ＿２、および第３のデータ処理部Ｐｄｃ＿３を含む例が示されている。この場合、端末に位置する第１のデータ処理部Ｐｄｃ＿１と第３のデータ処理部Ｐｄｃ＿３には、それぞれ送信部１５１ｄと受信部１５３ｆのみが含まれる。そして、第２のデータ処理部Ｐｄｃ＿２には、受信部１５３ｅと送信部１５１ｅの両方が含まれる。つまり、２つの送信部１５１ｄおよび１５１ｅと、２つの受信部１５３ｅおよび１５３ｆが含まれている。このように、実質２つのデータ処理部Ｐｄｃが含まれている。
【０００８】
なお、本例において、第１のデータ処理部Ｐｄｃ＿１は、外部に設けられたデータ源から供給されるデータストリームが入力されるストリーム入力部である。第２のデータ処理部Ｐｄｃ＿２は、第１のデータ処理部Ｐｄｃ＿１（ストリーム入力部）を介して供給されたデータストリームをデコードして、デコード結果を出力するデコード部である。そして、第３のデータ処理部Ｐｄｃ＿３は、第２のデータ処理部Ｐｄｃ＿２（デコード部）より出力されたデコード結果を外部に設けられた出力機器に適した形態で出力する出力部である。これらのストリーム入力処理、デコード処理、および出力処理は公知の手段および方法によって実現されるので説明を省くと共に、本発明の特徴であるデータ送受信に関して重点的に説明する。
【０００９】
以下に、オーディオストリームが入力される場合を例にデータ変換処理について説明する。第１のデータ処理部Ｐｄｃ＿１は、メディア（図示せず）からオーディオストリームを取得すると、送信部１５１ｄを介して第２のデータ処理部Ｐｄｃ＿２の受信部１５３ｅにオーディオストリームを送信する。第２のデータ処理部Ｐｄｃ＿２は、第１のデータ処理部Ｐｄｃ＿１からオーディオストリームを受け取ると、オーディオストリームをデコードして通常のオーディオデータ（以下、実オーディオデータ）を生成する。その後、実オーディオデータは、送信部１５１ｅを介して第３のデータ処理部Ｐｄｃ＿３の受信部１５３ｆに送信される。第３のデータ処理部Ｐｄｃ＿３は、第２のデータ処理部Ｐｄｃ＿２から実オーディオデータを受け取ると、受け取った実オーディオデータを音声として出力する。
【００１０】
送信部１５１ｄは、バッファ１２７ｄ、送信制御部１２９ｄ、および送信ＡＰＩ１３５ｄを含む。同様に、送信部１５１ｅは、バッファ１２７ｅ＿１、送信制御部１２９ｄ、および送信ＡＰＩ１３５ｄを含む。
そして、受信部１５３ｅは、バッファ１２７ｅ＿１、および受信ＡＰＩ１３７ｅを含む。同様に、受信部１５３ｆは、バッファ１２７ｆ、および受信ＡＰＩ１３７ｆを含む。
【００１１】
なお、バッファ１２７は、全ての送信部１５１および受信部１５３に備えられる必要はなく、データを送信する送信部１５１と、データを受信する受信部１５３とのどちらかに含まれていればよい。例えば、第２のデータ処理部Ｐｄｃ＿２の送信部１５１がバッファ１２７を含んでいる場合、第２のデータ処理部Ｐｄｃ＿２からデータを受け取る第３のデータ処理部Ｐｄｃ＿３の受信部１５３は、バッファ１２７を含まなくともよい。
【００１２】
図１６に、データの送受信を同期的および非同期の両方に対応して行う場合のデータ送受信装置実装プログラムＰＧｏと、ＲＡＭ１１５に展開されたデータ送受信装置展開プログラムＰＧｒを更に詳細に説明する。パイプライン処理においても、データの送受信は同期的に行われる場合もあれば、非同期に行われる場合もある。
【００１３】
同期的にデータの送受信を行う場合、送信部１５１および受信部１５３はそれぞれ、タスク接続部１６１をさらに備える。また、非同期にデータの送受信を行う場合、送信部１５１および受信部１５３はそれぞれ、ライブラリ接続部１６３をさらに備える。よって、同期的データの送受信および非同期データの送受信の両方に対応する場合、送信部１５１および受信部１５３は、タスク接続部１６１およびライブラリ接続部１６３の両方を同時に備える。なお、同図においては、説明の簡便化の為に、図１５に示したバッファ１２７、送信制御部１２９および送信ＡＰＩ１３５が省略されている。
【００１４】
また、本例においては、図１５に示した第１のデータ処理部Ｐｄｃ＿１、第２のデータ処理部Ｐｄｃ＿２、および第３のデータ処理部Ｐｄｃ＿３は、それぞれ、第４のデータ処理部Ｐｄｃ＿４、第５のデータ処理部Ｐｄｃ＿５、および第６のデータ処理部Ｐｄｃ＿６に置き換えられている。
【００１５】
第４のデータ処理部Ｐｄｃ＿４は、基本的に、第１のデータ処理部Ｐｄｃ＿１の送信部１５１ｄにタスク接続部１６１ｇとライブラリ接続部１６３ｇが追加されている。同様に、第５のデータ処理部Ｐｄｃ＿５は、第２のデータ処理部Ｐｄｃ＿２の受信部１５３ｅにタスク接続部１６１ｈ＿１とライブラリ接続部１６３ｈ＿１が追加され、送信部１５１ｈにタスク接続部１６１ｈ＿２とライブラリ接続部１６３ｈ＿２が追加されている。第６のデータ処理部Ｐｄｃ＿６の受信部１５３ｉには、タスク接続部１６１ｉとライブラリ接続部１６３ｉが追加されている。
【００１６】
第４のデータ処理部Ｐｄｃ＿４によるストリームの取得と、第５のデータ処理部Ｐｄｃ＿５によるストリームのデコードとは、タスク数を抑制するために、一般的には同期的に行われる。なお、別タスクによって非同期的に行うことも可能である。同期的に処理を行う場合、第５のデータ処理部Ｐｄｃ＿５は、自立的にタスクを起動する、いわゆる能動データ処理部であり、第４のデータ処理部Ｐｄｃ＿４は、第２のデータ処理部Ｐｄｃ＿２のタスクと同期して動作する、いわゆる受動データ処理部である。
【００１７】
一方、第５のデータ処理部Ｐｄｃ＿５によるストリームのデコードと、第６のデータ処理部Ｐｄｃ＿６によるデータの読み出しとは、一般的には非同期に行われる。第６のデータ処理部Ｐｄｃ＿６から出力される実オーディオデータは、タイマー（図示せず）の割り込みに従って等間隔で出力されなければならない。一方、第５のデータ処理部Ｐｄｃ＿５によるデコードは、処理タイミングにジッタ（遅延）が生じる場合がある。このジッタを吸収するために、一般的には、第５のデータ処理部Ｐｄｃ＿５と第６のデータ処理部Ｐｄｃ＿６の間にデータキューを設けて、第５のデータ処理部Ｐｄｃ＿５からのデータの書き込みと、第６のデータ処理部Ｐｄｃ＿６からのデータの読み出しとを非同期に行う。
【００１８】
図１７に、データキューを設けて、データの書き込みおよび読み出しを非同期に行う方法について簡単に説明する。なお、本例においては、第５のデータ処理部Ｐｄｃ＿５の送信部１５１ｈ或いは第６のデータ処理部Ｐｄｃ＿６の受信部１５３ｉの何れか一方に、データキュー１２５と参照テーブル２２９が設けられる。参照テーブル２２９には、データキュー１２５のバッファ情報が記録されている。非同期に処理を行う場合、第５のデータ処理部Ｐｄｃ＿５と第６のデータ処理部Ｐｄｃ＿６とは、両方とも自立的にタスクを起動する能動データ処理部である。
【００１９】
図１８を用いて、第２のデータ処理部Ｐｄｃ＿２（デコード部）と第３のデータ処理部Ｐｄｃ＿３（出力部）との間のデータ送受信の動作について説明する。第２のデータ処理部Ｐｄｃ＿２と第３のデータ処理部Ｐｄｃ＿３との間でデータ伝送を行うために、一方の送信部、もしくは他方の受信部から接続要求を行う必要がある。ここで、送信部１５１ｅから受信部１５３ｆに対して接続要求が行われるものとする（１１０１）。
【００２０】
続いて、両者間のデータ伝送に使用するデータキュー１２５をどちら側が確保するかを折衝する（１１０２）。折衝の結果を元に、データキュー１２５の生成判定を行う（１１０３）。ここで、送信部１５１ｅがデータキュー１２５を確保すると判定されるものとする。上記判定結果を受け、送信部１５１ｅは、データキュー１２５の確保、および参照テーブル２２９を作成する（１１０４）。第２のデータ処理部Ｐｄｃ＿２は、デコードされた実オーディオを送信するために、送信部１５１ｅに対してバッファの要求を行う（１１０５）。これにより送信部１５１ｅは、参照テーブル２２９を検索して、空きバッファがあればそのアドレスを第２のデータ処理部Ｐｄｃ＿２に通知する（１１０５ｒ）。
第２のデータ処理部Ｐｄｃ＿２は、上記通知されたアドレスに対して送信すべきデータ（ここでは実オーディオデータ）を書き込む（１１０６）。データ書き込みが終了すると、送信部１５１ｅは参照テーブル２２９の更新を行う（１１０７）。
【００２１】
第３のデータ処理部Ｐｄｃ＿３がデータを受信しようとするとき、受信部１５３ｆは送信部１５１ｅに対してデータ読み出し要求を行う（１１０８）。これにより送信部１５１ｅは、参照テーブル２２９を検索して、次に出力すべきバッファ、すなわち、データキュー１２５内に確保されているデータのなかでもっとも古いタイムスタンプを持つデータが保持されているバッファのアドレスを受信部１５３ｆに通知する（１１０８ｒ）。受信部１５３ｆは、上記アドレスから受信すべきデータを読み出し（１１０９）、そのデータを出力することで、音声が再生される。データ読み出しが終了すると、受信部１５３ｆは送信部１５１ｅに対しバッファを返却する（１１１０）。これを受けて、送信部１５１ｅは返却されたバッファを空きバッファとするよう、参照テーブル２２９の更新を行う（１１１１）。
【００２２】
図１５に示したデータ送受信装置展開プログラムＰＧｒ（データ送受信装置実装プログラムＰＧｏ）においては、メディア９０１ａからのストリーム読み出しと、ストリームのデコードとは、別タスクにより非同期的に行うことも、同一タスクにより同期的に行うことも可能である。通常タスク数が増加すると、動作のためのリソースが余分に必要となるので、特に理由がなければ同期的に動作させることが一般的である。この例において、第２のデータ処理部Ｐｄｃ＿２は、自立的にタスクを起動する能動データ処理部となり、第１のデータ処理部Ｐｄｃ＿１ストリーム入力部）は、第２のデータ処理部Ｐｄｃ＿２のタスクと同期して動作する受動データ処理部となる。この場合、両データ処理部間に、データを一時的に保持するデータキュー１２５は必要ない。
【００２３】
図１９を用いて、第１のデータ処理部Ｐｄｃ＿１（ストリーム入力部）と第２のデータ処理部Ｐｄｃ＿２（デコード部）との間のデータ送受信の動作について説明する。
【００２４】
受信部１５３ｅは、送信部１５１ｄに対し、接続要求を行う（１３０１）。続いて、両者間のデータ伝送に使用するデータキュー１２５の確保について折衝する（１３０２）。折衝の結果を元に、データキュー１２５を生成するか否かを判定する（１３０３）。この場合、両データ処理部が同期して動作するので、データキュー１２５を生成しないと判定される。
【００２５】
データ読み出し要求は能動データ処理部が行うため、第２のデータ処理部Ｐｄｃ＿２からデータ読み出し要求がなされる（１３０４）。データ読み出し要求を受けた受信部１５３ｅは、両データ処理部が同期して動作するので、前記データ読み出し要求を直接送信部１５１ｄに送信する（１３０５）。
【００２６】
送信部１５１ｄは、データ読み出し要求を受けると、次に送信すべきデータのアドレスを受信部１５１ｅに通知する（１３０６）。受信部１５１ｅは第２のデータ処理部Ｐｄｃ＿２に上記データアドレスを通知する（１３０７）。第２のデータ処理部Ｐｄｃ＿２は、通知されたアドレスからデータ読み出しを行った（１３０８）後、読み出し完了通知を受信部１５３ｅに送る（１３０９）。
【００２７】
本発明に関連する先行技術として、特開平１０−２８３１９９号公報が存在する。この公報では、パイプライン方式における一連のデータ変換処理をコンピュータなどのソフトウェア上で実現する技術について開示している。この技術によれば、入力、逆多重化、伸張などの単一のデータ処理をコンポーネント化し、所望の形態変換を行うために、必要な処理コンポーネントを組み合わせて、変換処理をパイプライン方式で逐次的に行うことができる。
【００２８】
【特許文献１】
特開平１０−２８３１９９号公報
【００２９】
【発明が解決しようとする課題】
コンポーネント化したデータ処理部Ｐｄｃが連続して処理を行うことで、パイプライン方式のデータ処理が可能となる。しかしながら、各データ処理部Ｐｄｃは、他のコンポーネントとデータの送受信をするために、データ送受信の末端に位置するデータ処理部Ｐｄｃは送信制御部または受信制御部のいずれかを備え、それ以外のデータ処理部Ｐｄｃは送信制御部および受信制御部を備える必要がある。
【００３０】
したがって、データ送受信装置１１１がＮ個のデータ処理部Ｐｄｃを含む場合、（Ｎ−１）組の送信部１５１および受信部１５３を備えなければならない。Ｎ個のデータ処理部Ｐｄｃに対して、送信部１５１および受信部１５３の組数が（Ｎ−１）となる理由は、パイプライン方式の末端に位置するデータ処理部Ｐｄｃは、送信部１５１または受信部１５３のいずれか一方のみを備えるからである。従って、パイプラインを構成するデータ処理部Ｐｄｃの数に応じて、備えるべき送信部１５１および受信部１５３の数が増大する。そのため、各データ処理部Ｐｄｃにおける送信部１５１および受信部１５３の実装サイズおよび実装コストが大きくなる。
【００３１】
各データ処理部Ｐｄｃの機能をハードウェアで実現する場合、実装とは、アレイなどのデバイスを意味する。各データ処理部Ｐｄｃをハードウェアで実現した場合、データ処理部Ｐｄｃの数が増加するに従ってデバイス数が増加し、さらにサイズや実装コストも大きくなる。
【００３２】
一方、各データ処理部Ｐｄｃの機能をソフトウェアで実現する場合、実装とは、ＲＯＭ１１７中のプログラムを意味する。各データ処理部Ｐｄｃをソフトウェアで実現するためには、実装プログラムを格納するために大容量のＲＯＭ１１７を必要とする。これは、モバイル機器等のＲＯＭ１１７サイズなどのリソースが限られている装置においては、致命的な欠陥となりうる。
【００３３】
さらに、上述のように、データ処理部Ｐｄｃは、自立的にタスクを起動する能動データ処理部と、タスクと同期して動作する受動データ処理部との２種類のデータ処理部に対応する場合がある。その場合、２種類の送信／受信機能を備えなければならないため、１種類の送信／受信機能を備える場合に比べて、上記のような実装コストやテスト工数が２倍になる。
【００３４】
また、新たにデータ処理部Ｐｄｃを追加する場合、既存の全てのデータ処理部Ｐｄｃとの接続について動作検証を行わなければならない。既存のデータ処理部Ｐｄｃの数が増加する程、テストに必要な工数が増大してしまう。
【００３５】
また、図１９を参照して説明したように、従来のデータ送受信装置１１１においては、データキュー確保に関する折衝、データキュー生成判定（能動データ処理部との接続の機能）、データキュー、およびバッファ管理データベースの作成、バッファ要求時の動作、データ書き込み、バッファ管理データベースの更新、読み出し要求時の動作、バッファの返却（受動データ処理部との接続の機能）、読み出し要求時の動作、アドレス通知時の動作、および読み出し完了通知時の動作という機能が実装される必要がある。そして、これらの機能が能動データ処理部と受動データ処理部で正しく接続されているかを確認する必要がある。また、従来のデータ処理装置において、接続の検証をするためのテスト工数はコンポーネント数に応じた数だけ必要となる。
【００３６】
それゆえに、本発明の目的は、複数のデータ処理における冗長度を低減させることにより、開発コストやテスト工数を減少させることのできるデータ送受信装置を提供することである。
【００３７】
【課題を解決するための手段および発明の効果】
本発明は、それぞれデータ処理を行う、２以上の第１の所定数の処理手段を介在させて、パイプライン方式でデータ転送を行うデータ送受信装置であって、
複数のデータ処理手段の内で隣接する第１のデータ処理手段と第２のデータ処理手段とを接続して、第１のデータ処理手段による処理結果であるデータを第２のデータ処理部に伝送させる、第１の所定数より１だけ小さい第２の所定数以上の中継手段を備え、
第１のデータ処理手段は、中継手段に接続されて、第２のデータ処理手段に対してデータを送信する送信手段を備え、
第２のデータ処理手段は、中継手段に接続されて、第２のデータ処理手段から送信されたデータを受信する受信手段を備え、
中継手段は、データの送受信を制御する送受信制御手段と
データを一時的に保持するバッファとを備える。
【００３８】
上述のように、本発明によれば、パイプライン方式でデータ転送を行う際、中継手段に受信機能および送信機能を集約することによって、複数のデータ処理における冗長度を低減させることができる。また、データ処理を制御するために必要なプログラム容量や製品の開発コスト、テスト工数を減少させることができる。
【００３９】
【発明の実施の形態】
（第１の実施形態）
図１を参照して、本発明にかかるマルチメディアデータの形態変換の機能をソフトウェアで実現するデータ送受信装置のハードウェア構成を示す。データ送受信装置１１は、例えば携帯電話やＰＤＡ、パーソナルコンピュータであって、画像データや動画データ、音声データ等のマルチメディアデータを扱う。本例においては、データ送受信装置１１は、ＣＰＵ１３と、ＲＡＭ１５と、ＲＯＭ１７とを含む。ＲＯＭ１１７には、マルチメディアデータの形態変換を含む種々の機能を実現するプログラムが格納されている。ＣＰＵ１３は、ＲＯＭ１７からマルチメディアデータ変換機能の実装プログラムを読み出す。そして、ＣＰＵ１３は、読み出したマルチメディアデータ変換機能の実装プログラムを、ＲＡＭ１５に展開して、データ送受信装置をソフトウェア的に実現する。
【００４０】
なお、説明の簡便化のために、ＲＯＭ１７に格納されているマルチメディアデータ変換機能の実装プログラムをデータ送受信装置実装プログラムＰｏと呼称し、ＲＡＭ１５に展開されたマルチメディアデータ変換機能をデータ送受信装置展開プログラムＰｒと呼称する。また、後述の第２の実施の形態にかかるデータ送受信装置展開プログラムＰｒと識別する為に、必要に応じて、第１および第２の本実施の形態に係るデータ送受信装置展開プログラムＰｒを、それぞれデータ送受信装置展開プログラムＰｒ１とデータ送受信装置展開プログラムＰｒ２と呼称する。
【００４１】
図２に、ＲＯＭ１７に格納されているデータ送受信装置実装プログラムＰＧｏを模式的に示す。データ送受信装置実装プログラムＰｏは、処理ごとのコンポーネントにそれぞれ対応するＮ個のデータ処理部Ｐｄ＿１〜Ｐｄ＿Ｎと１つの中継部２１＿ｍを含む。ｍは、１以上（Ｎ−１）以下の自然数である。Ｎ個のデータ処理部Ｐｄ＿１〜Ｐｄ＿Ｎをデータ処理部Ｐｄと総称する。つまり、ＲＯＭ１７には、Ｎ個のデータ処理部Ｐｄと、１つの中継部２１＿１とが記録されている。なお、中継部２１も、必要に応じて、第１の実施形態および後述の第２の実施形態に係る中継部２１を、それぞれ中継部２１ａおよび中継部２１ｂと識別呼称する。
【００４２】
データ処理部Ｐｄはそれぞれ、基本的に、送信ＡＰＩ３５と受信ＡＰＩ３７を含む。しかしながら、末端に位置するデータ処理部Ｐｄ＿１およびＰｄ＿Ｎはそれぞれ、送信ＡＰＩ３５＿１と受信ＡＰＩ＿Ｎのみを含む。つまり、データ送受信装置実装プログラムＰＧには、（Ｎ−１）個の送信ＡＰＩ＿１〜（Ｎ−１）と（Ｎ−１）個の受信ＡＰＩ＿２〜Ｎが含まれる。よって、データ送受信装置実装プログラムＰｏには、（Ｎ−１）組の送信ＡＰＩ３５と受信ＡＰＩ３７が含まれる。なお、送信ＡＰＩ３５および受信ＡＰＩ３７は、それぞれ、上述の従来のデータ処理部Ｐｄｃにおける送信ＡＰＩ１３５および受信ＡＰＩ１３７に相当する。
【００４３】
中継部２１は、後ほど図３を参照して説明するように、送受信制御部２３とバッファ２７を含む。送受信制御部２３は、従来のデータ処理部Ｐｄｃにおける送信部１５１の送信制御部１２９と、受信部１５３の受信制御部１３１を一体的に構成したものである。バッファ２７も、上述のバッファ１２７に相当する。
【００４４】
つまり、データ処理部Ｐｄは、従来のデータ処理部Ｐｄｃに比べて、バッファ１２７と、送信制御部１２９或いは受信制御部１３１が取り除かれている。そして、取り除かれた送信制御部１２９及び受信制御部１３１は送受信制御部２３に一体化されている。結果、データ送受信装置実装プログラムＰｏにおいては、データ処理部Ｐｄは、従来のデータ送受信装置実装プログラムＰＧｏにおけるのと同様に（Ｎ−１）個だけ備えられるが、そのサイズは（Ｎ−１）個の送信制御部１２９および受信制御部１３１が削減されている。
【００４５】
また、取り除かれた送信制御部１２９或いは受信制御部１３１は、１つだけの中継部２１に送受信制御部２３として一体化されている。よって、送信制御部１２９及び受信制御部１３１は、サイズ的におよそ１／（Ｎ−１）に削減されている。また、バッファ１２７も、中継部２１にバッファ２７として１つだけ設けられるので、１／２（Ｎ−１）に削減されている。なお、これら削減された要素の内で、送受信制御部２３の寄与がサイズ的に一番大きい。結果として、データ送受信装置実装プログラムＰｏはデータ送受信装置展開プログラムＰｒ１の１／（Ｎ−１）以下に削減できる。
【００４６】
なお、本実施形態において、説明の簡略化のために、データ処理部Ｐｄ間に存在する中継部２１は１つであるものとして説明する。しかしながら、データ処理部Ｐｄ間に存在する中継部２１の数は１つに限定されない。例えば、１つのデータ処理部Ｐｄが音声データおよび画像データを扱う等、２つ以上の異なる種類のデータを扱う場合、それぞれの処理に対応する中継部２１が必要となる。上記例においては、１つのデータ処理部Ｐｄが音声データおよび画像データに対応する場合、２つの中継部２１を備える。このとき、ＲＡＭ１５に展開される中継部２１の数は（Ｎ−１）よりも大きくなるが、この場合においても、送受信制御部２３やバッファ２７のサイズの削減に大きな効果がある。
【００４７】
図３を参照して、ＲＯＭ１７に格納されたデータ送受信装置実装プログラムＰＧｏが、ＲＡＭ１５に展開されたデータ送受信装置展開プログラムＰｒ１の詳細について説明する。データ送受信装置実装プログラムＰｏからはＮ個データ処理部Ｐｄ＿１〜Ｐｄ＿Ｎが展開されると共に、中継部２１が（Ｎ−１）個分だけ繰り返し展開される。なお、本例においては、説明の簡便化の為に、データ送受信装置展開プログラムＰｒ１は、第１のデータ処理部Ｐｄ＿１、第２のデータ処理部Ｐｄ＿２、および第３のデータ処理部Ｐｄ＿３＿を含む例が示されている。本例においては、第１のデータ処理部Ｐｄ＿１はストリーム入力部であり、第２のデータ処理部Ｐｄ＿２はデコード部であり、第３のデータ処理部Ｐｄ＿３は出力部である。
【００４８】
端末に位置する第１のデータ処理部Ｐｄ＿１と第３のデータ処理部Ｐｄ＿３には、それぞれ送信ＡＰＩ３５ａと受信ＡＰＩ３７ｃのみが含まれる。そして、第２のデータ処理部Ｐｄｃ＿２には、受信ＡＰＩ３７ｂと送信ＡＰＩ３５ｂの両方が含まれる。つまり、２つの送信ＡＰＩ３５ａおよび送信ＡＰＩ３５ｂと２つの受信ＡＰＩ３７ｂおよび受信ＡＰＩ３７ｃが含まれている。このように、実質２つのデータ処理部Ｐｄが含まれている。
【００４９】
また、２つの中継部２１＿１および２１＿２が第１のデータ処理部Ｐｄ＿１、第２のデータ処理部Ｐｄ＿２、および第３のデータ処理部Ｐｄ＿３の間に設けられている。具体的には、第１の中継部２１＿１の送受信制御部２３＿１がバッファ２７＿１を介して送信ＡＰＩ３５ａと受信ＡＰＩ３７ｂを中継している。同様に、図示されていないが、第２の中継部２１＿２の送受信制御部２３＿２がバッファ２７＿２を介して、送信ＡＰＩ３５ｂと受信ＡＰＩ３７ｃを中継している。なお、送受信制御部２３も後述の第２の実施形態に係る送受信制御部２３と識別するために、必要に応じて、第１および第２の実施形態に係る送受信制御部２３を、それぞれ送受信制御部２３ａおよび２３ｂと呼称する。
【００５０】
データ送受信装置展開プログラムＰｒ１においては、以下の如くデータ変換処理が実施される。第１のデータ処理部Ｐｄ＿１は、メディア（図示せず）からオーディオストリームを取得すると、中継部２１＿１のバッファ２７＿１の指定されるアドレスにオーディオストリームを書き込む。
【００５１】
第２のデータ処理部Ｐｄ＿２は、中継部２１＿１のバッファ２７＿１の指示されたアドレスからオーディオストリームを読み込み、読み込んだオーディオストリームをデコードし、実オーディオデータとする。デコードされた実オーディオデータは、中継部２１＿２のバッファ２７＿２の指定されるアドレスに書き込まれる。
【００５２】
第３のデータ処理部Ｐｄ＿３は、中継部２１＿２のバッファ２７＿２の指示されたアドレスから実オーディオデータを読み込み、再生する。なお、本実施形態において、すべてのデータ処理部Ｐｄ（第１のデータ処理部Ｐｄ＿１、第２のデータ処理部Ｐｄ＿２、第３のデータ処理部Ｐｄ＿３）は、自立的にタスクを起動する、いわゆる能動データ処理部であるものとする。
【００５３】
本実施形態において、全てのデータ処理部Ｐｄ＿１〜Ｐｄ＿３（Ｐｄ＿Ｎ）は能動データ処理部であるため、データの送受信は、非同期に行われる。その場合、図４に示すように、中継部２１ａ＿１および２１ｂ＿２には、データキュー２５と参照テーブル２９とがさらに設けられる。参照テーブル２９には、データキュー２５のバッファ情報が記録されている。バッファ２７には、データキュー２５と参照テーブル２９とが記録されている。なお、データキュー２５と参照テーブル２９は、データ送受信装置展開プログラムＰｒ１において中継部２１の一部として予め用意されていることは言うまでもない。
【００５４】
図５に示すフローチャートおよび図６に示すシーケンス図を参照して、上述の如く実現されたデータ送受信装置１１（データ送受信装置展開プログラムＰｒ１）のデータ変換動作について説明する。説明の冗長を避けるために、第２のデータ処理部Ｐｄ＿２（デコード部）と第３のデータ処理部Ｐｄ＿３（出力部）との間のデータの送受信についてのみ説明する。
【００５５】
ステップＳ１０１において、中継部２１ａ＿２から第２のデータ処理部Ｐｄ＿２と第３のデータ処理部Ｐｄ＿３とに接続要求が送信される。具体的には、中継部２１ａ＿２において、送受信制御部２３ａ＿２は、第２のデータ処理部Ｐｄ＿２と第３のデータ処理部Ｐｄ＿３とを接続するために、第２のデータ処理部Ｐｄ＿２の送信ＡＰＩ３５ｂおよび第３のデータ処理部Ｐｄ＿３の受信ＡＰＩ３７ｃに対して接続要求を送信する。そして、処理は次のステップＳ１０３に進む。
【００５６】
ステップＳ１０３において、データキュー２５が生成される。そして、処理は次のステップＳ１０５に進む。
【００５７】
ステップＳ１０５において、参照テーブル２９を作成するか否かが判断される。具体的には、送受信制御部２３ａ＿２は、参照テーブル２９がすでに作成されているか否かを判断する。
【００５８】
ステップＳ１０５においてＮｏ、つまり、参照テーブル２９がまだ作成されていない場合、処理はステップＳ１０７に進む。ステップＳ１０７において、送受信制御部２３ａ＿２は、参照テーブル２９を作成する。そして、処理は次のステップＳ１０９に進む。
【００５９】
一方、ステップＳ１０５においてＹｅｓ、つまり、参照テーブル２９がすでに作成されている場合、処理はステップＳ１０９に進む。
【００６０】
ステップＳ１０９において、バッファ２７の要求を受け取ったか否かが判断される。第２のデータ処理部Ｐｄ＿２は、データをデコードすると、送信ＡＰＩ３５ｂを介して中継部２１ａ＿２に空きバッファ要求を送信する。送受信制御部２３ａ＿２は、第２のデータ処理部Ｐｄ＿２から空きバッファ要求を受け取るまでステップＳ１０９の処理を繰り返し行う。ステップＳ１０９においてＹｅｓ、つまり、第２のデータ処理部Ｐｄ＿２から空きバッファ要求を受け取ると、処理は次のステップＳ１１１に進む。
【００６１】
ステップＳ１１１において、中継部２１ａ＿２は、空きバッファのアドレスを通知する。具体的には、送受信制御部２３ａ＿２は、送信ＡＰＩ３５ｂから空きバッファ要求を受け取ると、バッファ２７に記録されている参照テーブル２９を参照する。参照テーブル２９に空きバッファがある場合、中継部２１ａ＿２は、空きバッファのアドレスを第２のデータ処理部Ｐｄ＿２に送信する。そして、処理は次のステップＳ１１３に進む。
【００６２】
ステップＳ１１３において、データが書き込まれたか否かが判断される。具体的には、送受信制御部２３ａ＿２は第２のデータ処理部Ｐｄ＿２から読みとり完了通知を受け取ったか否かを判断する。第２のデータ処理部Ｐｄ＿２は、中継部２１ａ＿２から空きバッファのアドレスを指定されると、送信すべきデータ（オーディオデータ）を指定されたバッファ２７＿１の指定されたアドレスに書き込む。第２のデータ処理部Ｐｄ＿２は、データの書き込みが完了すると、書き込み完了通知を中継部２１ａ＿２に送信する。ステップＳ１１３においてＮｏ、つまり、バッファ２７＿２にデータが書き込まれていない場合、データの書き込みが完了するまで、ステップＳ１１３の処理が繰り返し行われる。
【００６３】
一方、ステップＳ１１３においてＹｅｓ、つまり、第２のデータ処理部Ｐｄ＿２におけるデータの書き込みが完了した場合、処理は次のステップＳ１１５に進む。
【００６４】
ステップＳ１１５において、参照テーブル２９が更新される。具体的には、第２のデータ処理部Ｐｄ＿２によって空きバッファにデータが書き込まれたため、送受信制御部２３ａ＿２は、空きバッファを記録済みバッファとして参照テーブル２９の記録を書き替える。そして、処理は次のステップＳ１１７に進む。
【００６５】
ステップＳ１１７において、第３のデータ処理部Ｐｄ＿３からデータの読み出し要求を受け取ったか否かが判断される。第３のデータ処理部Ｐｄ＿３がデータを受信しようとするとき、第３のデータ処理部Ｐｄ＿３は、受信ＡＰＩ３７ｃを介して、中継部２１ａ＿２にデータ読み出し要求を送信する。そして、処理は次のステップＳ１１９に進む。
【００６６】
ステップＳ１１９において、アドレスが第３のデータ処理部Ｐｄ＿３に通知される。具体的には、送受信制御部２３ａ＿２は、第３のデータ処理部Ｐｄ＿３からデータ読み出し要求を受け取ると、参照テーブル２９を参照する。そして、送受信制御部２３ａ＿２は、次に出力すべきバッファ２７、すなわち、データキュー２５２０１内に確保されているデータの中から、最も古いタイムスタンプを持つデータが保持されているバッファ２７を選択する。送受信制御部２３ａ＿２は、バッファ２７を選択すると、選択したバッファ２７のアドレスを第３のデータ処理部Ｐｄ＿３の受信ＡＰＩ３７ｃに渡す。第３のデータ処理部Ｐｄ＿３は、中継部２１ａ＿１から受け取ったアドレスから受信すべきデータを読み出して、出力する。データ読み出しが終了すると、第３のデータ処理部Ｐｄ＿３は、中継部２１ａ＿２にバッファ２７＿２を返却する。そして、処理は次のステップＳ１２１に進む。
【００６７】
ステップＳ１２１において、送受信制御部２３ａ＿２は、第３のデータ処理部Ｐｄ＿３からバッファ２７＿２を受け取る。そして、処理は次のステップＳ１２３に進む。
【００６８】
ステップＳ１２３において、参照テーブル２９が更新される。送受信制御部２３ａ＿２は、第３のデータ処理部Ｐｄ＿３からバッファ２７を受け取ると、参照テーブル２９の更新を行う。具体的には、送受信制御部２３ａ＿２は、参照テーブル２９において、返却されたバッファ２７＿２を空きバッファとする。
【００６９】
なお、データ送受信操作において、各機能を実現するための処理は、すべて中継部２１＿１において実装されるため、第１のデータ処理部Ｐｄ＿１と第２のデータ処理部Ｐｄ＿２との間のデータ送受信においても同様である。
【００７０】
以上のように、本実施形態によれば、データ送受信装置１１が含むデータ処理部Ｐｄの数に関わらず、ＲＯＭに記録される中継部のプログラムは１つのみでよく、また、各データ処理部Ｐｄはデータ送受信のために、関数を呼ぶだけの送信ＡＰＩ３５または受信ＡＰＩ３７を備えるだけでよい。従来のデータ送受信装置において存在するＮ個のデータ処理部に対して、送信／受信制御部と、バッファと、送信／受信ＡＰＩとは（Ｎ−１）組含まれている。なお、バッファは１組の送信／受信部のどちらか一方に含まれていればよい場合もある。したがって、本発明に係るデータ送受信装置１１によれば、送受信制御部２３の数は１／（Ｎ−１）となり、バッファの数は少なくとも二分の一となる。
【００７１】
また、各データ処理部Ｐｄに含まれる送信／受信ＡＰＩに必要なプログラム容量は、送受信制御部２３やバッファ２７と比較すると、非常に小さい。したがって、従来技術に比べ、冗長度を低減させることによって、必要とするＲＯＭ容量を小さくすることができる。これにより、ＲＯＭ容量に制限があるモバイル機器においても、本発明を適用することができる。また、各データ処理部の機能をハードウェアで実現する場合においても、実装コストを抑制することができる。
【００７２】
また、中継部２１という共通の処理コンポーネントにより、各データ処理部Ｐｄは、バッファ２７を要求する等の、中継部２１の機能を利用するための関数を呼ぶだけの送信ＡＰＩ３５または受信ＡＰＩ３７を備えるだけでよい。これにより、データ処理部Ｐｄの開発工数を削減することができる。
【００７３】
さらに、送受信機能を共通の中継部２１で実現することにより、新規のコンポーネントを追加する場合においても、接続テストは既存のデータ処理部Ｐｄのうち、１つのデータ処理部Ｐｄについて実施するだけで動作が保証される。従って、テスト工数を削減することができる。
【００７４】
（第２の実施形態）
図７に示すブロック図を参照して、本発明の第２実施形態におけるデータ送受信装置１１について説明する。同図は、上述の図３と同様に、ＲＡＭ１５に展開されたデータ送受信装置展開プログラムＰｒ２の詳細を示している。データ送受信装置展開プログラムＰｒ１は、図３に示したデータ送受信装置展開プログラムＰｒ１の中継部２１ａが中継部２１ｂに交換されている。中継部２１ｂは、中継部２１ａにおける送受信制御部２３ａが送受信制御部２３ｂに交換されると共に、判定部３９が追加されている。
【００７５】
なお、本実施形態において、第２のデータ処理部Ｐｄ＿２および第３のデータ処理部Ｐｄ＿３は、自立的にタスクを起動する、いわゆる能動データ処理部であるが、第１のデータ処理部Ｐｄ＿１は、第２のデータ処理部Ｐｄ＿２のタスクと同期して動作する受動データ処理部である。
【００７６】
判定部３９＿１は、接続先の２つのデータ処理部Ｐｄ（ここでは、第１のデータ処理部Ｐｄ＿１と第２のデータ処理部Ｐｄ＿２、または第２のデータ処理部Ｐｄ＿２と第３のデータ処理部Ｐｄ＿３）が両方とも能動データ処理部であるか、または一方が受動データ処理部であるかを判断する。接続先のデータ処理部Ｐｄが両方とも能動データ処理部である場合（ここでは、第２のデータ処理部Ｐｄ＿２および第３のデータ処理部Ｐｄ＿３間のデータ伝送）、中継部２１ｂ＿２において、バッファ２７＿２にデータキュー２５は生成されない。一方、接続先のデータ処理部が能動データ処理部と受動データ処理部とから構成される場合（ここでは、第１のデータ処理部Ｐｄ＿１および第２のデータ処理部Ｐｄ＿２間のデータ伝送）、中継部２１ｂ＿１において、バッファ２７＿１にデータキュー２５が生成される。
【００７７】
図８に示すフローチャートおよび図９に示すシーケンス図を参照して、第１のデータ処理部Ｐｄ＿１（ストリーム入力部）から第２のデータ処理部Ｐｄ＿２（デコード部）にデータが送信される際の動作について説明する。
【００７８】
まず、ステップＳ２０１において、中継部２１ｂ＿１から第１のデータ処理部Ｐｄ＿１と第２のデータ処理部Ｐｄ＿２とに接続要求が送信される。具体的には、中継部２１ｂ＿１において、送受信制御部２３ｂ＿１は、第１のデータ処理部Ｐｄ＿１と第２のデータ処理部Ｐｄ＿２とを接続するために、第１のデータ処理部Ｐｄ＿１の送信ＡＰＩ３５ａおよび第２のデータ処理部Ｐｄ＿２の受信ＡＰＩ３７ｂに対して接続要求を送信する。そして、処理は次のステップＳ２０３に進む。
【００７９】
ステップＳ２０３において、データキュー２５を生成するか否かが判断される。具体的には、中継部２１ｂ＿１において、判定部３９＿１は、第１のデータ処理部Ｐｄ＿１および第２のデータ処理部Ｐｄ＿２とが、能動データ処理部または受動データ処理部のどちらであるかを判断する。本実施形態において、第２のデータ処理部Ｐｄ＿２は能動データ処理部であると判断され、第１のデータ処理部Ｐｄ＿１は受動データ処理部であると判断される。よって、本実施形態においては、ステップＳ２０３における判断はＮｏ、つまり、データキュー２５は生成しないと判断される。判定部３９＿１は、判定結果を送受信制御部２３ｂ＿１に渡す。そして、処理は次のステップＳ２０７に進む。
【００８０】
一方、ステップＳ２０３における判断がＹｅｓ、つまりデータキュー２５を生成すると判断された場合、処理はステップＳ２０５に進む。ステップＳ２０５において、データキュー２５が生成される。送受信制御部２３ｂ＿１は、判定部３９＿１から判定結果を受け取ると、データキュー２５を作成する。また、ステップＳ２０３において、参照テーブル２９がまだ作成されていない場合、参照テーブルを作成する。そして、処理は次のステップＳ２０７に進む。
【００８１】
ステップＳ２０７において、データ要求を受け取ったか否かが判断される。具体的には、送受信制御部２３ｂ＿１は、第２のデータ処理部Ｐｄ＿２からデータを読み出すための要求が送信されてきたか否かを判断する。ステップＳ２０７においてＮｏ、つまり、第２のデータ処理部Ｐｄ＿２からデータ要求を受け取らない場合、データ要求を受け取るまで、ステップＳ２０７の処理が繰り返し行われる。
【００８２】
一方、ステップＳ２０７においてＹｅｓ、つまり第２のデータ処理部Ｐｄ＿２からデータ要求を受け取った場合、処理はステップＳ２０９に進む。ステップＳ２０９において、データ要求が中継部２１ｂ＿１から第１のデータ処理部Ｐｄ＿１に送信される。そして、処理は次のステップＳ２１１に進む。
【００８３】
ステップＳ２１１において、アドレスを受け取ったか否かが判断される。送受信制御部２３ｂ＿１は、第１のデータ処理部Ｐｄ＿１からデータが記録されている位置（アドレス）が送信されてきたか否かを判断する。ステップＳ２１１においてＮｏ、つまり第１のデータ処理部Ｐｄ＿１からアドレスを受け取っていない場合、アドレスを受け取るまで繰り返しステップＳ２１１の処理が行われる。
【００８４】
一方、ステップＳ２１１においてＹｅｓ、つまり第１のデータ処理部Ｐｄ＿１からアドレスを受け取った場合、処理は次のステップＳ２１３に進む。ステップＳ２１３において、第２のデータ処理部Ｐｄ＿２にアドレスが送信される。送受信制御部２３ｂ＿１は、第１のデータ処理部Ｐｄ＿１から受け取ったアドレスを第２のデータ処理部Ｐｄ＿２に送信する。そして、処理は次のステップＳ２１５に進む。ここで、第２のデータ処理部Ｐｄ＿２は、中継部２１ｂ＿１からアドレスを受け取ると、受け取ったアドレスからデータを読み出す。データの読み出しが完了すると、第２のデータ処理部Ｐｄ＿２は、読み出し完了通知を中継部２１ｂ＿１に送信する。
【００８５】
ステップＳ２１５において、読み出し完了通知が受信される。中継部２１ｂ＿１において、送受信制御部２３ｂ＿１は、第２のデータ処理部Ｐｄ＿２から読み出し完了通知を受け取ると、処理を終了する。
【００８６】
次に、図１０に示すフローチャートおよび図１１に示すシーケンス図を参照して、第２のデータ処理部Ｐｄ＿２から第３のデータ処理部Ｐｄ＿３にデータが送信される際の、データ送受信装置１１の動作について説明する。図１０に示すフローチャートは、図５に示された第１の実施形態にかかるデータ送受信装置１１の動作を示すステップＳ１０１の処理の後に、図８に示すフローチャートにおける動作を示すステップＳ２０２を追加したものである。このため、図５および図８のフローチャートと同一のステップについては、説明を省略する。
【００８７】
ステップＳ２０２において、データキュー２５を生成するか否かが判断される。本実施形態においては、第２のデータ処理部Ｐｄ＿２および第３のデータ処理部Ｐｄ＿３は、判定部３９＿２によって両方とも能動データ処理部であると判断されるため、データキュー２５および参照テーブル２９が生成される。そして、処理は次のステップＳ１０３に進む。ステップＳ１０３〜Ｓ１２３の処理は、図５に示すフローチャートにおけるステップＳ１０３〜Ｓ１２３の処理と同様である。
【００８８】
以上のように、第２の実施形態によれば、能動データ処理部と受動データ処理部とが混在する場合においても、中継部２１によってデータの送受信を中継することができる。
【００８９】
なお、本実施形態において、オーディオデータを再生する場合について説明したが、パイプライン方式による複数のデータ処理部によって処理されるデータであればオーディオデータに限られない。例えば、図１２に示すような構成において、オーディオデータとビデオデータとが多重化されたストリームを再生する場合に本実施形態を適用することも可能である。
【図面の簡単な説明】
【図１】本発明に係るデータ送受信装置の構成を示すブロック図である。
【図２】本発明に係るデータ送受信装置１１のＲＯＭ１７におけるソフトウェア構成を示すブロック図である。
【図３】第１の実施形態におけるデータ送受信装置１１のＲＡＭにおけるソフトウェア構成を示すブロック図である。
【図４】中継部２１に含まれる構成を示す図である。
【図５】第１の実施形態におけるデータ送受信装置１１の動作を示すフローチャートである。
【図６】第１の実施形態におけるデータ送受信装置１１の動作を示すシーケンス図である。
【図７】第２の実施形態におけるデータ送受信装置１１のＲＡＭにおけるソフトウェア構成を示すブロック図である。
【図８】第２の実施形態におけるデータ送受信装置１１の動作を示すフローチャートである。
【図９】第２の実施形態におけるデータ送受信装置１１の動作を示すシーケンス図である。
【図１０】第２の実施形態におけるデータ送受信装置１１の動作を示すフローチャートである。
【図１１】第２の実施形態におけるデータ送受信装置１１の動作を示すシーケンス図である。
【図１２】パイプライン方式によるマルチメディアデータ変換の一例を示すブロック図である。
【図１３】従来のデータ送受信装置の構成を示すブロック図である。
【図１４】従来のデータ送受信装置１１のソフトウェア構成を示すブロック図である。
【図１５】従来のデータ送受信装置１１の詳細なソフトウェア構成を示すブロック図である。
【図１６】能動データ処理部および受動データ処理部双方に対応するデータ処理部Ｐｄｃの構成を示すブロック図である。
【図１７】送信部１５１および受信部１５３に含まれる構成を示す図である。
【図１８】従来のデータ送受信装置１１の動作を示すシーケンス図である。
【図１９】従来のデータ送受信装置１１の動作を示すシーケンス図である。
【符号の説明】
１１、１１１      データ送受信装置
１３、１１３      ＣＰＵ
１５、１１５      ＲＡＭ
１７、１１７      ＲＯＭ
Ｐｏ、ＰＧｏ      実装プログラム
Ｐｒ、ＰＧｒ      展開プログラム
２１              中継部
２３              送受信制御部
２５、１２５      データキュー
２７、１２７      バッファ
２９、２２９      参照テーブル
３５、１３５      送信ＡＰＩ
３７、１３７      受信ＡＰＩ
Ｐｄ、Ｐｄｃ      データ処理部
Ｐｄ１、Ｐｄｃ１  ストリーム入力部
Ｐｄ２、Ｐｄｃ２  デコード部
Ｐｄ３、Ｐｄｃ３  出力部
１２９            送信制御部
１３１            受信制御部
１５１            送信部
１５３            受信部
１６１            タスク接続部
１６３            ライブラリ接続部
【図１】
2004310545.tif 000003
【図２】
2004310545.tif 000004
【図３】
2004310545.tif 000005
【図４】
2004310545.tif 000006
【図５】
2004310545.tif 000007
【図６】
2004310545.tif 000008
【図７】
2004310545.tif 000009
【図８】
2004310545.tif 000010
【図９】
2004310545.tif 000011
【図１０】
2004310545.tif 000012
【図１１】
2004310545.tif 000013
【図１２】
2004310545.tif 000014
【図１３】
2004310545.tif 000015
【図１４】
2004310545.tif 000016
【図１５】
2004310545.tif 000017
【図１６】
2004310545.tif 000018
【図１７】
2004310545.tif 000019
【図１８】
2004310545.tif 000020
【図１９】
2004310545.tif 000021