(57)【要約】  本発明は特に、コンピュータ(PC)のマルチメディア周辺装置(MDEV)にマルチメディアストリーム(MUS、MOV)を送信する方法であって、コンピュータ(PC)がユーザモードでおよびスーパーバイザモードで動作することができるプロセッサ(MP)を備えており、コンピュータ(PC)がプロセッサ(MP)によって読取り可能なかつマルチメディアモジュール(MM)を記憶している記憶媒体(HDD)を備えており、スーパーバイザモードでプロセッサ(MP)によって実行されるマルチメディアモジュール(MM)による、割振りの、受信のおよび送信の実装を含む、送信する方法に関する。本発明は、そのような方法を実装するコンピュータプログラム、記憶装置およびシステムにも関する。
2018520398.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ(PC)のマルチメディアデバイス(MDEV)にマルチメディアストリーム(MUS、MOV)を送信するための方法であって、前記コンピュータ(PC)がユーザモードでおよびスーパーバイザモードで動作することができるプロセッサ(MP)を備えており、前記コンピュータ(PC)が前記プロセッサ(MP)によって読取り可能なかつマルチメディアモジュール(MM)を記憶している記憶媒体(HDD)を備えており、スーパーバイザモードで前記プロセッサ(MP)によって実行される前記マルチメディアモジュール(MM)において、
/a/少なくとも10秒のマルチメディアストリーム(MUS、MOV)を含むように配置されるバッファ(BUF)の、カーネル空間での割振り(AL)と、
/b/マルチメディアストリーム(MUS、MOV)の受信(REC)、および前記バッファ(BUF)でのその記憶と、
/c/前記バッファ(BUF)に記憶されたマルチメディアストリームの、前記マルチメディアデバイス(MDEV)への送信(EM)とを含む、送信するための方法。
【請求項２】
前記マルチメディアモジュール(MM)による、前記マルチメディアストリームの送信中の前記マルチメディアデバイス(MDEV)の排他的予約(RES)を含む、請求項1に記載のマルチメディアストリーム(MUS、MOV)を送信するための方法。
【請求項３】
前記マルチメディアモジュール(MM)が、ユーザモードで前記プロセッサ(MP)によって実行されるマルチメディアプレーヤ(MPL)からアクセス可能なインタフェース(INT)を備えており、前記送信するための方法が、前記インタフェース(INT)を介した前記マルチメディアプレーヤ(MPL)による、前記バッファ(BUF)における任意の所与の読込み位置を選択する要求の、前記マルチメディアモジュール(MM)への送信(SND)を含む、請求項1または2に記載のマルチメディアストリーム(MUS、MOV)を送信するための方法。
【請求項４】
前記マルチメディアストリームがオーディオストリーム(MUS)から成り、かつ前記マルチメディアデバイス(MDEV)がデジタルアナログ変換器(DAC)を備える、請求項1から3のいずれか一項に記載のマルチメディアストリームを送信するための方法。
【請求項５】
プロセッサによって実行されると、請求項1から4のいずれか一項に記載の方法を実装する一連の命令を備える、コンピュータプログラム。
【請求項６】
請求項5に記載のコンピュータプログラムを備える非一時的コンピュータ可読記憶媒体(HDD)。
【請求項７】
-  コンピュータ(PC)と、
-  マルチメディアデバイス(MDEV)とを備え、
前記コンピュータ(PC)が、
-  ユーザモードでおよびスーパーバイザモードで動作することができるプロセッサ(MP)と、
-  前記プロセッサ(MP)によって読取り可能なかつマルチメディアモジュール(MM)を記憶している記憶媒体(HDD)とを備えており、
前記マルチメディアモジュール(MM)が、スーパーバイザモードで前記プロセッサ(MP)によって実行されるように配置されている、マルチメディアストリーム(MUS、MOV)を送信するためのシステムであって、
-  少なくとも10秒のマルチメディアストリーム(MUS、MOV)を含むように配置されるバッファ(BUF)を、カーネル空間で割り振るための回路(AL_C)と、
-  マルチメディアストリーム(MUS、MOV)を受信し、そしてそれを前記バッファ(BUF)に記憶するように配置される、上記マルチメディアストリームを受信するための回路(REC_C)と、
-  前記バッファ(BUF)に記憶されたマルチメディアストリームを、前記マルチメディアデバイス(MDEV)に送信するための回路(EM_C)とを備える、マルチメディアストリーム(MUS、MOV)を送信するためのシステム。
【請求項８】
前記マルチメディアストリームの前記送信中の前記マルチメディアデバイス(MDEV)の排他的予約のための回路(RES_C)を備える、請求項7に記載のマルチメディアストリーム(MUS、MOV)を送信するためのシステム。
【請求項９】
前記マルチメディアモジュール(MM)が、ユーザモードで前記プロセッサ(MP)によって実行されるマルチメディアプレーヤ(MPL)からアクセス可能なインタフェース(INT)を備えており、前記送信するためのシステムが、前記マルチメディアプレーヤ(MPL)が、前記バッファ(BUF)における任意の所与の読込み位置を選択する要求を、前記インタフェース(INT)を介して前記マルチメディアモジュール(MM)に送信することを可能にする回路(SND_C)を備える、請求項7または8に記載のマルチメディアストリーム(MUS、MOV)を送信するためのシステム。
【請求項１０】
前記マルチメディアストリームがオーディオストリーム(MUS)から成り、かつ前記マルチメディアデバイス(MDEV)がデジタルアナログ変換器(DAC)を備える、請求項7から9のいずれか一項に記載のマルチメディアストリームを送信するためのシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はマルチメディアストリーム、特にオーディオストリームの送信を改善することに関する。マイクロコンピュータ、ラップトップコンピュータおよびタブレットの能力の上昇が、主目的がCDおよびSACD媒体の再生および記録による誤りを訂正すること、ならびに記録および再現チェーンの様々な構成部品によってもたらされるデジタル化および干渉による雑音を除去することによって音の純度を改善することであるオーディオ記録のリアルタイム処理の発展を可能にした。
【背景技術】
【０００２】
これを行うハードウェアおよびソフトウェアを作成した会社は、再構築された音の明瞭度および純度の質的な飛躍を得ることに成功した。
【０００３】
オーディオ信号を読み込むときに使用される構成部品によって発生される雑音の物理的な問題に解決策がない限り、最良のハードウェアおよびソフトウェアにまだなされていないさらなる改善は比較的軽微である。雑音のレベルはこれらの構成部品の動作モードに、およびしたがって制御ソフトウェアの動作モードに関連がある。
【０００４】
デジタル音楽再生ソフトウェアのために今まで実装された最先端解決策は、これらのシステムで使用されるオペレーティングシステムのアプリケーションレベルで適用される。
【０００５】
既知の解決策では、オーディオデバイスドライバのみが最特権モード(カーネルモード、スーパーバイザモードとも呼ばれる)で動作する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
マルチメディアストリームの送信の質は現存の解決策では不十分である。
【課題を解決するための手段】
【０００７】
本発明はこの状況を改善する。
【０００８】
本発明の一態様は、コンピュータのマルチメディアデバイスにマルチメディアストリームを送信するための方法であって、コンピュータがユーザモードでおよびスーパーバイザモードで動作することができるプロセッサを備えており、コンピュータがプロセッサによって読取り可能なかつマルチメディアモジュールを記憶している記憶媒体を備えており、スーパーバイザモードでプロセッサによって実行されるマルチメディアモジュールによる、
/a/少なくとも10秒のマルチメディアストリームを含むように配置されるバッファの、カーネル空間での割振りと、
/b/マルチメディアストリームの受信、およびバッファでのその記憶と、
/c/バッファに記憶されたマルチメディアストリームの、マルチメディアデバイスへの送信との実装を含む、送信するための方法に関する。
【０００９】
この方法は、それがそのような方法によって送信されるマルチメディアストリームに含まれる音および/またはビデオの質を改善することを許容するという点で特に有利である。スーパーバイザモードでのマルチメディアモジュールの実行を実装することによって、方法は、それにマルチメディアストリームのリアルタイム管理のための非常に高い優先度を与える。加えて、非常に大きい(少なくとも10秒)ため従来にないサイズのそれのためにバッファを割り振り、かつバッファを(スーパーバイザモードでのみアクセス可能な)カーネル空間に置くことによって、方法は、(非常に短期間の間さえ)中断されにくいマルチメディアストリームの送信のより大きな連続性を確実にし、したがって送信するときにより高い質も確実にする。加えて、カーネル空間の使用は(ユーザ空間の使用と比較して)メモリおよびプロセッサ資源の使用の削減を暗示するが、その理由はそれが、マルチメディアストリームの送信中に電気および電磁干渉を発生しがちであるメモリコピーもプロセッサコンテキストスイッチもあまり必要としないからである。
【００１０】
本発明の別の態様は、プロセッサによって実行されると本発明の一態様に係る方法を実装する一連の命令を備えるコンピュータプログラムに関する。
【００１１】
本発明の別の態様は、本発明の一態様に係るコンピュータプログラムを備えるコンピュータ可読非一時的記憶媒体に関する。
【００１２】
本発明の別の態様は、コンピュータとマルチメディアデバイスとを備える、マルチメディアストリームを送信するためのシステムであって、コンピュータがユーザモードでおよびスーパーバイザモードで動作することができるプロセッサを備えており、コンピュータがプロセッサによって読取り可能なかつマルチメディアモジュールを記憶している記憶媒体を備えており、マルチメディアモジュールがスーパーバイザモードでプロセッサによって実行されるように配置されており、
-  少なくとも10秒のマルチメディアストリームを含むように配置されるバッファを、カーネル空間で割り振るための回路と、
-  マルチメディアストリームを受信し、そしてそれをバッファに記憶するように配置される、上記マルチメディアストリームを受信するための回路と、
-  バッファに記憶されたマルチメディアストリームを、マルチメディアデバイスに送信するための回路とを備える、送信するためのシステムに関する。
【００１３】
このシステムは、それが本発明に係る方法を実装するのに特に適し、そしてしたがってマルチメディアストリームを送信するときに上記ストリームに含まれる音および/またはビデオの質を改善するという点で有利である。
【００１４】
本発明の他の態様、目的および利点はその実施形態のいくつかの説明から明らかであろう。
【００１５】
本発明はまた図面の助けを借りてよりよく理解されるであろう。
【図面の簡単な説明】
【００１６】
【図１】一実施形態に従ってマルチメディアストリームを送信するためのシステムを例示する。
【図２】一実施形態に従ってメモリMEMの内容を概略的に例示する。
【図３】一実施形態に従ってマルチメディアストリームを送信するための方法を例示する。
【図４】一実施形態に従ってシステムのアーキテクチャを例示する。
【図５】一実施形態に従って方法を初期化するための手順を例示する。
【図６】一実施形態に従ってオーディオ再生を例示する。
【図７】一実施形態に従って自動一時停止を例示する。
【図８】一実施形態に従って一曲の音楽の送信の終わりを検出および処理するための方法を例示する。
【図９】一実施形態に従って一曲の音楽の送信を停止するための方法を例示する。
【図１０】一実施形態に従ってカーネル空間でのバッファを例示する。
【発明を実施するための形態】
【００１７】
下記する図では、実施形態はしばしばオーディオストリームに関するが、しかしこれらの実施形態は他の種類のストリームにも適用される。
【００１８】
図1は、ハードドライブHDD、マルチメディアデバイスMDEVおよびマザーボードを備えるコンピュータPCを例示する。代替的に、マルチメディアデバイスMDEVはマザーボードに統合されてよい。マルチメディアデバイスMDEVは、たとえば(場合により増幅器による増幅後に、マルチメディアストリームMUS(ビデオストリームのオーディオ部分であり得る符号化された音楽)に符号化される音楽を、スピーカを用いて再現するために)マルチメディアストリームMUSに由来するデジタルデータをスピーカを制御するのに適する電圧に変換するためのデジタルアナログ変換器DACを備える。ハードドライブHDDおよびマルチメディアデバイスを取り付けるためのデバイスは表されない。
【００１９】
マザーボードは、プロセッサMP(冷却システムは図示されない)および少なくとも1つのRAMメモリモジュールMEM(たとえばDDR3 SDRAMのDIMMスティック)が搭載される。
【００２０】
マザーボードは5つの回路AL_C、REC_C、EM_C、RES_CおよびSND_Cも搭載される。これらの回路は別々の個別の電子部品として表される。しかしながら、可能な一実装では、これらの5つの回路の機能は、これらの異なる機能を提供する1つの回路によって果たされる。可能な一実装では、5つの回路は、より詳細に下記する様式で、プロセッサMPおよび具体的なプログラムを含むメモリMEMの組合せから成る回路によって実装される。
【００２１】
マザーボードは、ハードドライブHDDを接続するための、図示しないストレージ用コネクタ(たとえばSATA、SCSIまたはIDE)、および特にマルチメディアデバイスMDEVを接続するための、図示しない拡張カード用コネクタ(たとえばPCI、PCI ExpressまたはAGP)も備える。
【００２２】
バス(図示せず)が、マザーボードの様々な構成部品(マイクロプロセッサMP、メモリMEM、マルチメディアデバイスMDEV、ハードドライブHDD、ならびに異なる回路AL_C、REC_C、EM_C、RES_CおよびSND_Cを含む)を接続する。
【００２３】
図2は、可能な一実施形態に従ってメモリMEMの内容を概略的に例示する。表されるメモリは、(初期アドレス0x00000000によって例示されるように)32ビットモードでアドレスされるが、もちろん64ビットまたはなんらかの他の適切なアドレッシングでアドレスされ得る。第1の物理アドレスから始まって、メモリMEMは、ソフトウェア形態で実装されるマルチメディアプレーヤMPLのための実行可能コードを含む。第2の物理アドレスから始まって、メモリMEMは、マルチメディアモジュールMMに対応する実行可能コードを含む。このマルチメディアモジュールMMは、ソフトウェアが他のプログラムにサービスを提供するインタフェースとして役立つ標準化された一組のクラス、方法または機能を意味するAPIの形態をとり得るインタフェースINTを含む。第3の物理アドレスから始まって、メモリMEMは、バッファBUFに対応する実行可能コードを含む。カーネルが通常ユーザアプリケーションを事前にロードされるので、マルチメディアモジュールMMおよびそのインタフェースINTのために必要とされるメモリは通常、マルチメディアプレーヤMPLのために必要とされるメモリの前に割り振られる。したがって、マルチメディアモジュールMMを含むメモリブロックの物理アドレスがマルチメディアプレーヤMPLを含むメモリブロックの物理アドレスより低いことが可能である(図2におけるメモリブロックの相対位置は逆の構成を図示しており、例示的であるにすぎない)。上記情報を記憶しているメモリにおける3つの領域は各々、連続領域として表される。しかしながら、実際にはこれが必ずしもそうであるわけではない。したがって、バッファが通例1つの連続ブロックとして割り振られる(バッファにおけるデータに対応するいかなるアドレスもバッファにおけるデータを含む少なくとも1つの他のアドレスに直ちに隣接することを意味する)とはいえ、これはマルチメディアモジュールMMまたはマルチメディアプレーヤMPLについてはしばしば事実ではなく、それは各々(割振り解除されたメモリの領域または他のアプリケーションに割り振られた領域によって隔てられる)一組の複数の非隣接のメモリのブロックにロードされてよい。また、図2は、それらの物理アドレスに従って記憶される情報を図示する。(プロセッサに統合されるMMUによって通例割り当てられ、かつ物理アドレスを無視することを許容する)仮想アドレスは物理アドレスと異なり得る(そして通例異なる)。
【００２４】
図3は、可能な一実施形態に従ってマルチメディアストリームを送信するための方法を例示する。
【００２５】
排他的予約ステップRES中に、マルチメディアモジュールMMが、マルチメディアデバイスMDEVの排他的予約を確立する。矢印がマルチメディアモジュールMMからマルチメディアデバイスMDEVを記号的に指す。可能な一実装によれば、マルチメディアデバイスはしたがって要求を受信し、それをたとえばマルチメディアデバイスの統合マイクロコントローラを使用して処理する。しかしながら、排他的予約は必ずしもマルチメディアデバイスに送信されるわけではない。可能な一実装によれば、要求はたとえばマルチメディアデバイスのデバイスドライバに送信され、それがマルチメディアデバイスの排他的予約を管理し、そしてマルチメディアデバイスにその排他的予約を通知さえしなくてよい。マルチメディアストリームの全体が送信された(たとえばフィルム全体)後に、マルチメディアモジュールは、(排他的予約を終わらせるために)マルチメディアデバイスを自動的に解放してよい。
【００２６】
(排他的予約ステップRESの後または前でよい)割振りステップALでは、マルチメディアモジュールMMは、カーネル空間に大きなバッファBUFを割り振る。
【００２７】
マルチメディアストリームを受信するステップRECでは、マルチメディアモジュールMMは、マルチメディアプレーヤMPLからマルチメディアストリームセグメント(たとえば数秒の音楽MUSまたはビデオMOV)を(データのブロックとして)受信する。それはこのセグメントをバッファBUFに保存する。必要に応じて、それは、バッファが満杯でない限りそのようなセグメントを受信する。
【００２８】
マルチメディアストリームを送信するステップEMでは、マルチメディアモジュールMMは、バッファBUFに含まれるマルチメディアストリームセグメントをマルチメディアデバイスMDEVに(データのブロックとして)送信する。一旦バッファが満たされると、その内容の一部がこの様式で送信されているので、マルチメディアモジュールMMは、バッファが再び満杯でない限りマルチメディアストリームセグメントを再び受信するように配置される。マルチメディアストリームの送信部分が必ずしもマルチメディアストリームの受信部分と厳密に一致するわけではない。たとえば、マルチメディアストリームを3キロバイトのブロックで受信すること、そしてそれらを2キロバイトのブロックで送信することが可能である。受信および送信されるブロックのサイズが必ずしも一定であるわけでもない。したがって、受信されるストリームおよび送信されるストリームが基本的に同一であるとはいえ、(受信のためのデータのブロックおよび送信のためのデータのブロックへの)それらの細分が必ずしもそうであるわけではない。
【００２９】
便宜のために、マルチメディアストリーム部分は用語「マルチメディアストリーム」によって言及されることになる。実際、マルチメディアストリーム部分はマルチメディアストリームのままである。
【００３０】
送信ステップSND中に、マルチメディアプレーヤ(MPL)は、バッファ(BUF)における任意の所与の読込み位置を選択する要求を、マルチメディアモジュールMMのインタフェース(INT)を介して送信する。バッファの大きなサイズにもかかわらず、したがって、バッファが読み込まれるのを待つ必要(そうでなければバッファに含まれるストリーム全体が送信されるのを待たなければならない)またはバッファに新たなデータをロードする必要なく、前方にジャンプすることが可能である。
【００３１】
図4は、一実施形態に従ってシステムのアーキテクチャを例示する。アプリケーションレベルに(ユーザ空間に)ロードされるオーディオアプリケーションMPLは、オーディオデータソース(DVD、リモートサーバ、ローカルファイルなど)から、一曲の音楽を表す大量のデータを読み込む。それは次いでこのデータを小さなパケットの形態で、カーネルに(カーネル空間に)ロードされるオーディオプレーヤMM(特殊な種類のマルチメディアモジュール)のバッファBUFに転送する。それはこのデータ転送をインタフェースINTを介して行い、これはカーネルのオーディオプレーヤMMに指令を送信するため、およびそれから通知を受信するためにも作用する。カーネルのオーディオプレーヤMMは次いで、これらのデータをオーディオ周辺装置MDEVのデバイスドライバDRVに転送する。デバイスドライバDRVはカーネルのオーディオプレーヤMMの外部であるか、またはカーネルのオーディオプレーヤMMに直接統合される。データは、次いで入出力インタフェースIOに、次いでオーディオ周辺装置MDEVに転送される。
【００３２】
図5は、一実施形態に従って方法の初期化手順を例示する。
【００３３】
ユーザ空間で動作するオーディオアプリケーションMPLは、(カーネル空間で動作する)カーネルのオーディオプレーヤMMに要求HQ_MODを送信して、オーディオ愛好家再生モード(高品質モード)に切り替える。必要に応じて、オーディオアプリケーションMPLは、カーネルのオーディオプレーヤMMをカーネル空間へ事前にロードする。
【００３４】
カーネルのオーディオプレーヤMMは、オーディオ周辺装置MDEVを予約するためにカーネルのオーディオサービスに排他的予約要求S_RESを送信する。この要求は、オーディオ周辺装置MDEVに送信され、かつカーネルのオーディオプレーヤから到着していないいかなる他の要求も取り消すために、オーディオシステムの残部からの切断に至る。カーネルのオーディオサービスは、排他的予約が成功したことを示す通知S_RES_OKを送信することによって、カーネルのオーディオプレーヤMMに応答する。
【００３５】
カーネルのオーディオプレーヤMMは、オーディオ周辺装置MDEVに要求REQ_Fを送信して、それがサポートする異なる形式(CD品質用の44.1kHzでの、96kHzでのサンプリングレート、サポートされるチャネル数など)を通信するようそれに依頼する。オーディオ周辺装置MDEVは、サポートされる形式をメッセージSND_Fで送信することによって応答する。
【００３６】
カーネルのオーディオプレーヤMMは次いで、オーディオデータのために使用されるバッファBUFをALに割り振る。このバッファは大きなバッファ(少なくとも10秒のオーディオデータ)である。
【００３７】
カーネルのオーディオプレーヤMMは次いで、オーディオ愛好家モードへの変更が成功したことを、メッセージHQ_MOD_OKを用いてオーディオアプリケーションMPLに信号で伝える。
【００３８】
図6は、一実施形態に従ってオーディオ再生方法を例示する。
【００３９】
一曲の音楽MUSを再生するために、オーディオアプリケーションMPLは、カーネルのオーディオプレーヤMMに構成メッセージCONF1を送信することから始める。このメッセージの内容は、図5に表したように初期化手順中に決定され得る。構成メッセージCONF1はしたがって、たとえば送信されることになる一曲の音楽が96kHzの周波数で24ビットでサンプリングされ、かつステレオであることを指定できる。他の形式がもちろん利用されてよい。カーネルのオーディオプレーヤMMは次いで、オーディオ周辺装置MDEVに構成メッセージCONF2を送信する。このメッセージCONF2はメッセージCONF1で受信される要素をとってよく、そして必要に応じて前処理されてよい。一旦構成されると、オーディオ周辺装置MDEVは、それが成功したと、カーネルのオーディオプレーヤMMに送信されるメッセージOK2によって応答し、そこから次いでメッセージOK1を用いてオーディオアプリケーションMPLに通知する。
【００４０】
オーディオアプリケーションMPLは次いで、オーディオデータをカーネルのオーディオプレーヤMMのバッファBUFへロードする(ステップLD)。一旦十分なデータがロードされると(たとえば少なくとも1秒の音楽に対応するデータ量)、オーディオアプリケーションMPLはカーネルのオーディオプレーヤMMにメッセージRD1を送信して、それにオーディオデータを読み込み始める(スピーカでの再生のためにデータをオーディオ周辺装置MDEVに送信することを意味する)よう依頼する。カーネルのオーディオプレーヤMMは、オーディオ周辺装置MDEVにメッセージRD2を送信することによって読込みを開始する。
【００４１】
読込み処理はしたがって、原則として再生されるべき一曲の音楽のオーディオデータの終わりが到達されるまで(換言すれば、一曲の音楽全体が処理されるまで)繰り返すループをトリガする。このループは、オーディオ周辺装置MDEVによる、オーディオデータパケットが送信されるよう依頼する要求RQ_PKの、カーネルのオーディオプレーヤMMへの送信を含む。オーディオプレーヤは、メッセージSND_PKを使用して要求されたパケットを送信することによって応答し、そしてカーネルバッファにおける次の読込みが次のパケットの始めに対応するようにカーネルバッファBUFにおける読込み位置を(ステップINCで)インクリメントする。送信パケットはバッファからとられるデータから構築される。可能な一実装によれば、パケットは、(たとえばパケットサイズ、巡回冗長符号などを示すヘッダなどの)他の情報を含む。代替的に、要求RQ_PKは全く送信されず、かつオーディオ周辺装置MDEVが、同期して動作するデジタルアナログ変換器DACを備える。カーネルのオーディオプレーヤMMは次いで、それ自体でオーディオ周辺装置MDEVのパラメータを基礎として送信周波数を決定して、要求なしでオーディオデータを送信するように配置される。
【００４２】
周期的に(たとえば毎秒)、カーネルのオーディオプレーヤMMは、メッセージNOT_POSを使用してオーディオアプリケーションMPLに読込み位置を通知する。代替的に(または、それが有用であるときに追加的に)、オーディオアプリケーションMPL自体が、たとえばカーネルのオーディオプレーヤのインタフェースINTを使用して(通知を受信するために待つことなく)この情報にアクセスできる。
【００４３】
オーディオアプリケーションMPLは、それが受信した通知NOT_POSをおよび/またはそれが(そのような通知を使用することなく)直接読み込んだストリーム情報を基礎として、(一曲の音楽が完全に再生されなかった限り)カーネルバッファBUFを満たす(ステップCONT_LDステップ)。
【００４４】
図7は、一実施形態に従ってデータを待つときの自動一時停止を例示する。
【００４５】
カーネルのオーディオプレーヤMMは、カーネルバッファBUFにおけるカーネルのオーディオプレーヤMMの読込み位置がロードされたオーディオデータの終わりに対応する位置に到達したが、それが曲位置の終わりでもバッファ位置の終わりでもないことを検出するように配置される。それは、たとえばEMPTY_BUFイベント(図6に例示した読込み位置のインクリメントINCがバッファにおけるオーディオデータ位置の終わりに到達したときにトリガされるイベント)、またはソフトウェア割込み、または別々のスレッド(スレッドは時に「タスク」と呼ばれる)によって行われる連続ループ試験を検出することによって、この検出を行う。
【００４６】
カーネルのオーディオプレーヤは次いで、オーディオ周辺装置MDEVに一時停止要求RQ_PSEを送信する(それでオーディオ周辺装置はオーディオパケットを要求するのを止めることになる)。オーディオ周辺装置MDEVは、一時停止が成功したというメッセージPSE_OKで応答する。カーネルのオーディオプレーヤMMは次いで、オーディオアプリケーションMPLに、オーディオ周辺装置MDEVがデータ不足のために一時停止されていることを、通知NOT_PSEによって通知する。代替実装では、オーディオ周辺装置MDEVに一時停止要求RQ_PSEを送信する代わりに、カーネルのオーディオプレーヤMMは、バッファBUFが再び十分なデータを有するまで「無音」パケット(無音に対応するゼロ信号を表す一定のサンプルを含むパケットを意味する)を送信する。この代替例は、任意の種類のオーディオ周辺装置との強化された相互運用性の利点を有する(一時停止がシミュレートされるのでオーディオ周辺装置はそれを認識していない)。
【００４７】
この時間中に、カーネルのオーディオプレーヤは、それがカーネルバッファにもうデータがないことを検出するようにするものと同様の機構によってカーネルバッファの内容を検査し続ける。十分なデータ量が検出されるとすぐに、たとえばイベントBUF_FILLを用いて、カーネルのプレーヤはオーディオ周辺装置MDEVにメッセージRES_RDを送信し、その結果オーディオ周辺装置MDEVが読込みを再開する。オーディオ周辺装置MDEVは、それが読込みを再開したというメッセージRES_RD_OKで応答し、カーネルのオーディオプレーヤMMが通知NOT_RDを用いてオーディオアプリケーションMPLに通知する。
【００４８】
図8は、一実施形態に従って一曲の音楽の送信の終わりを検出および処理するための方法を例示する。
【００４９】
カーネルのオーディオプレーヤMMは、カーネルバッファBUFにおけるカーネルのオーディオプレーヤMMの読込み位置がバッファの終わりまたは再生されている曲の終わりに対応する位置に到達したことを検出するように配置される。それは、たとえばイベントREACH_ENDを検出することによって、ソフトウェア割込みによって、または別々のスレッドによって行われる連続ループ試験によって、この検出を行う。
【００５０】
カーネルのオーディオプレーヤは次いで、カーネルバッファを読み込むことの終わりのまたは曲を読み込むことの終わりの通知NOT_ENDをオーディオアプリケーションMPLに送信する。
【００５１】
オーディオアプリケーションMPLは次いで、この位置の後に、または(複数のバッファがあるとき)次のバッファにオーディオデータが存在するかどうかを検査する(ステップTST_MORE_DAT)。そのようなことが事実であれば、それは適宜現在のまたは次のバッファから読み込み続ける(ステップCONT_RD)。そうでなければ(ステップNO_MORE_DAT)、カーネルのオーディオプレーヤは、オーディオ周辺装置MDEVに一時停止要求PSEを送信する(その結果オーディオ周辺装置がオーディオパケットを要求するのを止める)。オーディオ周辺装置MDEVは、一時停止が成功したことを示すメッセージOK_PSEで応答する。カーネルMMは次いで、オーディオアプリケーションMPLに、オーディオ周辺装置MDEVがデータ不足のために一時停止されていることを、通知NOTIF_Pによって通知する。代替実装では、オーディオ周辺装置MDEVに一時停止要求PSEを送信する代わりに、カーネルのオーディオプレーヤMMは、上記した様式でそれに無音パケットを送信する。
【００５２】
これは、一曲の終わりを読み込むことから次の曲の始めを読み込むことに自動的に切り替わることを許容する。
【００５３】
図9は、一実施形態に従って一曲の音楽の送信を停止するための方法を例示する。
【００５４】
オーディオアプリケーションMPLは、要求RQ_STP1を用いて、オーディオ周辺装置MDEVによる一曲の音楽の再生を停止するようカーネルのオーディオプレーヤMMに依頼する。カーネルのオーディオプレーヤMMは、要求RQ_STP2を用いて、一曲の音楽を再生するのを止めるようオーディオ周辺装置MDEVに依頼する。
【００５５】
オーディオ周辺装置MDEVは、メッセージSTP2_OKを用いて、それが再生するのを止めたことをカーネルのオーディオプレーヤMMに認める。カーネルのオーディオプレーヤMMは、メッセージSTP1_OKを用いて、オーディオアプリケーションMPLに、それが再生するのを止めたことを通知する。
【００５６】
オーディオアプリケーションMPLは次いで、メッセージRQ_NMを用いて、通常モード(非オーディオ愛好家)に戻るようオーディオプレーヤMMに依頼する。
【００５７】
カーネルのオーディオプレーヤMMは、要求RQ_RECONF1を用いて、カーネルのオーディオサービスにオーディオ周辺装置MDEVの再構成を依頼する。カーネルのオーディオサービスは、要求RQ_RECONF2を用いて、オーディオ周辺装置MDEVに要求された再構成を依頼する。オーディオ周辺装置MDEVは、通知RECONF2_OKを用いて、それが再構成されたとカーネルのオーディオサービスに応答する。カーネルのオーディオサービスは、通知RECONF1_OKを用いて、カーネルのオーディオプレーヤMMに、オーディオ周辺装置MDEVが再構成され(そして再び使用される準備ができている)ことを通知する。
【００５８】
カーネルのオーディオプレーヤMMは次いで、要求RQ_FRを用いて、オーディオ周辺装置MDEVの排他的予約を終わらせるようカーネルのオーディオサービスに依頼する。カーネルのオーディオサービスは、通知FR_OKを用いて、それがこの排他的予約を実際に終わらせたと応答する。カーネルのオーディオプレーヤMMは、オーディオアプリケーションMPLにそのように通知する。
【００５９】
カーネルのオーディオプレーヤMMは次いでカーネルからアンロードされ得、そしてその前に、それはカーネルモードのバッファを解放できる(ステップUNLD)。オーディオ周辺装置MDEVの制御は次いでオペレーティングシステムに返され得る。
【００６０】
図10は、一実施形態に従ってカーネル空間でのバッファを例示する。例示されるバッファは現在読み込まれているオーディオデータを備える。現在の読込み位置はポインタRD_POSによって識別される。バッファにロードされたオーディオデータの終わりはポインタPOS_END_LD_AUによって識別される。曲の終わり位置(それがバッファに位置するとして)はポインタPOS_END_AUによって識別される。バッファ終わり位置はポインタPOS_END_BUFによって識別される。
【００６１】
第1の実施形態は、コンピュータPCのマルチメディアデバイスMDEVを介して(音楽ストリームMUSまたはビデオストリームMOVなどの)マルチメディアストリームを送信するための方法に関する。
【００６２】
可能な一実装では、マルチメディアデバイスは、(サウンドカード、グラフィックカードまたは両方の組合せなどの)ハードウェアデバイスであり、コンピュータの一体部品である。代替実装では、マルチメディアデバイスはコンピュータの外部であり、かつ(有線または無線接続によって)それに単に接続される。
【００６３】
コンピュータはたとえばパーソナルコンピュータ(ラップトップまたはデスクトップ)であるが、しかしそれはたとえば移動電話、タブレット、MP3プレーヤ、スマートウォッチ、サーバまたはネットワークドライブであってもよい。可能な一実装によれば、そのようなネットワークドライブは、(内部ストレージからおよび/またはコンピュータネットワークからマルチメディアストリームを読み込むことが可能な)コンピュータ部も人間の耳に識別可能な様式でマルチメディアストリームを再現することができるハイファイ部分も両方とも含む統合ハウジングの全部または一部を構成する。
【００６４】
コンピュータは、ユーザモードでおよびスーパーバイザモードで動作することが可能な少なくとも1つのプロセッサMPを備える(それはマルチコアまたはシングルコアプロセッサでよい)。ユーザモードでは、プロセッサは資源(メモリ、周辺装置など)へのアクセスを(オペレーティングシステムの制御下で)相当厳密に検証しており、これにより(ユーザモードで実行される)特定のソフトウェアが資源を独占してコンピュータクラッシュを引き起こすのを、またはそれがアクセスすることができることになっていない機密情報へのアクセスを得るのを防止する。ユーザモードはしたがってソフトウェアによって使用されるデフォルトモードである。しかしながら、ユーザモードが増強した制御を受けるという事実は、ユーザモードがより遅くかつ応答しにくいことを意味する。ユーザモードで動作するソフトウェアによってメモリが割り振られると、それはユーザ空間(他のプログラムのおよびオペレーティングシステムのメモリにアクセス可能でない空間)に割り振られる。メモリがスーパーバイザモードに割り振られると、それはカーネル空間、すべての資源が見える空間に割り振られる。カーネル空間では、コンピュータによって実行されるすべてのソフトウェアによって使用される物理メモリの部分にアクセスすること、および非常に危険であり得る変更(情報を削除、それを置換など)を行うことさえ可能である。スーパーバイザモード(カーネルモードとも呼ばれる)では、プロセッサはしたがってコンピュータ資源、特にメモリへのほぼ無制限のアクセスを有する。カーネルモードはしたがって、通常オペレーティングシステムカーネルのために予約されており、これが低レベル機能(デバイスドライバ、ハードウェアアクセスなど)を管理する。
【００６５】
第1の実施形態によれば、コンピュータは、プロセッサによって読取り可能なかつマルチメディアモジュールMMを記憶している(磁気ハードドライブHDD、またはフラッシュメモリなどのメモリから成るソリッドステートドライブSSD、または任意の他の種類の記憶媒体などの)記憶媒体を備える。マルチメディアモジュールMMはたとえば、CまたはC++など、(たとえば、ある種のインタープリタ型言語とは対照的に)十分に高性能を保証する言語で書かれたプログラムをコンパイルした結果である。マルチメディアモジュールは、アセンブリ言語で直接書かれたソフトウェアをアセンブルした結果でさえあってよく、これは性能最適化をさらに最適化できる。マルチメディアモジュールは、それがC言語などの言語で部分的に書かれ、(性能観点から重要な)いくつかの部分がアセンブリ言語で直接書かれたプログラムをコンパイルした結果であり得るという意味で、組合せでもよい。
【００６６】
マルチメディアモジュールMMは、スーパーバイザモードでプロセッサMPによって実行されるように設計される。このマルチメディアモジュールはたとえば、マイクロソフトウィンドウズ(登録商標)、リナックス(登録商標)、OS X、アンドロイド、iOS、ウィンドウズ(登録商標)フォン、ブラックベリー、シンビアンなどといった従来のオペレーティングシステムでよい、コンピュータにインストールされるオペレーティングシステムのカーネルに統合される。このマルチメディアモジュールはたとえば、デバイスドライバ、特にマルチメディアデバイスMDEVを管理するデバイスドライバに統合されてよい。このマルチメディアモジュールは代替的に、そのようなデバイスドライバと同じレベルでインストールされてよい(が、しかしそこに統合されない)。マルチメディアモジュールは、(オンデマンドで)動的にロードされるカーネル拡張に統合されることも、またはモノリシックカーネル内に直接統合されることもあり得る(したがって特にこの使用のためのカーネルをコンパイルすることが可能である)。スーパーバイザモードでのマルチメディアモジュールの実行は向上した性能を与える。特に、それは、並列にしかしユーザモードで動作する他のモジュールより優先度を享受できる。スーパーバイザモードでの実行は、マルチメディアデバイスの要求(それが現在再生しているマルチメディアストリームの次の部分を受信する要求を含んでよい)に対する応答時間を改善する。これは、とりわけ応答処理の実行がこの場合にはユーザモードでの呼出しルーチンを必要としないので、ユーザモードで動作するすべてのモジュール以上のマルチメディアモジュールの優先度のために、マルチメディアストリームによって搬送される信号の時間精度を改善する。ユーザモードでマルチメディアストリームを送信するために必要とされるものより少ないスーパーバイザモードでマルチメディアストリームを送信するために必要とされる活動があるので、この活動に関連した(電磁を含む)雑音は低減される。
【００６７】
送信するための方法は、マルチメディアモジュールによる、少なくとも10秒のマルチメディアストリームを(いくつかあれば、まとめて)含むように配置される1つ(または代替的に複数)のバッファBUFの、カーネル空間での割振りの実装を含む。このバッファは、カーネル空間に位置することに加え、したがって先行技術より非常に大きなサイズを有し、これはマルチメディアストリームの送信の連続性を保証することを可能にする。
【００６８】
マルチメディアモジュールによってマルチメディアデバイスに送信されるマルチメディアストリームはデータの形態であり、それは、マルチメディアデバイスに到達する前に、マルチメディアデバイスのためのデバイスドライバおよびコンピュータオペレーティングシステムのカーネルのモジュールを含む、いくつかの中間要素を通過することが多い。新たなデータが(そのようなカーネルモジュールによって使用され得る)バッファに規則的に記憶されて、マルチメディアストリームの送信の連続性を保証する。このバッファのために(少なくとも10秒のマルチメディアストリームに対応する)従来にないサイズを使用することは、非常に大きな単位サイズの(マルチメディアプレーヤなど、マルチメディアストリームのソースからマルチメディアモジュールへの)データ転送を可能にし、したがってマルチメディアデバイスへのマルチメディアデータの送信中のこれらの転送数を大いに削減する。これは、したがって新たなデータを要求および送信するための発生される追加の活動を大いに限定する。これは、この追加の活動によって発生される電磁干渉をそれに応じて低減させる。
【００６９】
バッファの大きなサイズは、したがってマルチメディアソースからデータを得ることを一時的に阻止するいかなる中断も最高10秒以上の期間の間、補償され得るという点で有利である。
【００７０】
可能な一実装によれば、10秒閾値は厳密ではなく、そして約10秒を意味すると理解される(たとえば、9秒で十分よい)。先行技術のバッファの時間幅は1秒未満であり、そして本発明に係るバッファのそれは、それが非常に長い(少なくとも10倍長い)という点で優れている。
【００７１】
そのような時間幅(少なくとも10秒)は、コンピュータを減速または大いにしかし一時的に中断させることがあり得る現象の、マルチメディアストリームの送信への影響に対処するのに十分なようである。そのような現象は、たとえばRAMの一時的な不足に関連があることがある。そのような場合には、仮想メモリを使用して不十分なRAMを補足することが一般的である。この仮想メモリは、RAMより非常に遅いが非常に大きな容量の大容量記憶媒体(典型的にハードドライブ)に基づく。送信されるべきマルチメディアストリームの一部分が仮想メモリに位置する場合、メモリスワップ動作を行ってそれにアクセスすることが必要であり(単語「スワップ」は「交換」を意味する)、その間に大容量記憶装置に(たとえばハードドライブに)記憶されるマルチメディアストリーム部分を表すデータがRAMへロードされて、長時間使用されていなかったデータを置き換える。このメモリスワップ動作は長時間かかることがあり、そのためマルチメディアストリームの送信の中断を(先行技術の解決策のコンテキスト内で)引き起こすことがある。大きなバッファの使用は、マルチメディアストリームの送信の中断を引き起こさずに、時折必要とされるメモリスワップを緩和することを許容する。そのような現象はまた、バックグラウンドタスクの自動実行のための準備段階と関連付けられ得る。これらは特に、アンチウィルスソフトウェア、(コンピュータのハードドライブに新たに保存されたデータをアーカイブ媒体にコピーする)自動データバックアップソフトウェア、(デフラグメンテーションなどの)自動ハードドライブ保守、コンピュータにインストールされているソフトウェアへの更新の自動検索などのためでよい。これらの準備段階は、たとえそれらがRAMの容量を超える結果にならないとしても、プロセッサへの著しい負荷に至り得る。スーパーバイザモードでの動作はユーザモードで動作するモジュールに与えられるであろうより高いプロセッサ利用率を保証し、したがってマルチメディアストリームの送信が影響されるという可能性を低減させる。その上、たとえ(ユーザモードで動作するモジュールを必要に応じて使用してよい)マルチメディアストリームのソースがそのような準備段階のために一時的にデータを切らすとしても、大きなバッファは、少なくとも10秒間そのようなデータ不足を補償する。
【００７２】
送信するための方法は、マルチメディアモジュールによる、(たとえばネットワークを介してリモートサーバからの、またはローカルハードドライブもしくはUSBキーなどのローカルストレージからの)マルチメディアストリームの受信、およびバッファでのその記憶の実装を含む。このマルチメディアストリームは、バッファ容量に対応するマルチメディアストリーム部分であると理解される。したがって、少なくとも連続10秒のマルチメディアストリームを維持することが可能であり、そしてバッファ内容が送信されるにつれて、それは、バッファを可能な程度まで絶えず満杯に保つ様式で、上記受信に類似して受信されるマルチメディアストリームの後続の部分と置き換えられる。
【００７３】
送信するための方法は、マルチメディアモジュールによる、バッファBUFに記憶されたマルチメディアストリームの、マルチメディアデバイスへの送信の実装を含む。可能な一実装によれば、この送信は、バッファBUFから小さなマルチメディアストリームパケットを送信することによって実行され、上記パケットのサイズがマルチメディアデバイスMDEVによって定められている。
【００７４】
マルチメディアストリームはいかなるソースから届いてもよい。それはコンピュータに記憶されるファイルから届いてよいが、しかしそれは外部エンティティ、たとえばリモートサーバから(たとえば「ストリーミング」と呼ばれ、時には直接ストリーミングまたは連続再生と呼ばれる技法を用いて)届いてもよい。
【００７５】
第2の実施形態において、第1の実施形態に係るマルチメディアストリームを送信するための方法は、マルチメディアモジュールMMによる、マルチメディアストリームの送信中のマルチメディアデバイスMDEVの排他的予約RESの実装を含む。マルチメディアモジュールMMがマルチメディアデバイスMDEVにストリームを送信しているとき(限り)、いかなる他のソフトウェアも、したがって、同じマルチメディアデバイスへの同時アクセスを要求することによってモジュールに干渉することができない。たとえば、マルチメディアデバイスがサウンドカードである場合、電子メッセージソフトウェアでの電子メールの受信は、マルチメディアストリームの送信に重畳され(または割り込み)得るだけでなく、(たとえば、電子メールソフトウェアが同じマルチメディアデバイスにアクセスしようと試みており、したがって上記マルチメディアデバイスの資源を消費するという事実に関連した雑音を発生することによって)そのような送信を中断させることもあり得る種類の時期外れの音をトリガすることができないであろう。
【００７６】
可能な一実装によれば、マルチメディアストリームの送信は、(たとえば一時停止を要求するユーザ介入を除いて)連続的であり、そして当該マルチメディアストリーム全体の送信の終わりまで(たとえば映画全体の完全再生の終わりまで)予約は排他的なままである。排他的予約は、したがってマルチメディアストリーム全体を送信することの前提条件として(たとえば、映画の始めの直前に)生じ、そして新たなマルチメディアストリーム部分の各受信に応じて排他的予約を更新する必要なしで(当初の排他的予約が持続する)、(マルチメディアストリーム部分の受信およびマルチメディアストリーム部分の送信を多く含む)映画の全体を通じて効力があり続け得る。
【００７７】
可能な一実装によれば、排他的予約は、コンピュータにインストールされているオペレーティングシステムのカーネルで行われる。この実装は、マルチメディアデバイスドライバまたはマルチメディアデバイスを制御するカーネルモジュールの、所定のマルチメディアソース以外のアプリケーションとのいかなる接続も拒否する機能を組み込んだ新たなデバイスドライバ(または新たなカーネルモジュール)との置換えを含む。マルチメディアソースは、たとえば(アプリケーションモジュールの形態の)マルチメディアプレーヤであり、このアプリケーションモジュールのみが新たなデバイスドライバ(またはドライバ)によって承認されている。可能な一実装によれば、機能は、マルチメディアソース識別子、および一方の値が排他的予約が必要とされることを示し、そして他方が排他的予約がより長く必要とされることを示すビットを、入力パラメータとして受ける。可能な一実装によれば、この機能は、たとえば排他的予約を要求することを承認された1つまたは複数のマルチメディアソースを予め定め、そしてそのように予め定めた承認アプリケーションのリストに記載されているもの以外のいかなるアプリケーションも排他的予約を行うのを防止することによって、安全になる。可能な一実装によれば、承認ソースが1つあるのみであり、そして機能は入力パラメータとしてソース識別子を受けない。可能な一実装によれば、マルチメディアストリームの送信に関連するデバイスドライバ(またはカーネルモジュール)のすべて(または代替的に一部)の機能が変更され、その結果これらの機能は、排他的予約がなされたとき、かつ呼出しアプリケーションモジュールが排他的予約が要求された対象ではないことをそれが確認したときにエラーコードを返す。
【００７８】
別の可能な実装では、排他的予約は、コンピュータにインストールされているオペレーティングシステムのカーネルで以下の通り行われる。カーネルでアプリケーションモジュールとマルチメディアデバイスドライバとの間のインタフェースを提供するインタフェースモジュールが、前項に記載したものと同様の様式で、所与のマルチメディアソース以外のアプリケーションとのいかなる接続も拒否することを許容する機能を組み込んだ新たなインタフェースモジュールと置き換えられる。
【００７９】
別の可能な実装では、排他的予約は、コンピュータにインストールされているオペレーティングシステムのアプリケーション層で行われる。オペレーティングシステムは、マルチメディアデバイスへの排他的アクセスを予約する機能を提供する。マルチメディアプレーヤアプリケーションなどのマルチメディアソースが、排他的予約を確立するためにオペレーティングシステムのこの機能を呼び出す。
【００８０】
可能な一実装では、バッファは循環バッファである。マルチメディアモジュールは、(循環バッファに含まれ、かつ送信されようとするマルチメディアストリーム部分を指す)マルチメディアストリームの開始へのポインタ、および(循環バッファが満杯であればマルチメディアストリームの開始へのポインタと同一であり得る)マルチメディアストリームの終了へのポインタを維持する。
【００８１】
1つの可能な表記法によれば、(マルチメディアストリームの始めに対応するメモリアドレスに関係なく)マルチメディアストリーム開始ポインタに値ゼロが割り当てられる。たとえば、アドレス0x03000000からアドレス0x031AEA9Fまでのメモリの領域を占有する、1,764,000バイト(または16進法表記で0x1AEAA0バイト)の循環バッファを考える。そのような循環バッファは、したがって44.1kHzの周波数で、チャネル当たり16ビットでサンプリングされる10秒のステレオオーディオデータを含み得る。マルチメディアストリームの始めは、したがって0x03000000から0x031AEA9Fまでのいかなるアドレスでもあり得る(たとえばアドレス0x0305ABE6)。マルチメディアストリーム開始アドレス@DFMに関係なく、従来は値ゼロは、マルチメディアストリームのこの開始へのポインタに割り当てられる。循環バッファ内に位置する任意のアドレス@Qへの任意の他のポインタと関連付けられる値は、次いで従来は(@Q+SZBUF-@DFM)Mod SZBUFに等しいとして定義され、SZBUFはバッファのサイズを指している(たとえば上記例で1,764,000)。2つのマルチメディアストリーム開始および終了ポインタが異なる値を有すれば、マルチメディアモジュールは、2つのポインタが同じ値を有するまで循環バッファにより多くのマルチメディアストリームを受信しようと試みる。マルチメディアストリーム開始ポインタに対応するメモリアドレスが、バッファ内容が徐々に送信されるにつれて変化し続け、しかも循環的にそうなるにもかかわらず、この表記法では、それにゼロ基準値を永久に割り当て得る。
【００８２】
もちろん、いかなる他の表記法も可能である。
【００８３】
第3の実施形態において、第1または第2の実施形態に係るマルチメディアストリームを送信するための方法のマルチメディアモジュールMMは、ユーザモードでプロセッサMPによって実行されるマルチメディアプレーヤMPLからアクセス可能なインタフェースINTを含み、送信するための方法は、上記インタフェースINTを介したマルチメディアプレーヤMPLによる、バッファBUFにおける任意の所与の読込み位置を選択する要求の、マルチメディアモジュールMMへの送信SNDを含む。したがって、マルチメディアモジュールは、単にバッファの始めなどの所定の位置ではなく、バッファにおける任意の位置での読込み位置を選択することを許容する。これは特にバッファのサイズに鑑みて有利である。そのような選択は、任意の読込み位置を選択することが有用でないほど短い先行技術のバッファに合わせたサイズのバッファの場合、重要ではない。
【００８４】
別の実装では、バッファは上述した実装に係る循環バッファであり、マルチメディアモジュールはしたがって、マルチメディアストリーム開始ポインタおよびマルチメディアストリーム終了ポインタを維持する。任意の所与の読込み位置を選択する要求は次いで、マルチメディアストリーム開始ポインタの値とマルチメディアストリーム終了ポインタの値との間に値がある第3のポインタに関係する(これらのポインタの値が上述した表記法に従って定められるとき)。循環バッファからのマルチメディアストリームの送信は次いで、マルチメディアストリーム開始ポインタからではなく(選択がなされたときの)第3のポインタによって定められるアドレスから始まって生じる。したがって、より多くのマルチメディアストリームを受信することができなければならないことなく急速に前後に移動することが可能であるが、但しそのような急速な前後の移動が循環バッファの内容に限定される。任意の所与の読込み位置の選択を実装するこの第3のポインタなしでは、いかなる特殊機能もなければ、早送りに続く急速巻戻しは新たなダウンロードを暗示する。実際、一旦マルチメディアストリーム開始ポインタが前方にジャンプして移動されると、マルチメディアストリーム開始ポインタ前にどんな内容が位置するかを知ることが不可能であれば、後方にジャンプすることは可能ではない(前内容は他の内容の受信によって上書きされてしまったかもしれない)。
【００８５】
可能な一実装によれば、マルチメディアモジュールは、インタフェースINTによる読込み位置を選択する要求の受信に応じて時間遅延をトリガするように配置される。可能な一実装によれば、時間遅延の長さは、バッファが含み得るマルチメディアストリームの最大長さと同じ桁である。この時間遅延は、インタフェースINTによる読込み位置を選択する別の要求のいかなる新たな受信によっても割り込まれ、受信がそのような時間遅延を(あたかも一切前になかったかのように)再びトリガする。時間遅延の間、マルチメディアモジュールは、最初は新たに選択された位置に先行し(その後送信される現在のサンプルに直に先行するように、循環バッファの内容が送信されるにつれて、移動される)スライド領域(循環バッファ)を上書きするのを防止される。このスライド領域は最初は、新たな読込み位置の選択のために送信されないデータを含む。次いで、時間遅延の間、スライド領域は、だんだん少ない未送信データおよびますます多くの既送信データ(しかし送信するための方法のユーザの命令に応じて、再送信される必要があるかもしれない)を含む。より詳細には、マルチメディアモジュールは、時間遅延の間、そのように保護されたバッファ領域に書き込むことなく、最大までバッファを満たそうと努める。一実装では、この保護領域の最大サイズは、たとえば5秒である全循環バッファに含まれるマルチメディアストリームの最大時間幅の半分に対応する時間幅に設定される。1秒より大きいが、循環バッファのサイズより実質的に小さい(たとえば循環バッファのサイズの80%)いかなる他の時間幅も選択され得る。
【００８６】
たとえば、1分の循環バッファ、2分の時間遅延および30秒の保持されるべき領域の最大サイズと考える。バッファが満杯である(特定の問題がある、またはマルチメディアストリーム全体の終わりが到達された場合を除き、マルチメディアストリームの送信中の通常の場合)としよう。送信するための方法のユーザが20秒前進したい場合(たとえば現在のマルチメディアストリームが退屈または不快であり、そしてユーザがそれをスキップしたい場合)、インタフェースINTは20秒前進した結果になる命令を受信する。再生されない20秒に対応するデータを(少なくとも処理能力が許容する程度に)直ちに上書きする代わりに、時間遅延は、これらのデータを保持することを許容する。より詳細には、早送りのまさに始めで、マルチメディアモジュールは、それが(20秒の前進のために)最後の20秒しか有しないので、30秒保持できず、したがって10秒間何も書き込むことができない。そして1分と50秒間の場合、それは最後の30秒保持し、そしてこの時間後、それはマルチメディアストリームの現在の瞬間に先行する30秒を保持しようと試みることなく循環バッファを再び完全に満たす。同じ構成で、ユーザが今20秒の代わりに40秒前進することを望む場合、マルチメディアモジュールは現在の瞬間に先行する30秒以上の先行ストリームに対応する10秒の保存されたマルチメディアストリームを(処理能力によって許される程度に)直ちに上書きでき、そして次いで次の2分間、最小で30秒維持する。この機能の1つの目的は、たとえば、誤って前方にジャンプした、または実際に所望したより自分が前方にジャンプしたと気付いたユーザが、マルチメディアストリームのソースとの接続が悪いときでも、特に満足すべき平均処理能力を提供するが、頻繁な中断を有する非常に不規則な接続の存在下で、即座に巻き戻すことができるようにすることである。
【００８７】
第4の実施形態において、上記実施形態の1つに係るマルチメディアストリームを送信するための方法のマルチメディアストリームはオーディオストリームMUSであり、そしてマルチメディアデバイスMDEVはデジタルアナログ変換器DACを備える。この実施形態は高品質(ハイファイ)オーディオの送信を可能にする。
【００８８】
第5の実施形態によれば、コンピュータプログラムが、プロセッサによって実行されると、先行の実施形態の1つに係る方法を実装する一連の命令を備える。このコンピュータプログラムはC言語、C++言語またはアセンブリ言語で書かれてよい。
【００８９】
第6の実施形態において、コンピュータ可読非一時的記憶媒体(たとえばハードドライブHDD、またはフラッシュメモリもしくはEEPROMなどの不揮発性メモリ)が、第5の実施形態に係るコンピュータプログラムを備える。
【００９０】
第7の実施形態によれば、マルチメディアストリームを送信するためのシステムがコンピュータPCとマルチメディアデバイスMDEVとを備え、コンピュータPCがユーザモードでおよびスーパーバイザモードで動作することができるプロセッサMPを備えており、コンピュータがプロセッサMPによって読取り可能なかつマルチメディアモジュールMMを記憶している記憶媒体HDDを備えており、マルチメディアモジュールMMがスーパーバイザモードでプロセッサMPによって実行されるように配置されている。
【００９１】
送信するためのシステムは、少なくとも10秒のマルチメディアストリームを含むように配置されるバッファBUFを、カーネル空間で割り振るための電子回路AL_Cを備える。可能な一実装によれば、割振り回路はプロセッサおよびメモリを備え、上記メモリが、少なくとも10秒のバッファBUFのカーネル空間での割振りを実装するように配置されるコンピュータプログラムを含んでいる。プロセッサは、(他の回路と共有されてよい)コンピュータの中央処理装置、または専用プロセッサでよい。メモリは、(他の回路と共有されてよい)コンピュータのメインメモリ、または専用メモリでよい。それは非一時的メモリでよい。
【００９２】
送信するためのシステムは、マルチメディアストリームを受信し、そしてそれをバッファBUFに記憶するように配置される、上記マルチメディアストリームを受信するための電子回路REC_Cを備える。可能な一実装によれば、受信回路はプロセッサおよびメモリを備え、上記メモリが、上記マルチメディアストリームを受信し、そして上記バッファBUFに記憶するように配置されるコンピュータプログラムを含んでいる。プロセッサは、(他の回路と共有されてよい)コンピュータの中央処理装置、または専用プロセッサでよい。メモリは、(他の回路と共有されてよい)コンピュータのメインメモリ、または専用メモリでよい。それは非一時的メモリでよい。
【００９３】
送信するためのシステムは、バッファBUFに記憶されたマルチメディアストリームを、マルチメディアデバイスMDEVに送信するための電子回路EM_Cを備える。可能な一実装によれば、送信回路はプロセッサおよびメモリを備え、上記メモリが、バッファBUFに記憶されたマルチメディアストリームをマルチメディアデバイスMDEVに送信するように配置されるコンピュータプログラムを含んでいる。プロセッサは、(他の回路と共有されてよい)コンピュータの中央処理装置、または専用プロセッサでよい。メモリは、(他の回路と共有されてよい)コンピュータのメインメモリ、または専用メモリでよい。それは非一時的メモリでよい。
【００９４】
第8の実施形態によれば、第7の実施形態に係るマルチメディアストリームを送信するためのシステムが、マルチメディアストリームの送信中の、マルチメディアデバイスの排他的予約のための電子回路RES_Cを備える。可能な一実装によれば、送信回路はプロセッサおよびメモリを備え、上記メモリが、マルチメディアストリームの送信中にマルチメディアデバイスMDEVを排他的に予約するように配置されるコンピュータプログラムを含んでいる。プロセッサは、(他の回路と共有されてよい)コンピュータの中央処理装置、または専用プロセッサでよい。メモリは、(他の回路と共有されてよい)コンピュータのメインメモリ、または専用メモリでよい。それは非一時的メモリでよい。
【００９５】
第9の実施形態によれば、第7または第8の実施形態に係るマルチメディアストリームを送信するためのシステムのマルチメディアモジュールMMは、ユーザモードでプロセッサMPによって実行されるマルチメディアプレーヤMPLからアクセス可能であるインタフェースINTを備え、送信するためのシステムが、マルチメディアプレーヤMPLが、バッファBUFにおける任意の所与の読込み位置を選択する要求を、上記インタフェースINTを介してマルチメディアモジュールMMに送信することを可能にする電子回路SND_Cを備えている。可能な一実装によれば、送信回路SND_Cはプロセッサおよびメモリを備え、上記メモリが、バッファBUFにおける任意の所与の読込み位置を選択するマルチメディアプレーヤMPLによる要求を、上記インタフェースINTを介してマルチメディアモジュールMMに送信するように配置されるコンピュータプログラムを含んでいる。プロセッサは、(他の回路と共有されてよい)コンピュータの中央処理装置、または専用プロセッサでよい。メモリは、(他の回路と共有されてよい)コンピュータのメインメモリ、または専用メモリでよい。それは非一時的メモリでよい。
【００９６】
第10の実施形態は、第7〜第9の実施形態の1つに係るマルチメディアストリームを送信するためのシステムに関し、マルチメディアストリームはオーディオストリームMUSであり、そしてマルチメディアデバイスMDEVはデジタルアナログ変換器DACを備える。
【００９７】
もちろん、本発明は例として上記した実施形態に限定されず、それは他の変形に拡張する。
【００９８】
本発明の方法に関する開示した特徴は本発明の対応するシステムへ移行され得、そして逆もまた同様である。楽曲に関して記載した実施形態は、非常に正確な同期が必要とされる場合、他の種類のマルチメディアストリーム、特にビデオストリーム、オーディオビデオストリーム、拡張現実感ビデオストリーム、または情報制御点灯装置(投光器、レーザなど)もしくは電気機械装置のストリーム(たとえば作業で特殊効果を実装するために現場の要素に接続されるロボットまたはアクチュエータを制御するストリーム)へさえ移行され得る。
【符号の説明】
【００９９】
AL_C  回路
BUF  バッファ
DAC  デジタルアナログ変換器
DRV  デバイスドライバ
EM_C  回路
HDD  ハードドライブ
INT  インタフェース
IO  入出力インタフェース
MDEV  マルチメディアデバイス、オーディオ周辺装置
MEM  メモリ
MM  マルチメディアモジュール、カーネルのオーディオプレーヤ
MOV  ビデオ
MP  プロセッサ
MPL  マルチメディアプレーヤ、オーディオアプリケーション
MUS  音楽、マルチメディアストリーム
PC  コンピュータ
REC_C  回路
RES_C  回路
SND_C  回路
【図１】
2018520398.tif 000003
【図２】
2018520398.tif 000004
【図３】
2018520398.tif 000005
【図４】
2018520398.tif 000006
【図５】
2018520398.tif 000007
【図６】
2018520398.tif 000008
【図７】
2018520398.tif 000009
【図８】
2018520398.tif 000010
【図９】
2018520398.tif 000011
【図１０】
2018520398.tif 000012
【国際調査報告】
2018520398.tif 000013
2018520398.tif 000014
2018520398.tif 000015
2018520398.tif 000016