アカウント名:
パスワード:
タレコミの文章自体、ちょっと誤訳というか誤解してる感じですね。
Graphics workstations, and OpenGL applications may benefit from this, since it gives the lowest framerate-jitter
(グラフィックワークステーションはOpenGLアプリケーションにおいて、フレームレートのジッタを軽減するという利点がある)
ということだそうで。実際に秒2000回も表示しなければならないとか言ってるわけでなく、表示間隔のぶれ(ジッタ)を問題にしているのでしょう。
たとえば、割り込み周期が1000Hz だとすると、60Hz のリフレッシュレートの画面表示1回あたり、16.67回の割り込みが発生します。これで割り込みベースで処理すると、処理単位が17msの時と16msの時があるため、内部処理の時間間隔に1msのずれが発生する可能性があります。
このように、1000は60で割り切れないため、タイミングがずれて表示がなめらかにならないのを「フレームレートジッタ」と称しているのでしょう。
これを防ぐためには、割り込み周波数が表示周波数の整数倍になっているのが望ましい。一方、リフレッシュレートは60Hzとか72Hzとかいろいろあるので、とりあえずこのどちらの周波数に対しても4000Hz付近の数値の中でも最も誤差が少ない数値ということで、3956Hzが選ばれたのだと思います。
3956Hzは0.2528ms周期周期ですが、
60Hz:16.67ms←66×0.2528ms=16.68ms(誤差0.0169ms)が14回、67×0.2528ms=16.94ms(誤差0.2696ms)が1回72Hz:13.89ms←55×0.2528ms=13.90ms(誤差0.0140ms)が17回、54×0.2528ms=13.65ms(誤差0.2387ms)が1回
となり、ジッタが最小になります。
でも、アニメや映画のテレビ放送では、2-3プルダウンといって、24fps(42ms/コマ)の各コマを、秒60フィールドのテレビで、2フィールド(33ms)と3フィールド(50ms)で交互に表示という乱暴なことをしているので、それ見慣れた者としては、60fpsと1000Hz程度程度のずれなんて気になるわけないだろとちょっと思ってみたり。
ぴゅあおーでぃおの世界では、もっと厳しいところでズレが気になるつもりな人はたくさんいそうですけど…
このパッチを作られた方が投稿されたメーリングリスト内にある別記事を読んでみたのですが、この方は、DOOM3などのゲーム(OpenGLアプリケーション)のパフォーマンスを最適化しようとされているようですね。今回のチューニングの結果、wine上で動かしたHalf-Life:Sourceまでもが "quite a different experience" になったらしいです。ゲームがサクサク動くのならグラフィックワークステーションにも恩恵があるだろう、ということでしょうか。
デフォルトで1000Hzだった割り込み頻度を3956Hzも選択できるようにした、と言うことですが、この割り込み頻度が何を指してるのかわかりません。（ソースが上がってましたが60MBくらいあったので私には読むの無理ですｗ）勘ですけど（おい！）ハードウェア（ビデオカード、マウス、キーボード）から上がってきた割り込みをカーネルが受けて、それを各アプリケーションに通知する頻度を1000Hzに制限してる、ってことなんですかね？
そうだとすると、最悪1msec遅れる可能性があるわけで、（マウスorキーボード入力→ビデオカードで反映、ならさらに倍）60Hz(16.68ms)や72Hz(13.90ms)で次フレームの処理に入りたいアプリにとってはそれなりの損失かもしれません。
Linuxでゲームやったことないのでなんとも言えないのですが、現状でWindowsと比べて反応の鈍さとか感じられるんですかねぇ？（Windowsの実装がどうなってるかも知りませんけど）
元ネタを読むと「心理視覚最適化」なんて言葉を持ち出すのはなんか違うと思います。
unixのスケジュール粒度は昔は10ms程度が普通で（おおむかしはもっと遅かった）、それでも（ほぼ）静止画（キャラクタディスプレイとか、動画を伴わないGUI）だけ出せばすむころは、でまったく問題なかったのですが。インタラクティブな60FPSの描画とかをしたければ、プロセススケジューリングの時間粒度を小さくすると嬉しいんでしょうね。 たしか、昔のUNIX WSでもフライトシミュレータで本気で遊ぶために HZを変えるとかやってました。
3956という値そのものより、現状の1000より4倍早いってほうが効いてるのでは？
60*1001/1000では何度計算しても60より大きくなるような……という突っ込みはおいといて。
補足ですが、直感的に理解するなら、60と72の最小公倍数である360を基準に考えるといいと思います。つまり、厳密に60Hzと72Hzであるならば、360の10倍である3600、11倍の3960、12倍の4320などが「良い」値です。しかし現実の数字には1000/1001という呪い [ite.or.jp]がかかっているため、実は1000で割り切れる数に近い方が都合が「良い」。そこでピックアップされたのが3960であり、4000/1000=4ですから、4Hz減じた3956が最も合理的(この近傍ではジッダ最小)です。
NTSCのフレームレートは59.97Hzではなく、29.97Hzの倍の59.94Hzになりますね。理由は、この辺がわかりやすい（かな？）http://www.ite.or.jp/study/musen/tips/tip05.html [ite.or.jp]
そんな微少レベルの歪みを気にする人がスピーカの歪による音質低下を問題としないのは不思議なことです
あー、スピーカーの歪は「特性」って事になるのでは。別に正弦波がきちんと正弦波になることを期待してるんじゃなくて、自分の心地いいような歪み方になるのを期待してるわけですから＜オトキ●の人は
# そこがあの分野での定量化や定性化を妨げてるわけで…
そういう意味では入力と出力が歪んでることが分かっていてもそこは容易にかえようがないから、増幅段階で歪特性や周波数特性を都合のいいようにしましょう。と言うのははたから見ても合理性ありますよ。問題は手法が余りにダメなだけであって。
ちょっとソースが示せないのですが
スト２（ストリートファイター２）華やかなりし頃、上級プレイヤーは1/60フレームで4コマと5コマだかのアニメーションパターンの違いを見切ってたそうな4コマだとガード可だが5コマだと不可、とかなんとか。正確に何コマかは覚えてないですが
オーディオやってる人はΣΔ型A/D・D/Aのオーバーサンプリングの仕組みを理解していないだけです
シグマ・デルタ型A-D及びD-A変換におけるオーバーサンプリングを理解している者として、貴方には謝罪しなければいけません。過去に私の同類とされる者がご迷惑をおかけしました。そろそろ許してあげては頂けませんでしょうか。
その領域では間隔の正確さよりも誤差の平均が均されているかが重要かとそもそもΔΣは量子化誤差をその領域に追いやるというのが肝のはずだけど
http://archives.free.net.ph/message/20100529.115400.17a8ef44.ja.html [free.net.ph]パッチ投稿者が「3956 Hzは殆どの情報における人間感覚レジスタのプロファイルに合う」と言っていますね。ソースはどこなのだろうか。
ピュアオーディオの人たちにも朗報な予感。
linuxカーネルの話なんだから、ハードウェアはgivenでソフトウェアの設定でどの範囲でクロックやタイマー割り込みインターバルを変更できるか、って議論でしょ。ここは。」
それは4320Hzはだめで3956HzはOKという理由にはならんと思うが。そもそもこれって特定のハードウェアをターゲットにした話なのかね？
> 2-3プルダウンコマ送りで見る限り、最近はちゃんと2-1(前後フレームのミックス)-2に分割してるようですよ。
>コマ送りで見る限り、最近はちゃんと2-1(前後フレームのミックス)-2に分割してるようですよ。
最近の機械はたいてい24フレームでも再生できます。4倍速とかだと120フレームなので単に5回表示するだけです。そもそもプルダウンしてないのでは。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
3956 Hzの根拠 (スコア:5, 参考になる)
タレコミの文章自体、ちょっと誤訳というか誤解してる感じですね。
(グラフィックワークステーションはOpenGLアプリケーションにおいて、フレームレートのジッタを軽減するという利点がある)
ということだそうで。
実際に秒2000回も表示しなければならないとか言ってるわけでなく、表示間隔のぶれ(ジッタ)を問題にしているのでしょう。
たとえば、割り込み周期が1000Hz だとすると、60Hz のリフレッシュレートの画面表示1回あたり、16.67回の割り込みが発生します。
これで割り込みベースで処理すると、処理単位が17msの時と16msの時があるため、内部処理の時間間隔に1msのずれが発生する可能性があります。
このように、1000は60で割り切れないため、タイミングがずれて表示がなめらかにならないのを「フレームレートジッタ」と称しているのでしょう。
これを防ぐためには、割り込み周波数が表示周波数の整数倍になっているのが望ましい。
一方、リフレッシュレートは60Hzとか72Hzとかいろいろあるので、とりあえずこのどちらの周波数に対しても
4000Hz付近の数値の中でも最も誤差が少ない数値ということで、3956Hzが選ばれたのだと思います。
3956Hzは0.2528ms周期周期ですが、
60Hz:16.67ms←66×0.2528ms=16.68ms(誤差0.0169ms)が14回、67×0.2528ms=16.94ms(誤差0.2696ms)が1回
72Hz:13.89ms←55×0.2528ms=13.90ms(誤差0.0140ms)が17回、54×0.2528ms=13.65ms(誤差0.2387ms)が1回
となり、ジッタが最小になります。
でも、アニメや映画のテレビ放送では、2-3プルダウンといって、24fps(42ms/コマ)の各コマを、
秒60フィールドのテレビで、2フィールド(33ms)と3フィールド(50ms)で交互に表示という乱暴なことをしているので、
それ見慣れた者としては、60fpsと1000Hz程度程度のずれなんて気になるわけないだろとちょっと思ってみたり。
ぴゅあおーでぃおの世界では、もっと厳しいところでズレが気になるつもりな人はたくさんいそうですけど…
Re:3956 Hzの根拠 (スコア:3, 興味深い)
このパッチを作られた方が投稿されたメーリングリスト内にある別記事を読んでみたのですが、
この方は、DOOM3などのゲーム(OpenGLアプリケーション)のパフォーマンスを最適化しようとされているようですね。
今回のチューニングの結果、wine上で動かしたHalf-Life:Sourceまでもが "quite a different experience" になったらしいです。
ゲームがサクサク動くのならグラフィックワークステーションにも恩恵があるだろう、ということでしょうか。
デフォルトで1000Hzだった割り込み頻度を3956Hzも選択できるようにした、と言うことですが、
この割り込み頻度が何を指してるのかわかりません。（ソースが上がってましたが60MBくらいあったので私には読むの無理ですｗ）
勘ですけど（おい！）ハードウェア（ビデオカード、マウス、キーボード）から上がってきた割り込みをカーネルが受けて、
それを各アプリケーションに通知する頻度を1000Hzに制限してる、ってことなんですかね？
そうだとすると、最悪1msec遅れる可能性があるわけで、（マウスorキーボード入力→ビデオカードで反映、ならさらに倍）
60Hz(16.68ms)や72Hz(13.90ms)で次フレームの処理に入りたいアプリにとってはそれなりの損失かもしれません。
Linuxでゲームやったことないのでなんとも言えないのですが、
現状でWindowsと比べて反応の鈍さとか感じられるんですかねぇ？
（Windowsの実装がどうなってるかも知りませんけど）
元ネタを読むと「心理視覚最適化」なんて言葉を持ち出すのはなんか違うと思います。
Re:3956 Hzの根拠 (スコア:3, 興味深い)
unixのスケジュール粒度は昔は10ms程度が普通で（おおむかしはもっと遅かった）、それでも（ほぼ）静止画（キャラクタディスプレイとか、動画を伴わないGUI）だけ出せばすむころは、でまったく問題なかったのですが。インタラクティブな60FPSの描画とかをしたければ、プロセススケジューリングの時間粒度を小さくすると嬉しいんでしょうね。 たしか、昔のUNIX WSでもフライトシミュレータで本気で遊ぶために HZを変えるとかやってました。
3956という値そのものより、現状の1000より4倍早いってほうが効いてるのでは？
Re:3956 Hzの根拠 (スコア:2, 参考になる)
業務用では違う周波数を使います。
日米の放送など業務用途では 59.97Hz や 23.97Hz を使うのが一般的です（欧州は知らない）。
60ちょうどや24ちょうどの規格も存在しますが、ほとんど使われません（SMPTE-292Mなどを参照）。
# 59.97=60*1001/1000, 23.97=24*1001/1000で、なぜ1001なのかは、NTSCカラー化の時代に由来するんだったかな。
3956Hzでそれらの周期を表すと、
59.97Hz ≒ 3956Hz/66 (1周期の誤差185ns)
23.97Hz ≒ 3956Hz/165 (1周期の誤差4.6ns)
となって、けっこうよく一致します。
59.97Hzの場合1時間半で1msずれる計算ですが、そのような微妙な周波数（位相）ずれは別の方法で補正します。
Re: (スコア:0)
60*1001/1000では何度計算しても60より大きくなるような……という突っ込みはおいといて。
補足ですが、直感的に理解するなら、60と72の最小公倍数である360を基準に考えるといいと思います。つまり、厳密に60Hzと72Hzであるならば、360の10倍である3600、11倍の3960、12倍の4320などが「良い」値です。しかし現実の数字には1000/1001という呪い [ite.or.jp]がかかっているため、実は1000で割り切れる数に近い方が都合が「良い」。そこでピックアップされたのが3960であり、4000/1000=4ですから、4Hz減じた3956が最も合理的(この近傍ではジッダ最小)です。
Re: (スコア:0)
NTSCのフレームレートは59.97Hzではなく、29.97Hzの倍の59.94Hzになりますね。
理由は、この辺がわかりやすい（かな？）
http://www.ite.or.jp/study/musen/tips/tip05.html [ite.or.jp]
Re:3956 Hzの根拠 (スコア:1, 興味深い)
仮現運動の認知にその程度のずれなど関係ないでしょう
＞ぴゅあおーでぃおの世界では、もっと厳しいところでズレが気になるつもりな人はたくさんいそうですけど…
現在の市販製品の実力レベルのクロックジッタなど問題になりません
オーディオやってる人はΣΔ型A/D・D/Aのオーバーサンプリングの仕組みを理解していないだけです
（オーバーサンプリングしている分，ジッタによる歪は小さくなるのです）
そんな微少レベルの歪みを気にする人がスピーカの歪による音質低下を問題としないのは不思議なことです
(OT)オトキ●（Re:3956 Hzの根拠 (スコア:1)
あー、スピーカーの歪は「特性」って事になるのでは。
別に正弦波がきちんと正弦波になることを期待してるんじゃなくて、自分の心地いいような歪み方になるのを期待してるわけですから＜オトキ●の人は
# そこがあの分野での定量化や定性化を妨げてるわけで…
そういう意味では入力と出力が歪んでることが分かっていてもそこは容易にかえようがないから、増幅段階で歪特性や周波数特性を都合のいいようにしましょう。と言うのははたから見ても合理性ありますよ。
問題は手法が余りにダメなだけであって。
Re:3956 Hzの根拠 (スコア:1)
ちょっとソースが示せないのですが
スト２（ストリートファイター２）華やかなりし頃、上級プレイヤーは1/60フレームで4コマと5コマだかのアニメーションパターンの違いを見切ってたそうな
4コマだとガード可だが5コマだと不可、とかなんとか。正確に何コマかは覚えてないですが
Re: (スコア:0)
彼らの価値観では、
音質を調整する目的の回路は邪悪きわまりないが、
最小限の回路において音質が変化してしまう困った特性をもつ部品を使うことで音質をコントロールするのはピュアで良いことなのだそうです。
Re: (スコア:0)
シグマ・デルタ型A-D及びD-A変換におけるオーバーサンプリングを理解している者として、貴方には謝罪しなければいけません。
過去に私の同類とされる者がご迷惑をおかけしました。
そろそろ許してあげては頂けませんでしょうか。
Re: (スコア:0)
オーバーサンプリング、つまりサンプリング周波数をあげている分だけ
ジッタに影響されやすいはずなんですがねぇ。
等間隔サンプリングを前提としている信号処理システムでは、その等間隔が
崩れるとその後はすべて総崩れになります。Δ∑とて例外ではない。
つまり、オーバーサンプリングしている領域でジッタがあって等間隔
サンプリングが崩れると、どんな信号処理をしたってダメってこと。
Re: (スコア:0)
その領域では間隔の正確さよりも誤差の平均が均されているかが重要かと
そもそもΔΣは量子化誤差をその領域に追いやるというのが肝のはずだけど
Re: (スコア:0)
ごくベーシックなPCMの場合、44.1kHzのクロックのジッタが50%にもなれば、かなり歪んだ音になります。
しかし、デルタ・シグマの場合は、数MHzのクロックのジッタが50%になっても、あまり歪んだ音にはなりません。
ジッタは平均化されてゼロに近づきますし、クロックの個々のパルスのジッタ量は44.1kHzの1クロックに比べて
1/100とかですし。
Re: (スコア:0)
リンク先のさらに先を読んでもよくわからんです。
> ぴゅあおーでぃおの世界では、もっと厳しいところでズレが気になるつもりな人はたくさんいそうですけど…
彼らは発振器のジッタを語ることはあっても、データ元とDACのクロック差を語る
ことはほとんどない、とても面白い人たちです。
Re:3956 Hzの根拠 (スコア:1, 興味深い)
http://archives.free.net.ph/message/20100529.115400.17a8ef44.ja.html [free.net.ph]
パッチ投稿者が「3956 Hzは殆どの情報における人間感覚レジスタのプロファイルに合う」と言っていますね。
ソースはどこなのだろうか。
ピュアオーディオの人たちにも朗報な予感。
Re: (スコア:0)
きっと彼らは 3956Hz で変化する CPU の電源電流で鳴く、コイルやコンデンサの音が聞こえるに違いない。心地よいのだろうか？
Re: (スコア:0)
古くはRTCなど、インターバルな割り込みを入れてくれる何かは、何らかのクロックを2のN乗で分周したものを出力にする構造になっていますので。
Re:3956 Hzの根拠 (スコア:1)
linuxカーネルの話なんだから、ハードウェアはgivenでソフトウェアの設定でどの範囲でクロックやタイマー割り込みインターバルを変更できるか、って議論でしょ。ここは。」
Re: (スコア:0)
あなたの使っているシステムではそうでしょう。
例えば水晶発振子ならば、どんな周波数でも可能ですよ(プランク域は駄目だが)。通常はコストに合わないから作りませんが。
Re: (スコア:0)
それは4320Hzはだめで3956HzはOKという理由にはならんと思うが。
そもそもこれって特定のハードウェアをターゲットにした話なのかね？
Re: (スコア:0)
> 2-3プルダウン
コマ送りで見る限り、最近はちゃんと2-1(前後フレームのミックス)-2に分割してるようですよ。
Re: (スコア:0)
>コマ送りで見る限り、最近はちゃんと2-1(前後フレームのミックス)-2に分割してるようですよ。
最近の機械はたいてい24フレームでも再生できます。
4倍速とかだと120フレームなので単に5回表示するだけです。
そもそもプルダウンしてないのでは。
Re: (スコア:0)
Re: (スコア:0)
例えば、アナログキャプチャの映像をリアルタイムで表示する場合は入力した映像にモニタが同期して表示を更新しなければジッタが発生しますが、GPUとキャプチャカードのクロックが異なるので解決はほぼ不可能です。
CRTを使っていた頃は、Windowsのドライバと設定が異なるために表示位置がずれたり別の表示設定メモリとなることがあったのでXConfigを書き換えたりしましたが、解像度が違うと分周比が異なるのでリフレッシュレートは大まかな目安程度の意味しかありませんでした。
CR