「mpd.conf」を弄る~アップサンプリング(1)

mpdでbit数を拡張することはデジタル領域でイコライジングをしてルームチューニングしたい人にとっては一定の効果はあると判断しています。
しかし、アップサンプリングに関しては「懐疑的」と言うよりははっきりと「否定的」でした。理由は簡単で、「format “88200:24:2″」と変更してみても、音質的にはどう考えてもNGだったからです。理屈から考えて悪かろうはずはないのですが、この世界は理屈よりも現実ですから、音が悪ければどうしようもありません。

そして、アップサンプリングという動作はCPUに大きな負荷を与えるのでそれが音質に悪影響を与え、それがアップサンプリングのメリットよりも大きいんだろう・・・と、勝手に解釈していました。

ですから、きわめて非力な「ALIX」から「CuBox」、「CuBox-i4Pro」というようにCPUが強化されるたびにアップサンプリングに挑戦するのですが、いつもいつも結果はNGでした。
ちなみに、DAC（エソテリックのD-07X）側でアップサンプリングさせても結果はおおむね思わしくないので、結局は44.1kHzの音源は44．1kHzで再生するのが男前だと判断してきました。

しかし、最近になって、きわめて重要なことを見落としていたことに気づきました。
まずは、そのお馬鹿きわまる見落としから報告します。

サンプリング周波数変換のアルゴリズム

では、何を見落としていたのかというと、アップサンプリングという動作はアルゴリズムが選べるという事実でした。
全くもってうっかりした話で、長い間サンプリング周波数の変換はMPD本体が行っていると思っていたのですが、実は「libsamplerate」というライブラリを組み込むことで実装していたのです。

このことに気がついたのは、デジファイさんの「v0.05のmpd-0.19gitについて」のページを拝見したときでした。

その中に以下の記述がありました。

＜– 引用開始 –＞
mpd.confのsamplerate_converterに以下の値が指定できます。
“soxr very high”
“soxr”
“soxr medium”
“soxr low”

libsamplerateよりは高速で品質がいいようです。
まだ、深くテストをしていませんが、2倍程度のアップサンプリングは”soxr” で実用になるようです。
＜– 引用終了 –＞

最初は「???」という感じだったのですが、Google先生に聞いてみて初めて、MPDは「libsamplerate」や「SOX」というライブラリを組み込むことでサンプリング周波数の変換を実現していることを知りました。そして、「libsamplerate」や「SOX」はユーザーの環境と必要性にあわせていくつかのアルゴリズムが存在していることもこの時初めて知りました。

そう思って、あらためて「man mpd.coh」のページを見てみると、確かに以下のように記述されています。
やはり、面倒でも一度はじっくりとマニュアルには目を通さないといけませんね。（＾＾；

＜– 引用開始 –＞
samplerate_converter
This specifies the libsamplerate converter to use. The supplied value should either be an integer or a prefix of the name of a converter. The default is “Fastest Sinc Interpolator”.
At the time of this writing, the following converters are available:

Best Sinc Interpolator (0)
Band limited sinc interpolation, best quality, 97dB SNR, 96% BW.

Medium Sinc Interpolator (1)
Band limited sinc interpolation, medium quality, 97dB SNR, 90% BW.

Fastest Sinc Interpolator (2)
Band limited sinc interpolation, fastest, 97dB SNR, 80% BW.

ZOH Interpolator (3)
Zero order hold interpolator, very fast, very poor quality with audible distortions.

Linear Interpolator (4)
Linear interpolator, very fast, poor quality.

internal
Poor quality, no floating point operations. This is the default (and only choice) if MPD was compiled without libsamplerate.
＜– 引用終了 –＞

ポイントは太字の部分ですね。

The default is “Fastest Sinc Interpolator”.
日本語に直せば、「デフォルトは”Fastest Sinc Interpolator”です。」ね。
実際、古いVoyage MPDのmpd.confをのぞいてみれば

#samplerate_converter “Fastest Sinc Interpolator”

という感じでコメントアウトされています。
しかし、もっと気になるのは最後の部分です。
ザックリと日本語に直せば、

「低品質で浮動小数点演算もしません。libsamplerateに関する特別な設定をしないでコンパイルしていればこの設定がデフォルトとなります。（そして、これが唯一の選択肢です。）」

えーっ！低品質！！浮動小数点演算もしないのがデフォルト！！！おまけに、これしか選択できない！！！！・・・って感じですね。
マニュアルページの記述が正しければソースコードからコンパイルしてMPDを組み込んだときはデフォルトでは最低品質の「internal」が選ばれている可能性があります。確かに、昔はMPDの新しいヴァージョンを求めてgitでソースコードを落としてきて自前でコンパイルしていました。そのときに「libsamplerate」なんかに配慮した覚えは全くありません。

