サウンドプログラミング3

1 名前：デフォルトの名無しさん [2006/04/21(金) 07:54:35 ] 音のプログラミング処理について語りましょう 各エフェクタの組み合わせとか、 プログラミング外の話題はDTM板の方がいいよ サウンドプログラミング2 pc8.2ch.net/test/read.cgi/tech/1091054082/ サウンドプログラミング pc5.2ch.net/test/read.cgi/tech/996171508/ 411 名前：デフォルトの名無しさん [2007/03/19(月) 12:27:37 ] 誰かDAW作ってくれ 412 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 10:48:51 ] >>411 frieve 413 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 10:17:20 ] エフェクトのコーラスのうねりは時間で変化させるんですか？ それともpitchを変化させるんですか。 414 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 10:39:30 ] コーラス： 入力音を二つに分岐させる。 片方にモジュレーション（周波数変調）をかける。 二つを加算して出力。 415 名前：413 mailto:sage [2007/03/31(土) 10:55:39 ] コーラスとフランジャーは　モジュレーション大きさだけの違いだけなんですか？ 416 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 11:45:55 ] ・モジュレーション幅 ・モジュレーション速度 ・フィードバック量 ・分岐させた二つの加算割合 などを変化させることによってコーラス／ビブラート／フランジャーなどが作れる。 417 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 11:50:26 ] >>416 それの大きさで呼び名が変わるってこと？ なんどもすんません。 418 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 12:30:34 ] そういうこと。 モジュレーション幅が広めで速度が速いとコーラスっぽくて、 モジュレーション幅が狭めで速度が遅いとフランジャーっぽい。 フランジャーの場合はフィードバック量も関係してくることが多い。 419 名前：413 mailto:sage [2007/03/31(土) 12:34:58 ] サンキュです 420 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 12:36:08 ] いえいえ。 421 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:59:37 ] ぉぃぉぃ 一応混じれ酢すると ふらんじゃー： 数ms以下の短いディレイに変調をかけ、元音とミックスして、 　　　　　　　　　中〜高音域のコムフィルター効果でメタリックな響きを出す こーらす　　　：数十〜ms程度の比較的長いディレイに変調をかけ、元音とミックスして、 　　　　　　　　　(たぶん超低域のコムフィルター効果で)アンビエントな音のウネリを出す 422 名前：418 mailto:sage [2007/04/01(日) 22:34:53 ] >>421 補足サンキュ。418では変調速度と変調幅だけしか言及してなかった。 （変調幅を大きくする≒ディレイ値を大きくしないといけない 　という勝手な理解をしてしまったよ。） 確かにディレイ値のほうが大きな影響があるな。 423 名前：デフォルトの名無しさん [2007/04/02(月) 00:32:07 ] だけど、コーラスのきついやつがフランジャー、って理解でそう間違ってないでしょ? 424 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 00:33:53 ] おまぃに関してはおまぃの判断に任せる 425 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 01:31:19 ] コーラスのディレイの短いやつがフランジャー、って理解で間違ってない。 426 名前：413 mailto:sage [2007/04/02(月) 12:28:37 ] 勉強になります。 427 名前：418 mailto:sage [2007/04/02(月) 16:25:13 ] 理工系の大学とかで学術論文にアクセスできるのであれば、 Jon Dattorro. "Effect Design, Part 2: Delay-Line Modulation and Chorus". Journal of Audio Engineering Society, October 1997. とか、あとは「DAFx」という書籍もエフェクト関係の勉強になる。 両方とも英語なのがタマニキズ。 428 名前：デフォルトの名無しさん [2007/04/02(月) 17:10:08 ] >>425 登場経緯的には、フランジャーが先だよね? 浅めに(?)かけてみたら 12 弦っぽい 効果があって、それ目的でパラメーター調整しやすいようにアレンジして製品化した、と。 429 名前：413 mailto:sage [2007/04/04(水) 09:16:25 ] >>427 DAFxはいろいろ載ってておもしろそうですね。 Jon Dattorro 　Effect Designは見れなかった。残念 ただ、英語はダメなので気長にみてみます。 430 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 09:21:13 ] 基本的にはパラメーターのレンジを変えた、同じエフェクトと思っていいと思うけど、 実際には目的の違いから異なるアイデアを盛り込んでる場合が多いと思うよ。 たとえばコーラスはぶ厚く広げるのが目的だからディレイラインがすごく多いものとか、 変調が周期波形じゃないものとか、イロイロと。 そのへんがエフェクターの個性になってくわけだが。 431 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 04:03:47 ] 今までDSP買ってエフェクターやら作ってたんだけど、ふと思った。 いい加減今のＰＣならリアルタイム入出力のFIR処理くらい出来るんじゃないかと。 これが出来ればあらかじめフィルタ係数用意して切り替えるようにすれば ソフトウェアエフェクターってできそうだし。 で、作って見たがあえなく撃沈。音途切れ途切れ。 何が問題なんでしょう？？ １００万タップくらいのＦＩＲなら余裕で動くと思ってたのに。 432 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 07:58:42 ] あまり詳しくないのであれなんだが とりあえずSSEは使った?（PowerPCならAltivec 大きいFIRはFFT利用して劇的に計算コスト減らした実装ができるんじゃなかったけか？ 433 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 08:02:06 ] ちなみにリアルタイム入出力のコンボリューションリバーブとか普通にありますよ。 434 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 09:20:49 ] たいてい432の言うようにFFTかましてるよね。だからレイテンシーが問題になることも。 435 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 12:33:04 ] >>431 ハードウェアのことあんまり詳しくないんだけどフィルタ係数や入力信号のバッファ がL１ L２ 超えて外部になると一気にメモリ転送の問題が発生する気がする メモリのレイテンシーって結構デカイ気がするけど詳しい人教えて >>433 ちょっと俺も興味あるんだけど そのソフトの詳細希望 >>434 リアルタイムでFFTだとレイテンシーもだけどブロック間の繋ぎがどうなるんだろ 436 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 13:31:52 ] >そのソフトの詳細 今時のPCの音楽制作環境のことまるで知らないの？？ コンボリューションリバーブなんかはここ数年流行っててすでに一般的。たくさんあるぞ。 「コンボリューション VST」とかでぐぐってみなはれ 437 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 14:05:58 ] >>436 こういうのってリアルタイム入出力できるの？ 438 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 00:06:50 ] >>435 ブロック間のつなぎはoverlap-and-addでやるだけなので、大丈夫。 439 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 07:49:56 ] >>437 DSPプログラミングやってて、今時そうゆうの知らないことのほうが驚きですよ。 音楽制作と無関係な業界でやってる技術者だったりすると案外そうゆうもんですかね。 「DSP」っていう言葉も昔は主に専用チップ、Digital Signal Processorのことを指していたけど、 汎用PCによるリアルタイム処理が台頭してきた今は、 意味が広がってデジタル信号処理全般、Digital Signal Processingというニュアンスですよ。 440 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 08:12:27 ] FIRネタの書き込みは、どの板も具体的な話が欠落してるなｗ 厨？ 441 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 08:18:37 ] >440 単純に大量のかけ算するだけなら簡単だが、 FFT応用するとかいうと詳しい人なかなかいないんでしょ。 そうゆうおまいは？ 442 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 08:23:46 ] >>441 それも既出。 443 名前：デフォルトの名無しさん [2007/04/07(土) 10:12:17 ] >>435 ここでは板違いかもしれないけど、 たとえば、foobar2000のイコライザは8192Tapの firフィルタで、畳み込みにfftを利用している。 foobar2000のプラグインのconvolverは、大きな インパルスファイルを指定してやれば、 数万Tapの畳み込みも音がとぎれず再生する こちらも畳み込みにfftを利用。 （Tap数は表示されるFFT　Length　の半分） firフィルタはどうしてもレイテンシがでかくなるから リアルタイムの演奏や画像との同期は難しいけど パソコン上のファイルを変形させるならかなり使える。 「fft　overlap save」でググるよろし。 こことかは、お勉強の過程が書いてあって 参考になるかも。 ttp://junzo.10gallon.jp/ 444 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 15:15:53 ] 結局のところ今のPCじゃ時間軸での畳み込みはまだ無理ってことでFA？ 多分 436はその辺は考えてなかったんだろな 知識ひけらかす前に 431の質問を汲み取ってやれ 445 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 15:43:51 ] すいません、畳み込みリバーブのプラグインとかは時間軸での畳み込みとは違うんですか？ 446 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 16:45:19 ] 今手元に可逆圧縮済みrawがあって、これをwavにしなければならないんですけど、 ・rawデータはwavのヘッダ無し波形 ・どういう形で圧縮されているのか分からないのでデコードしようがない 一体圧縮済みrawはどういうフォーマットなんでしょうか？ 447 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 17:22:42 ] >>445 畳み込みリバーブと書いてあっても 実際はインパルス応答 入力信号を両方FFTしてオーバーラップ法を使った 周波数軸での畳み込みをしているのでは無いかということ この辺りは説明書とかみると書いてあるのかな？ 実際に最近のCPUで誰か真っ当な時間軸での畳み込みやって 何タップくらいいけるのか測定してみてくれYO ぉ サウンドプログラミグっぽくなってきたなおぃ 448 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 17:25:30 ] あ もちろんリアルタイム入出力での話ね オフラインなら何億タップだろうがメモリがあるかぎりいけるだろうからw 449 名前：445 mailto:sage [2007/04/07(土) 19:29:09 ] >>447 さらにすいません、 真っ当な時間軸での畳み込みというのと、FFTを使った周波数軸での畳み込み、 というのは結果が違うのですか? FFTを使った方法は軽いけどあくまで別物なんですか？ 450 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 21:14:20 ] >>449 （精度の問題を除いて）時間軸畳み込みと全く同じ結果が得られる方法がある。 451 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 21:32:48 ] 素人談義状態だな 452 名前：445 mailto:sage [2007/04/07(土) 22:14:09 ] >>450 なるほどです。 ちょっと調べてたらなぜ畳み込みにFFTが使われるのか、とてもわかりやすい説明みつけました。 ttp://www.nextftp.com/swlabo/m0_pctech/hp_ultraprecision/up_815_1.htm 周波数軸での畳み込み？、、、というのにあたるのかどうかよく理解できないのですが、 とにかく概算で約200倍速く計算できるようなこと書いてありました。 自分はFFT自体あまり理解できてないのですが、これ読むと魔法のようすね。 453 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 02:24:08 ] >>452 オーダーが違うからね。 FIR 長を N として、 普通に時間領域で畳み込みすると、O(N^2) FFT 使うと、O(N lon N)。 長さ N で FFT しちゃうと、そのサイトにある通り、循環畳み込みになっちゃうから、 実際には長さ2倍にして、半分 0 埋めてとかやる。 で、FFT ＋ 周波数領域で掛け算 ＋ 逆FFT ってなるんだけど、 2N log 2N ＋ N ＋ 2N log 2N とかで演算回数かかるけど、 O(N log N) だから、何千・何万タップとかになると圧倒的にこっちが早い。 454 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 05:27:24 ] >>451 煽りはいいから >>447 の試してソース公開してみろって 455 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 10:04:31 ] >>447 わざわざ最新のＣＰＵを買わなくなって計算の見積もりは出来るだろ。 そりゃ、ＤＳＰと違って、ＰＣの場合は演算能力の見積もりは難しいけど 44.1Kで 100万(1M)となると、モノラルで44.1G/Sの積和能力が必要になる ゲーム機のGPUなんかでは、無理に思えない数字に見えるだろうが パソコンだと、あと１０年程先だろうね 確かに100万となると20bitにもなるわけでゲーム機のような単精度でいくら 高速でも意味はないわけだけどさ。 あ、FFTを補助的に使ってリアルタイムに実現する方法もあるんで 456 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 11:01:08 ] 聞きかじり＆妄想が延々と続きます・・・ 457 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 11:30:08 ] 2^20のFFTを使うとすると 1048576-1000000 = 48576 サンプルが丁度いいサイズになる 1.1秒毎に22秒ほどのデータをFFTして処理するので、計算時間を無視して1.1秒の遅延が必要になる。 計算時間はこのシステムが動く最悪値と考えれば2.2秒の遅延が必要になる 別けて計算する方法は、１サンプルあたりのFIRフィルタの計算は Σ C[i]*D[i] たとえば 現在から1万サンプルのデータDaと 99万Dbに別けると Σ C[i]*D[i] = ΣC[i]*Da[i] + ΣC[i]*Db[i] ΣC[i]*Db[i]は１万サンプル以上前のデータなので、ＦＦＴを使う方法で１万サンプル分を先に計算出来る 残った１万サンプルだけをリアルタイムに計算すればいい 計算量は44100*10000 = 441M/Secなので、今のＰＣなら不可能な数字ではない 458 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 12:01:09 ] ttp://www.knufinke.de/sir/index_en.html 459 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 15:18:43 ] >>449 直線畳み込みと循環畳み込みをfftを利用して行うこととは 数学的に完全に等価です。 ですから、数千Tapｐを超えるｆｉｒフィルタの処理を行うとき 時間軸での畳み込み（直線畳み込み）をやるのは 無意味だと思いますね。 これが最強、最有名です。 ttp://www.ludd.luth.se/~torger/brutefir.html 460 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 15:53:22 ] ひたすらゴッグルさんのご神託を貼り付けるだけのスレｗ 461 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 15:57:07 ] この議論、数ヶ月前にも見たｗ 462 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 16:32:43 ] FFTを使う方法でもリアルタイムに出来るというのは前回無かったように思うが？ 463 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 16:49:50 ] で、この議論のどこら辺でリアルタイム手法が提案されたって？ 464 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 16:54:40 ] じゃあ　俺も妄想ね。 単精度32bitステレオで扱おうと思うとデータ量だけで フィルタ係数分左右で１タップ8byte 入力信号とあわせると16byteの記憶領域が必要。 １０万タップの時点で既に１．６Ｍの記憶領域が必要になってしまう。 それがどうしたという感じだが、もしこのデータを外部メモリから読み出そうとすると 最近のメモリで読み出しレイテンシーが10nsくらいだから 信号と係数を逐次読み込んで毎回積和をとるとしたら 1/10000sec が毎回読み出しだけで消費されてしまう時間。 さらにこれに積和時間と入力信号保持用にリングバッファなりしなければならない。 MMXにシフトレジスタ命令はあったはずだが。 まぁこれ考えるとＣＰＵキャッシュから外れるとメモリ読み出し時間 が一番のボトルネックになる気がするんだけど。 １０万タップもまったく現実的じゃないよな。 サンプリング8kでギリギリ読み出しが間に合う速度くらいｗ とするとL1最低でもL2にデータ保持できる量＝最大次数　くらいのノリにならねぇか？ キャッシュも自分でフルに使える分けじゃないし かなりローレベルなプログラミング技術が要求されるよなぁ 465 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 17:01:39 ] 何msまでの遅延ならリアルタイムと見なせるだろうか。 30msくらい遅れると明らかに違和感が出るよな。 10msくらいならおｋ？ 466 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 17:05:21 ] >>465 そもそも今いっているリアルタイムはそういう意味ではない。 一定量の遅延があるだけで出力し続けれるのならそれはリアルタイム処理。 　入力→演算→出力　 の流れが次の入力が来るまでに終っているかどうか（１サンプル内で演算が終っているかどうか） がリアルタイム処理の定義だと思われ 467 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 17:26:36 ] レイテンシー以前の話かよｗ 468 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 17:35:23 ] >>463 もちろんＰＣの場合はCODECとの通信がブロックでやってくるから、意味はないのだけど １サンプル毎に答えを出す手法について提案されているじゃないか? でも、コレ計算量の削減になるのかな？ 256点で考えてみよう。 64点を時間領域で　残りの192点をFFTで行うとする c0*d0+　・・・　+c63*d63 とc64*d64+・・・c255*d255 前半は O((N/4)^2)=O(N^2/16) =4096 後半は、64サンプル毎に256点のデータで行えば 64サンプル毎に１回処理するので 4*(2N log 2N ＋ N ＋ 2N log 2N )=4*2*N*( 1+2*log2N) = 4*2*256*17= 34816 うーん 469 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 17:42:11 ] >>464 単精度でＦＦＴ方式を10万タップで使うと、結果は上位8bitまでしか信用出来なくなる 浮動小数点なので、相対誤差だから十分良いといえば良いのだけどね あと１０万タップくらいならFFTでやれば今のＰＣならリアルタイム処理は行えるよ 実際やってるし。 だって２秒に１回計算すりゃいいんだから余裕。 素直に書いたルーチンでも１秒に１０回くらいは計算出来てるよ。 470 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 17:56:28 ] 256点でなく、一般化して考えてみる M分割した1/Mを時間領域で　残りをFFTで行うとする この方式との比率は、 ((N/M)^2 + M*2*N*( 1+2*log(N)/log(2)))/(N^2) N=2^8ではダメだったが、 N=2^16 M=16を代入すると 約1/50 N=2^20 にすると 1/200　と大きいほど改善するようだ さらに、細かく分割して効率化すれば、もっと効率上がるのかも 471 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 18:15:45 ] 計算間違いしてた こうか？ 　(((N/M)+M*( 1+4*log(N)/log(2)))/(N) N=2^16 M=16を代入すると 約1/12 でしかない 472 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 18:24:13 ] １０万タップにあてはめてみるとN=16 M=32で約1/20 この時の負荷はFFTだけで計算した場合の１００倍近い 473 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 19:50:03 ] >>464 確かに時間軸での畳み込みをプログラムで実装するとそこが問題になりそうだ。 ハードのこと全然詳しくないんだが。 というかその後の話が全部周波数軸での話しになってるのが妙にうけた。 あきらかに>>464の話は時間軸での計算なのになｗ FFTでの畳み込みは確かに早いんだけど精度とかアルゴリズム的なこと考慮しないといけないから面倒だな。 そういった意味では時間軸での畳み込みの限界を俺も見てみたい気がする。 474 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 19:55:58 ] > 最近のメモリで読み出しレイテンシーが10nsくらいだから > 信号と係数を逐次読み込んで毎回積和をとるとしたら > 1/10000sec が毎回読み出しだけで消費されてしまう時間。 1/10000[sec]/10[ns]＝10^-4/10^-8＝10^4[word] 1/10000secって一体なんの話？ 475 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 19:59:18 ] １０万個読み出し * 10ns と思われ　リードタイム？ 476 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:03:51 ] 10^5[個]×10^-8[sec]＝10^-3 10万個なら1/1000がメモリ読み込み時間 10^6[個]×10^-8[sec]＝10^-2 100万個なら1/100がメモリ読み込み時間 477 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:28:02 ] FFTを使おうが、Σdt[i]*c[i]の演算は時間軸での計算だと思うけどな 単にＦＦＴを使って掛け算を高速化しているのにすぎないわけで >>464 まず、 係数については柔軟性を持たせる為に浮動小数点というのは悪くないが データは16bit固定小数点で保持すれば十分だろう。 実用的には係数も16bit で十分。 （この場合でも積和累計レジスタには　16+16-1+17=48bit　が必要） その場合、途中係数が0が続く部分が大量に出る。 なぜなら全部が1のデータでも計算結果は2bitオーバフローしてしまうのだから。 だから0の部分をリスト形式でスキップすれば計算量は多少小さくなるかもね キャッシュについては、 Σc[i]*d[i] は　分解出来るわけだから、たとえば256サンプル毎に キャッシュに入るサイズで分割して計算すれば、問題ないだろう 478 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:31:31 ] > データは16bit固定小数点で保持すれば十分だろう。 > 実用的には係数も16bit で十分。 ゲーム用途なら実用的かも。 音楽用途だと精度が低すぎ。 例えばリバーブの消えかけ部分のS/N比が低くなるだろう。 479 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:38:18 ] >>478 リバーブの場合でも全体にスケーリングすれば十分さ。 逆にどこもかしこも係数が大きい100Kワードの係数があったとすれば 結果は簡単にオーバーフローしてしまう。 全部の係数が＋１か-1であってもオバーフローするんだからさ 480 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:41:18 ] ふーん。 固定小数点＋スケーリングって事は、 トータルでは浮動小数点演算なわけだ。 481 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:42:56 ] あ、ごめん。 データと係数は16bit固定小数でも 内部演算結果は48bitになるっつう話ね。了解。 482 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:46:55 ] 64bitマシンならともかく、現行ＣＰＵだと16+16-1+17=48bitを固定小数点で計算するには 桁上げが必要になるわけで、浮動小数点レジスタで計算させた方がいいと思うよ 483 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:48:45 ] おｋ 一体なんのための固定小数点だったんだろうね？ 484 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:52:21 ] PCのインターフェースは44.1K 16bitステレオなのだから 16bit固定小数点の選択で何の過不足も無いと思うのだが？ 485 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 20:55:01 ] もーどーでもいいや。 結論出たら教えてくれ。 486 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:05:08 ] じゃ、ここまでの勝手なまとめ １、ＦＦＴを使う場合でもレイテンシ1のフィルタは実現可能 　　　ただし計算量はそれなりに増える 　　　それでも係数器が巨大ならＦＦＴを使わない方法よりもずっと高速 ２、ＦＦＴを使わない場合でもキャッシュサイズが溢れる心配については不要 　　キャッシュに入るサイズにFFTでレイテンシ１のフィルタを作る時と同じように分割すればいいだけ 　　だったらＦＦＴ使えよと 487 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:06:57 ] DSPだと積和を１クロックで処理できるって売りを良く聞くけど Intel入ってるとかだとどうなの？ 例えば１０クロック必要なら単純に 3GのCPUでも300M個の処理しかできないよね。 ３億タップ！？って感じはするけど実際に使えるリソース考えると >>464の言うリード時間の問題がほとんどになる気がする。 >>477 何個分割して処理しようが結局メモリからキャッシュにフィルタ係数なり入力信号なりを リードしてから計算しないといけなくなるから無意味。 始めからCPUキャッシュ上に係数も信号も保持していないと駄目ぽ。 >>464 の言う1/10000sec が 1/1000sec の間違いだという仮定ならますますPCでの リアルタイム畳み込みは時間軸では厳しくなりそうですね。 あと揚げ足とるようだけど10万個の係数読むなら10万個の入力信号も 読まないといけないわけで合計20万個のデータリードになるよ＾＾； ということは 1/500sec が一度の積和に必要なメモリリード時間になるが。。。 キャッシュから外れたら無理だね。と思わせる時間だよなこれw 逆に質問、キャッシュ内データのアクセスタイムってどれくらいなんだろ。 ナノのオーダーじゃ全然遅いよね。ピコとかのオーダーなのかな 488 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:09:20 ] >>486 の結論２は明らかに間違っている。 489 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:10:01 ] って書いたら真上で 487が指摘していた うぇw 490 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 21:20:08 ] >>487 もしかして、話についていけない？ フィルタの計算は、１サンプル毎にデータがズレて t0↓　d 　e　 f 　g　 h 　i　 j 　k t1↓　c 　d 　e 　f 　g 　h　 i 　j t2↓　b 　c 　d 　e 　f 　g 　h　 i t3↓　a 　b 　c 　d 　e 　f 　g 　h 係数器は同じ係数が使われる。 　　 c0　c1　c2　c3　c4　c6 　c7 f0の時点で、 d*c0+e*c1+ ・・・・ だけでなく d*c1+e*c2+・・・・　や d*c2+e*c3+・・・・　を先に計算しておけば t1の時点では c*c0だけを t2の時点では b*c0+c*c1を計算するだけでいい というわけ で、先に計算する時に計算順をキャッシュのサイズで分割すればいいだろ？ って話をしてるわけさ 491 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 22:00:44 ] ようするに、 遅延器の後ろの部分は、先に計算出来るから 計算順を変更してしまって、 １サンプルでは同じ遅延器部分を何度も計算してしまうようにしちゃえばいいって事だな で、細かく分割して計算順を変更する手間を考えたら、 だったらＦＦＴで計算しちゃえよと 492 名前：デフォルトの名無しさん [2007/04/08(日) 22:03:03 ] スルー 493 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 22:05:51 ] >>490全然計算量減ってないあたりが笑えた 494 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 22:11:37 ] ん？　　計算量は同じだけど、t0に計算が集中してしまうね 495 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 22:18:05 ] しかもt8以降は計算量一定 一体何を言いたかったの？ 496 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 22:28:23 ] こんだけ説明されて判らんのか？　どこが判らんの？ 497 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 22:32:40 ] >>494 例ではそうなってるけど、 実際は、これを分割するわけ、キャッシュに入るサイズで分割すれば キャッシュの出入り回数はそれだけ実質へらせられる 498 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 22:46:22 ] とりあえず誰かこれプログラムにしてみてよ 話それから 499 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 23:18:17 ] 1/2分割の手順 N2=N/2-1 Σ(0..N){c[i]*d[i]} =c[0]*d[0]+c[1]*d[1] +・・・c[N]*d[N] R1=Σ(2..N2) {c[i]*d[i]} S1=Σ(N2..N) {c[i]*d[i]} R2=Σ(2..N2) {c[i]*d[i-1]} S2=Σ(N2..N) {c[i]*d[i-1]} ２サンプル毎に 偶数目では S1=Σ(N2..N) {c[i]*d[i]} と S2=Σ(N2..N) {c[i]*d[i-1]} を計算　 Σ(0..N){c[i]*d[i]} =c[0]*d[0]+c[1]*d[1] +R1+S1で求める 奇数目では R1=Σ(2..N2) {c[i]*d[i]} と　R2=Σ(2..N2) {c[i]*d[i-1]} を計算 新しいサンプリングデータがdnewとして c[0]*dnew+Σ(1..N){c[i]*d[i]} =c[0]*dnew+c[1]*d[0] +R2+S2　で求める そしてデータは２ワードシフトする 500 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 23:19:36 ] 訂正 × c[0]*dnew+Σ(1..N){c[i]*d[i]} =c[0]*dnew+c[1]*d[0] +R2+S2　で求める ○ c[0]*dnew+Σ(1..N){c[i]*d[i-1]} =c[0]*dnew+c[1]*d[0] +R2+S2　で求める 501 名前：デフォルトの名無しさん mailto:sage [2007/04/08(日) 23:51:28 ] こういう計算する時の遅延器ってみんなどう実現してるのかな DSPの場合はモジュラアドレッシングがあるからいいけど ＰＣの場合、俺がやった事があるのは １、２のべき乗のサイズのバッファ取って and 演算で計算 　　 [(wp+i) & (BufSize-1) ] 　　案外、効率が悪い ２、メモリを２倍とって wpの位置に書く時 [wp]と[wp+N] の２箇所に書いて 　読む時はそのまま [wp+i] でアクセス 　　効率はいいけど、メモリが２倍必要 　　仮想記憶用のテーブルにアクセス出来れば、メモリを２度割り付ければいいんだろけど 他にいい方法ある？ 　メモリをその都度moveするコードはありえないとして 502 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 01:03:17 ] 何この流れ。 最近は、リアルタイムの意味を取り違えている人がいるから困ったもんだ。　（あのドラマ、リアルタイムで見た　とか。お前の視覚神経はコンピューターか） 503 名前：デフォルトの名無しさん [2007/04/09(月) 01:04:27 ] スルー推奨 504 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 10:47:29 ] リアルだったら殴ってるよタイム 505 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 13:29:27 ] 流れぶったぎって初歩的な質問を・・・ 0〜1のリニアなスロープを聴感上リニアにしたいのですが、いい方法ありますか？ -96〜0などとしてデシベル換算だと、0が0にならないですよね。 あるいは良く近似するカーブを得る軽い方法などありますか？ （自分は累乗をよく使うのですが、近似というところではイマイチで・・・） 506 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 13:38:18 ] 指数カーブに適当に0を通る関数を掛け算したら？ (a^x)*x^b とか bを 1/2 つまり平方根なんて良く使うよ 507 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 14:44:14 ] 平方根掛けいいですね。 試してみましたが、かなり近似しつつ0を通るようにできますね。いいこと教わりました。 リアルタイムで毎回計算する用途だと平方根はちょっと重いですかね? 類似した方法も、いろいろ試してみたいとおもいます 508 名前：デフォルトの名無しさん mailto:sage [2007/04/09(月) 18:34:32 ] a^x と √x のどっちが重いかという話なら、同じ程度だと思うが ＰＣならテーブル作って間を直線補間するし DSPなら４〜５次くらいに級数近似するし 509 名前：デフォルトの名無しさん mailto:sage [2007/04/10(火) 01:18:11 ] パッタリ止まったなぁw で、ソースまだ？ 510 名前：デフォルトの名無しさん mailto:sage [2007/04/10(火) 02:05:59 ] クレ房きました 511 名前：デフォルトの名無しさん mailto:sage [2007/04/10(火) 02:08:10 ] オレ、勝手にやってる

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef