Voayage MPDの優先度をチューニングしてさらなる高みを目指す（１）

Googleで「Voayage MPD」と検索してみると、日々新しいページが付け加わっているのが分かります。
その内容を少しばかり拾い出してみると、

「一部のオーディオファンの間で話題になっていた Voyage MPD。連休を利用して導入を試みました。1日半、苦戦しましたが、何とか音が出せるようになりました。」

「クライアントに「Music Player Minion」や「Sonata」を使って試してみましたが予想通り、音を出す段階までたどり着けません。
ネットワークも linux もあまりにスキルのない私には全く歯が立ちません」

「再生専用として使用してきたPCにVoyage MPDをインストールした。クライアントはGnome Music Cliantを使っている。
ubuntuの様にはすんなりとインストール出来ない。何度かの試行錯誤を経てやっとNASを接続しての再生が可能となった。」

「Voyage MPDというのはローカルでちょっと話題になったLinuxの音楽専用ディストリビューション（OS)というものです。これを使って何とか再生までたどり着きました。とはいっても私はLinuxド初心者なので勿論一人ではできませんでしたので、プロのN氏に手取り足取り助けて頂きました。＞ありがとうございます。」

と言う雰囲気で、皆さんシステムの導入そのものに大変な苦労をしているようです。
ただし、それだけの苦労をしても、今までとは隔絶した音の世界をもたらしてくれることへの驚きをだれもが述べています。まさに、「趣味性」満点のシステムだと言えます。

そこで、今回はさらに「趣味性」を高めて、この「Voyage MPD」の音楽再生に関わるプロセスの優先度を徹底的に追い込んで、さらなる高みを目指してみたいと思います。ただし、私はＰＣの専門家ではありませんので、以下の記述に関しては思いこみや理解不足による誤りがあることは否定できませんので、お気づきの点がありましたら指摘いただけると有り難いです。

また、この優先度の設定に関する詳しい記述は「みみず工房」さんのサイトにありますので、そちらの方も是非とも参照してください。

ジョブとプロセス

さて、本題に入る前に、今回チャレンジしようとしている「プロセスの優先度」について簡単に説明しておきたいと思います。なぜなら、一般的なユーザーにとって「プロセスの優先度」なんて言葉は出会うことがほとんどないからです。

一般的な家電機器は普通は一つの仕事しかしません。洗濯機の中に生鮮食品を入れて保存しようとしてもそれは無理な話ですし、冷蔵庫の中に洗濯物を入れてもいけません。
ところが、ＰＣというのは実に不思議な機械で、たった一台のＰＣで、画像や動画を表示したり、音楽を再生したり、ネットにつないで情報のやりとりをしたり、文字を入力したり、データを保存したりと、実に様々な仕事をこなすことができます。
このように、ＰＣの様々な働きをユーザーの側から見たときに「ジョブ」と言います。つまり、ユーザーから見てＰＣというのは様々な「ジョブ」をこなす優れものだと言えるわけです。

この「汎用性」こそがＰＣがかくも広く社会に浸透した大きな要因の一つだと思うのですが、ＰＣオーディオ派にとってはここで一つの矛盾に突き当たります。それは、ＰＣオーディオ派にとってはＰＣは音楽再生に関わる「ジョブ」だけに徹してほしいのですが、現実のＰＣは様々なジョブがこなせる状態でスタンバイしているので、結果として音楽再生というジョブが十全に機能せずに音質が劣化するという矛盾です。

この矛盾を解決するために、多くの人がまず最初に取り組んだのがWindoesPCのチューニングでした。音楽再生に不要な機能を徹底的に絞り込んでいくことで、ＰＣオーディオの可能性を広げていきました。そして、この延長線上に、音楽再生にとってよりベターだと思える環境を再生ソフトの側で作り出す「cMP2」という提案がなされたりもしました。

次に、多くの人が目をつけたのがOSの選択でした。もちろん、WindowsというOSが音楽再生にとって不都合だというわけではないのですが、余分な「ジョブ」を削り落とす事に限界を感じるようになったのがきっかけでした。そこで、多くの人々はより「軽い」OSであり、さらにはネット上に多くの知見が蓄積されていて扱いやすい「Linux」での音楽再生にチャレンジを始めました。

そして、この「Linux」上での音楽再生という試みの中で一つの到達点を呈示したのが「Voyage MPD」でした。
既に何度も述べていますから繰り返しませんが、この「Voyage MPD」によって音楽再生という「ジョブ」に特化したＰＣが初めて実現したわけです。つまり、「Voyage MPD」の登場によって、「汎用機のＰＣで音楽を再生する」と言うスタイルが抱えこまざるを得なかった矛盾を基本的には解決することができたわけですから、これをとりあえずの「完成形」と見る人もあらわれました。

しかし、今回の話題は、ここからさらに前に進もうというものです。
それが、この項のタイトルに記した「ジョブとプロセス」に関わる問題です。

最初にもふれたように、ユーザーから見たＰＣの様々な働きのことを「ジョブ」と言いますが、これを逆にＰＣ側から見ると「プロセス」とか「タスク」と言います。Windowsの世界では「プロセス」と「タスク」はほぼ同義語で使われますが、Linuxの世界では「プロセス」という言い方が主流のようです。
また、「スレッド」という言葉も使われますが、これは「プロセス」よりも小さな単位で動作するもので「ライトウェイトプロセス」と呼ばれることもあります。

ここで問題となるのは、ユーザーの側から見た「音楽再生」という単一の「ジョブ」は、ＰＣ側から見ると決して単一の「プロセス」や「スレッド」では成り立っていないと言うことです。
このあたりが、ＰＣという機器の融通の利かないところであって、人間から見れば「音楽再生」というジョブは実に明快な単一の機能のように思えるのですが、ＰＣから見るとその「ジョブ」を実行するためには多くの異なる「プロセス」や「スレッド」を組み合わせることが必要となるのです。

たとえば、HDをNASで接続し、USB接続でDDコンバーターに送り出しているという一般的な形を想定してみると、音楽再生という単一の「ジョブ」を実現するためには、

＜音楽ファイルを取り込む＞
eth0：ネットワーク接続
cifsd：NAS接続

＜再生ソフトのMPDを動作させる＞
main thread：MPDを起動し、クライアントとの通信を行う
player thread：プレーヤーのコマンド（再生、ストップなど)を管理する
decoder thread：音楽ファイルを読み込みPCMへ変換する
output thread：PCMデータをドライバーに受け渡す
update thread：tag_cacheのアップデートを行う

＜サウンドドライバからUSB端子にデータを送り出す＞
irq/16-uhci_hcd：[16]などの数字は環境によって変わる

＜同期をとる＞
sirq-timer：タイマー関連の割り込み

などの「プロセス」や「スレッド」が上手く歩調を取って動作することが必要になるのです。

そして、「Voyage MPD」は「ジョブ」という観点から見ると「音楽再生」に特化することには成功したのですが、「プロセス」という側から見てみると、必ずしも「最適化」されていない事に改善の余地を見いだしたのが今回の話題の発端なのです。（前振りが長いーーー＾＾；・・・かな？）

プロセスの優先度

ＰＣは、ユーザーから見た「ジョブ」を実現するために、複数の「プロセス」や「スレッド」を上手く歩調を取って動作させています。

しかし、
少し考えれば理解できることだと思うのですが、それらの動作は一つのCPUで実現しているわけですから、同時に並行して動作させることはできません。
そこで、それら複数の「プロセス」や「スレッド」は順番待ちをしながら不都合が起きないように動作しています。
これがとても重要です。

もしも、あるプロセスを実行しなければ不都合が起こるにもかかわらず、別のプロセスがCPUを占拠して場所を譲らなければ最悪音切れが起こったりします。そこまでの不都合が出なくても、この順番待ちが上手くいかなければ音質に悪影響を及ぼすことは容易に想像できます。
そして、上で列挙した「プロセス」や「スレッド」は音楽再生という「ジョブ」を実現するためには全て必要なものなのですが、重要度と言うことでは全て同一ではないことも容易に察せられます。
たとえば、MPDを起動させるための「main thread」は、最初に動作すれば後はほとんど不要です。「update thread」なども、音楽再生しているときに動作することはあり得ません。
これに対して、音楽ファイルをHDから取り込んだり（cifsd）、音楽データをドライバに受け渡したり（output thread）、USB端子に送り込んだり（irq/16-uhci_hcd）するプロセスは一瞬の待ち時間もなしにスムーズに動作する必要があるだろう事は容易に察せられます。

ＰＣはこれらの「プロセス」や「スレッド」に重みづけを与えることができます。
これを「優先度」と呼んでいます。

そして、より高い「優先度」を与えられた「プロセス」や「スレッド」は、あまり順番待ちをすることなくCPUを使用することができるようになります。
ですから、より優先したいプロセスには高い優先度を与えれば、音楽再生という「ジョブ」がよりスムーズになされるのではないかと考えるわけです。