と言うことは、かなりの確率でこの最低品質のアルゴリズムによるアップサンプリングを試してきた可能性があるのです。さらに言えば、よくても中間レベルの品質しかない「Fastest Sinc Interpolator」だったわけです。
これでは、どれほどCPUの能力が向上しても上手くいくはずがありません。つまりは、問題の本質を全くもって見誤っていたのです。

どのアルゴリズムを選ぶのか？

これは言うまでもないことです。当然のことながら、最高品質の「Best Sinc Interpolator」を選ぶべきです。
幸いなことに、lightmpdには「libsamplerate」が適切に組み込まれていますから、自由に選択することが可能です。

しかしながら、事はそれほど簡単ではありません。
事がそれほどに簡単なら、Voyage MPDの作者も最初からデフォルトで最高品質の「Best Sinc Interpolator」を設定しているはずです。分かっていながら、あえてデフォルトに最低品質の「internal」を選択したかと言えば、おそらくは、Voyage MPDの基本的なポリシーから考えれて低スペックのPCに組み込まれることを想定したからでしょう。

具体的に言えば、「Voyage MPD Starter Kit」に採用された一枚基盤の「ALIX.3D2」の場合は「CPU: 500 MHz AMD Geode LX800」「DRAM: 256 MB DDR DRAM 」でした。このスペックで「Best Sinc Interpolator」を選べばCPUの能力は追いつかずに音切れが起きてしまいます。

そう言えば、一昔前の話ですが、MPDに接続すると問題なく認識するのに長く聞いていると音切れが発生して困るというUSB-DACがありました。なかなか理由が分からずに困っていたのですが、ついにある人が、MPDに対して強制的にアップサンプリングさせるような仕様になっていることを発見して謎が解けたことがあります。
何ともお馬鹿な仕様であきれたものです。
しかし、そのおかげで、アップサンプリングというお仕事を無難にこなすにはかなりのCPUのパワーがいることを再認識させてくれましたし、非力な「ALIX.3D2」では、デフォルトの設定であっても苦しい事も教えてくれました。

そして、この初期の時代の経験が「MPDでアップサンプリングさせても効果はない」という認識を生み、定着させたのだと思います。
なにしろ、理屈を考える人なら、CD規格の最大の弱点である「折り返し歪」をうっちゃるにはアップサンプリングが最適な方法である事は容易に推測できますから、まずはやってみる人が多かったはずです。そして、やってみて「駄目だ」という現実を確認したので「MPDでアップサンプリングさせても効果はない」という認識が定着したのです。
それは時代の制約から言って仕方のないことでした。

しかし、「ALIX.3D2」を使っていた時代は遠い過去となり、今や「CPU： AMD G series T40E, 1 GHz dual Bobcat core with 64 bit support メモリ：4 GB DDR3-1066 DRAM」という「APU.1D4」の時代になりつつあります。そして、この基盤の上で起動する64bit版のlightmpdも用意されるようになると最高品質の「Best Sinc Interpolator」を動作させることは不可能ではなくなってきました。

mpd.confの変更点は以下の2つです。

audio_output {
type “alsa”
name “lightmpd_APU1C”
device “hw:0,0” # optional
priority “FIFO:99” # optional
mixer_type “disabled”
format “88200:24:2” # optional
dsd_usb “yes”
# use_mmap “yes”
buffer_time “150000”
period_time “37500”
}

ポイントは「”44100:24:2″」から「”88200:24:2″」へと変更させることです。
詳しくは項を変えて考えてみたいと思うのですが、「44.1kHz：88.2kHz：176.4kHz」と言うラインと「48kHz：96kHz：192kHz」というラインは全く別の種類の音源だと考えた方がいいと思います。そして、CPUへの負荷と「折り返し歪」の改善というアップサンプリングの目的を考えれば2倍にするのが最適値だと思います。（それに、DEQ2496も96kHzまでしか受け付けないので88.2khzへのアップサンプリングが最適値です）

そして、サンプリングのアルゴリズムを最高品質に変更します。

samplerate_converter “Best Sinc Interpolato”

この状態で、実際に音楽を再生してシステムの状況をhtopコマンドで監視します。

