Mizukama Blog

「MPDは殆どリソースを消費しない」と説明されていることがあるが、設定によっては結構な負荷がかかることもある。その辺の勘所を書きたいと思う。

　MPDに大きな負荷がかかる場合と言うのは、主にサンプリングレートの変換を設定した場合であろう。いわゆるアップサンプリングである。

CPU: Phenom x4 945 (3.0GHz 4 core)
OS: Ubuntu 12.04 LTS 64bit
MPD: 0.16.5

の環境で試したところ、

audio_outputの項目で
format "1764000:32:2"

なおかつ
samplerate_converter "Best Sinc Interpolator" (最高設定)

を指定し、CDからリッピングしたApple Losslessのファイルを再生したとき、MPDのCPU使用率はTOP読みで50%程度（1コアの50%ということ。以下同様）を前後する。

format "1764000:32:2"

のまま、samplerate_converterの項目をコメントアウトしてやる（デフォルト設定になる）と、CPU負荷は15%程度になる。

　なお、
samplerate_converter "Best Sinc Interpolator" (最高設定)

のままで、

format "882000:24:2"

に設定してもCPU使用率は50%前後になるので、samplerate_converterを最高設定にしてアップサンプリングする限り、Phenom x4 945で1コアを50%程度使う程度の負荷はかかるということである。

　だから、MPDでアップサンプリングを使い、最高設定にしたければ、Raspberry Piなどの低スペックボードでは無理である。AtomやAMDのEシリーズ等の低電圧版x86でも厳しい可能性がある。

　次に、MPDをRaspberry Piで使うときの勘所を書きたいと思う。環境は以下の通り。

CPU: ARM1176JZF-S (700MHz)
OS: Raspbian 2014-01-07-wheezy
MPD: 0.16.7
DAC: UCA222

　アップサンプリングを行わない場合、MPDで再生中の負荷は平均すると大体10%前後である。が、これが80%程度に達することがある。MPDクライアントからライブラリの更新をかけたときのことである。Raspberry Piのような非力なマシンで膨大な音楽ライブラリを有している場合は、MPDがクライントにライブラリの情報を伝えるだけで、CPU使用率が跳ね上がるのだ。sambaなどで他のサーバーに置いてある音楽ファイルにアクセスしている場合には、ライブラリの更新時に当然のごとくsmbfs等の負荷も高まり、場合によっては100%近くに達することもある。また、新しい曲を再生するよう操作したときも、MPDのCPU使用率は上昇する。これは、MPDが再生する前に曲のデコードを行い、メモリに入れる作業をするためと思われる。大まかに言うと、平均10%のところ、再生開始直後は50%ぐらいまで上昇する。

　さて、ここで問題となるのはCPU使用率が跳ね上がった時に、機器の組み合わせによってはノイズが発生するということである。全体のCPU負荷が100%に張り付いていなくても、ノイズの発生は明らかにCPUの負荷が増大した時に頻度を増すのである。この原因について私はよく理解していないが、CPUの負荷が上昇すると、USB通信の質が低下するということではないかと思う（つまり、デコード自体が追いついていないという訳では無いだろうという考え）。そう考えると、mpd.confの中で、”audio_buffer_size”と”buffer_before_play”の設定と音質に関する通説にも少し解が見えてくる気がする。

（参考）
Voyage MPDの使いこなし | PCオーディオ実験室

　他のサイトでも多くが共通して書いているのは、”buffer_before_play”は100%が良い、”audio_buffer_size”の値は大きすぎても小さすぎてもいけない、の2点である。普通に考えると、リソースに余裕がある限り、なるべくバッファーサイズは大きくするのが良いように思えるのだが、これは前述の点を考慮すると反論が可能である。つまり、バッファーサイズを大きくしすぎると、MPDは再生を開始後（プレイリストで次の曲が分かっているような場合ではなく、新規に再生を指定した場合を想定している）に大量のデコード作業をこなさなければならず、CPU使用率の高い状態が続き、ノイズが発生したり音質の低下が生じる、ということである。また、”buffer_before_play”は、バッファーに入れてある分が指定割合以下になるとデコードを行うという指定であるため、この値が低いと、CPU負荷の推移に山ができることが予想される（つまり、”buffer_before_play”が100%の場合は、常にデコードをするが、”buffer_before_play”が10%の場合はバッファー量が”audio_buffer_size”で指定した値の10%以下になると100%分になるまでデコードをする、ということ）。よって、再生中にCPUの負荷が高まるタイミングが生じ、そのときにノイズの発生や音質の低下が生じると考えられる。理想としては、デコード作業を完了させてメモリに格納してから再生を開始するのが良いようにも思えるが、それだと操作と再生開始にタイムラグが生じることになるだろう。

　もし本当に「CPUの負荷が上昇すると、USB通信の質が低下する」という現象が生じているなら、いわゆる”オーディオ用USBホスト機器”というのも意味があるように思えるし、Raspberry Pi関連のプロジェクトで行われている、USBを介さないi2s DACというのも有効そうだと思われる。また、Raspberry Piの場合は割と細かくオーバークロックやダウンクロックの設定が可能なので、それがどう影響するかも興味がある。ただ、Raspberry Piをわざわざ使うよりは、もう少しましなUSBチップを載せているマザーボードを使うとか、PCIやPCIe接続のちょっといいオーディオボードを取り付けて出力させる、とかの方が確実そうな気がする。