文章
由 巨熊 »
如果我們不使用硬體DSP運算, 完全改成軟件運算, 可以完全不使用SRC嗎?
你的說法在某些場合是沒錯的. 問題是, 你要如何處理多個取樣率來源的結果呢? 簡單一點就以時域Delay為例, 輸入的取樣率與輸出其實是相同的. 在遊戲中那些由8kHz到48kHz不等的音源都處理了, 輸出的取樣率還是不變. 不過取樣率不同之下, 你該如何把它們混合輸出呢? 當然, 你也可把DSP Code的輸出鎖定為固定取樣率. 不過, 這樣做的話, 骨子裡還是把SRC嵌入DSP Code中.
在這裡, 你也許會把問題怪責到我們混合使用不同取樣率的音源, 要是我們嚴格規管, 只容許單一取樣率的存在, SRC的需要便會很低. 不過, 問題並非單是這樣的. 某些運算本身就是SRC運算的應用. 那麼你該躲到哪裡去呢? 像Wavetable本身, 我們還是會利用Pitch Shift去填補不存在的取樣. 你當然可以針對所有會發出的聲音錄下取樣, 不過在實際的應用上, 單是把GM所有樂器的所有樣本都全數紀錄去避免以Pitch Shift填補欠缺的聲音, 並不是一件容易的事, 某程度上更是不切實際.
數位混音方面... 你要混合不同取樣率的聲音, 不使用SRC的話, 你打算用Analog Mixer嗎? 像3D音效需要混合32到128音源不等, 你要用上32到128聲道的DAC? 你敢說這樣的混音設計一定比SRC好嗎?
3D音效中的Doppler Effect, 也是利用SRC進行Pitch Shift. 要是不使用SRC, 我們要面對的就不單是數個常用取樣率, 而是任意取樣率. 再來的又回到數位混音問題: 混合32到128個任意取樣率的音源, 你又打算如何處理呢?
即使上述的功能不以硬件DSP處理, 完全改以軟件運算, 最終還是不能逃避SRC的使用. 要讓上述運算改以DSP處理, 便得讓硬件本身具備SRC才可.
我想帶出的訊息:
1. SRC有多種用途, 絕非洪水猛獸
2. 即使硬件不具備SRC, 在很多用途上我們還是不能逃避SRC
3. 某些工作(如混合多個任意取樣率的音源)即使採用一些避開SRC的工作方法, 也不見得一定有正面作用
4. Emu10K1的問題, 是它沒有本體支援44.1kHz取樣, 而不是具備SRC
5. 硬件能本體支援44.1kHz, 其實有SRC也不影響44.1kHz的播放品質
6. 就是對SRC不瞭解的人, 才會想盡法子把它排除出硬體以外