[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]
[OSASK 822] Re: フォーマットについて.
こんばんは、Myurikaです。
Hidemi KAWAI さんにいただいた [OSASK 818] Re: フォーマットについて. へのお返事です。
>> TOWNSでも後期にはFIFOバッファ積んでましたし、それは当然なのだと思います。
>> しかし、16バイトじゃ足りないのです(笑)。作りの悪いMIDIの曲だと、一瞬に
>>して数十から、下手すると100バイトを超えるデータが発生することがあって、結
>>構困りものなのですね。
>># TOWNSのMIDIマネージャだと、人間にに判るぐらい処理が落ちることがありまし
>>た。
> この「処理落ち」というのに関して、2つの可能性が僕にはあるよう
>に思えます。Myurikaさんがどちらを想定なさっていたのかがわかりま
>せんが、とりあえず両方のケースについてお答えします。
>1.MIDIマネージャーは送ったつもりなんだけど、実はまだバッファに
> 溜まっていて、それが累積して微妙なところでテンポが狂う。
>2.単純にFIFOバッファがあふれて、あふれた分を送信するために割り
> 込みがちょくちょくかかり、そのせいで全体の処理が遅くなる。
実は、ですね。どちらも違っていたように思います。
要は、全てのデータの転送が終わるまで、ほとんど全ての処理がストップして
いたのです。割り込みで動いているハズのマウスも止まってました。
割り込み先から呼ばれているルーチンなのに、PIO転送でもしてたんでしょうか。
そんな乱暴が許されるのかどうか、私は知りませんが、少なくともそう見えまし
た。
まぁ、OSASK上で開発している以上、そんなことにはならないと思うんですが、
MIDIドライバの出来如何では、データの大量送信が危険なことには変わりありま
せん。
実際、ウチのMIDI I/Fに大量のデータを送りつけると、ドライバが死にます(泣
)。
1.については、ソフトウェアMIDIが出てきた頃からの宿命的な問題とも言えま
す。
送信バイト数に制限がなく、音の貧弱なソフトウェアMIDIで作曲をされる方は、
レイヤーという技術(全く同じ演奏を違うチャンネルで行うことで、音に厚みを持
たせるなどの効果がある)を使ったりもするのです。それによって、ある瞬間に
10音とか 20音とかのノートオン/オフが集中する、などということが起こり得ま
す。ていうか、そういうデータはそういうことばっかりです。
ソフトウェアMIDIを使っている以上、その遅延を体験できませんからね。
# もっとも、これはMIDIドライバマネージャの辺りでわざと遅延をかけることも
できるんですが(笑)。
>> で、その困りもののデータへの警告のために、送りきれない量のデータが発生
>>していることをプレイヤが認識できた方が個人的には嬉しいわけです。
> これは、1.のケースに対処するために必要、という意味でしたら、
>納得が行きます。・・・でしたら、busyなんていうあいまいなものでは
>なくて、未送信バイト数そのものをアプリケーションにお知らせいたし
>ます。これが0でなかったら、送信できていないデーターが存在すると
>いうことを意味しているわけです。もちろん、未送信データーについて
>は、FIFO内に入ってしまった分も含めて、アプリケーションが望んだタ
>イミングでキャンセルすることもできます。いかがでしょうか?
すばらしいです。
実は、未送信バイト数については、アプリかMIDIドライバの辺で割り出そうぐ
らいに思ってたんです(笑)。
それでは。
| Myurika (尾藤主和) myurika !Atmark! pop06.odn.ne.jp |