1 [##########################################################*** 55.5%] Tasks: 10, 4 thr; 1 running
2 [** 1.4%] Load average: 0.58 0.58 0.52
Mem[|||#*********** 88/3919MB] Uptime: 00:48:03
Swp[ 0/0MB]

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
215 root 20 0 324M 42420 19416 S 53.9 1.1 17:57.65 /usr/bin/mpd
219 root RT 0 324M 42420 19416 S 53.4 1.1 17:48.19 /usr/bin/mpd
237 root 20 0 11460 1644 1048 R 0.0 0.0 0:03.37 htop
218 root 20 0 324M 42420 19416 S 0.0 1.1 0:02.25 /usr/bin/mpd
217 root -54 0 324M 42420 19416 S 0.0 1.1 0:01.21 /usr/bin/mpd
208 root 20 0 13040 828 676 S 0.0 0.0 0:00.12 /usr/sbin/telnetd
1 root 20 0 10936 856 728 S 0.0 0.0 0:03.02 init
120 root 20 0 10936 856 736 S 0.0 0.0 0:00.01 /sbin/syslogd -n
121 root 20 0 10936 864 728 S 0.0 0.0 0:00.02 /sbin/klogd -n
168 root 20 0 12564 744 552 S 0.0 0.0 0:00.00 rpcbind
170 root 20 0 12788 1224 824 S 0.0 0.0 0:00.00 rpc.statd -L
216 root 20 0 324M 42420 19416 S 0.0 1.1 0:00.00 /usr/bin/mpd
227 root 20 0 10940 824 700 S 0.0 0.0 0:00.00 /sbin/getty -L ttyS0 115200 vt100
228 root 20 0 13040 1016 844 S 0.0 0.0 0:00.01 -sh

1時間程度聞き続けましたが音切れなどの問題は全く発生しません。
[cpuaffinity]で「type=2」を選択していますからアップサンプリングの仕事は全てCPU0に括りつけられていますので、CPU0の負荷は50％程度で推移します。それでも、音切れを起こすような不始末はしでかしません。
また、このアップサンプリングをになうスレッドに高い優先度を割り振っていることと、CPUのお仕事をも上手く割り振っていることもプラスに作用しているのかどうかは分かりませんが、音質的には今までのアップサンプリングした音とは別世界です。

今までは高域に変に化粧を施したような雰囲気があり、なによりもCD規格の素の音がもっていた力強さが完全に台無しになってしまっていました。ところが、上記の設定でアップサンプリングした音は力強さを全く失いませんし、CD規格の音の魅力だったザラッとした生成の風合いがある種の繊細さに変化しているように感じられます。
もちろん、これが果たしてメインシステムの音として定着させていいのかどうかはもう少し聞き込んでみる必要はあります。しかし、それでも今までのように「一聴して即駄目！」みたいなレベルでないことは事実です。

それから、mpd-0.19gitからはsoxにも対応していますので、こちらの音も確認してみる必要があります。
上と同じ条件ならば、こちらもまた最高品質の「soxr very high」に設定しても何の問題もありません。

htopコマンドで見てみると、デジファイさんが紹介しているように「libsamplerate」よりは高速に処理が可能なようで負荷は10分の1程度です。ホンマかいな？・・・という感じです。

1 [####** 3.8%] Tasks: 10, 4 thr; 1 running
2 [#** 1.4%] Load average: 0.02 0.03 0.02
Mem[|||#** 87/3919MB] Uptime: 00:06:29
Swp[ 0/0MB]
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
215 root 20 0 324M 41960 19416 S 3.3 1.0 0:05.96 /usr/bin/mpd
219 root RT 0 324M 41960 19416 S 2.4 1.0 0:04.57 /usr/bin/mpd
232 root 20 0 11460 1648 1048 R 0.5 0.0 0:00.61 htop
218 root 20 0 324M 41960 19416 S 0.5 1.0 0:00.30 /usr/bin/mpd
217 root -54 0 324M 41960 19416 S 0.0 1.0 0:00.13 /usr/bin/mpd
1 root 20 0 10936 860 728 S 0.0 0.0 0:03.01 init
119 root 20 0 10936 856 736 S 0.0 0.0 0:00.01 /sbin/syslogd -n
121 root 20 0 10936 860 728 S 0.0 0.0 0:00.01 /sbin/klogd -n
168 root 20 0 12564 748 552 S 0.0 0.0 0:00.00 rpcbind
170 root 20 0 12788 1224 824 S 0.0 0.0 0:00.00 rpc.statd -L
208 root 20 0 13040 828 676 S 0.0 0.0 0:00.00 /usr/sbin/telnetd
216 root 20 0 324M 41960 19416 S 0.0 1.0 0:00.00 /usr/bin/mpd
227 root 20 0 10940 828 700 S 0.0 0.0 0:00.00 /sbin/getty -L ttyS0 115200 vt100
228 root 20 0 13040 992 832 S 0.0 0.0 0:00.00 -sh

音質的にはlibsamplerateよりはソリッドな感じがするので好みは分かれそうです。
ただ、雰囲気的にはこちらの方が「正しい音」のような気もします。
このあたりもじっくりと聞き比べてみる必要があるようです。

どちらにしても、ボードの高スペック化でアップサンプリングも実用化の範疇に入ってきたような気がします。・・・次回に続く。