ところが、「Voyage MPD」をインストールしたままの素の状態では、これらの「プロセス」や「スレッド」は全く同じ重みで設定されています。(やや、正確さに欠ける表現ですが・・・まあ、いいでしょうーー；）
そこで、これらの「プロセス」や「スレッド」に、どのような重みづけ、優先度の設定を行えば、音楽再生という「ジョブ」をもっともストレスなくスムーズに実行できるのかを探ってみたいと思うようになるわけです。

もちろん、「Voyage MPD」はデフォルトのままでも「音切れ」のような不都合が起こるわけでもありませんし、これまでの様々な再生に関わる提案と比べてみても一線を画すほどに素晴らしい世界を描き出してくれます。ですから、これで十分と思われる方も多いと思うのですが、満足してしまえば「趣味の世界」は終わってしまいます。
一般の方にとっては、何と「些末」な事にこだわるのだと笑われそうなのですが、それが「趣味」の世界というものです。

耳を頼りに試行錯誤

さて、話しがこのあたりまで来ると、ほとんど「未開の荒れ地」と言わざるをえません。しかし、その「荒れ地」はしっかりと鍬を入れれば「豊かな耕地」に一変する可能性を秘めています。
先人の影はごくわずかですから、最後に頼りになるの己の耳を信じて試行錯誤あるのみです。

まずは、「Voyage MPD」に接続しているネットワーク端子や「DDコンバーター」が使用しているUSB端子の「irq番号」を調べます。
この音の入り口と出口に関わるプロセスは優先度を高く設定しておくべきだと考えるからです。

# cat /proc/interrupts

CPU0
0: 6205 IO-APIC-edge timer
1: 2 IO-APIC-edge i8042
9: 0 IO-APIC-fasteoi acpi
12: 4 IO-APIC-edge i8042
14: 0 IO-APIC-edge ide0
15: 0 IO-APIC-edge ide1
16: 435 IO-APIC-fasteoi uhci_hcd:usb5, i915, eth0
18: 0 IO-APIC-fasteoi uhci_hcd:usb4
19: 2042 IO-APIC-fasteoi ata_piix, uhci_hcd:usb3
23: 2 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
NMI: 0 Non-maskable interrupts
LOC: 17368 Local timer interrupts
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
PND: 0 Performance pending work
RES: 0 Rescheduling interrupts
CAL: 0 Function call interrupts
TLB: 0 TLB shootdowns
ERR: 0
MIS: 0

これは私の環境のものなので、お使いの環境によって異なってきます。

これで分かることは、ネットワーク端子（eth0）には「16」という番号が割り振られていることです。
次に「19」のところに「2042」という大きな数字が表示されています。これは「19」が頻繁に使われていることを示していますので、この事から「「DDコンバーター」が接続されているUSB端子の「irq番号」は「19」であることが分かります。

もう一度繰り返しますが、この番号は使っているＰＣによって変わってきますので、必ず「cat /proc/interrupts」で確認してください。

これに、NAS接続を受け持つプロセスの「cifsd」の優先度を高く設定したいと思います。
ただし、音楽ファイルを内蔵のHDやUSB接続のHDに収納しているときは、「eth0」や「cifsd」の優先度を上げる必要は全くありません。このあたりも、システムの構成によって変わってきます。
ただし、「Voyage MPD」は基本的には音楽再生しかできませんから、CDのリッピングやタグの編集などを行うとなると、NAS接続させるのが一般的かと思われますので、このシステム構成を前提に話を進めていきます。

やり方はそれほど難しくありません。
「/etc/rc.local」と言うファイルに、次のように追記して再起動すれば優先度の設定が変更できます。

# vi /etc/rc.local

＜以下を追記する＞

chrt -f -p 52 `pgrep irq/19-uhci_hcd`
chrt -f -p 53 `pgrep irq/16-eth0`
chrt -f -p 53 `pgrep cifsd`

優先度の設定は「52」とか「53」という数字で行います。数字が大きいほど優先度は高くなります。設定可能な数値は０~９９です。
再起動して確認してみます。

# ps -eLo pid,lwp,rtprio,priority,time,cmd | egrep “irq|cifsd”

118 118 50 -51 00:00:00 [irq/9-acpi]
945 945 50 -51 00:00:00 [irq/12-i8042]
946 946 50 -51 00:00:00 [irq/1-i8042]
1147 1147 50 -51 00:00:00 [irq/14-ide0]
1148 1148 50 -51 00:00:00 [irq/15-ide1]
1149 1149 50 -51 00:00:00 [irq/23-ehci_hcd]
1150 1150 50 -51 00:00:00 [irq/23-uhci_hcd]
1151 1151 50 -51 00:00:00 [irq/19-ata_piix]
1155 1155 52 -53 00:00:00 [irq/19-uhci_hcd]
1156 1156 50 -51 00:00:00 [irq/18-uhci_hcd]
1159 1159 52 -53 00:00:00 [irq/16-uhci_hcd]
1499 1499 50 -51 00:00:00 [irq/16-i915]
1835 1835 53 -54 00:00:00 [irq/16-eth0]
1895 1895 53 -54 00:00:00 [cifsd]
2225 2225 – 20 00:00:00 egrep irq/|cifsd

となっています。
irqの優先度はすべて「50」が割り当てられているのが分かります（「Voyage MPD」をインストールしたままの素の状態では「プロセス」や「スレッド」は全く同じ重みで設定されている、というのがやや、正確さに欠けると言ったのは、この点です）ので、「irq/16-eth0」や「irq/19-uhci_hcd」にはそれよりも高い優先度である「52」「53」を割り当てたわけなのですが、設定したとおりに反映していることが分かります。
後はこの設定で音がどのように変化するかと言うことなのですが、私の場合ではかなりの改善が確認されました。

ただし、この設定がいつの場合も「ベスト」である保証は全くありません。
これ以外にも、プロセスの同期を取るためのタイマーの優先度を上げるという考えもあります。また、「irq/16-eth0」や「cifsd」よりも、「irq/19-uhci_hcd」の優先度を上げるという考えもあります。
このあたりは、結局は自分の環境で試行錯誤してベストと思われる設定を探っていくしかありません。

ただし、音の傾向はデフォルトと比べるとかなり雰囲気が変わりますし、優先度を色々弄るとかなりはっきりとした違いが出てきますので、最終的には自分の好みも反映して決めていくことが大事かと思われます。

長くなってきたので今回の報告はここまでとします。
次回は、MPDを動作させるための一連のスレッド（main thread、player thread、decoder thread、output thread）の優先度の設定について報告します。