うっかりしていたのですが、「voyage-mpd-0.9.2」の更新記録を確認すると「MPD 0.18.4 with Yan’s real-time patch」と書かれています。
しばらく、「Voyage MPD」とはご無沙汰をしていたので、まさかyanさんのパッチが公式に取り入れられているとは思いませんでした。
なお、「yanさんのパッチって何？」と言う人は「Voayage MPDの優先度をチューニングしてさらなる高みを目指す（２）」あたりをご覧ください。ちなみに、「lightMPD」でもこのパッチは当てられていて、さらに設定ファイル（mpd.conf）にもデフォルトで必要な記述が追加されています。
yanさんのパッチの優秀さは今さら言うまでもないことですから、本家サイトでもそれを追認したと言うことでしょう。
しかし、それならばコメントアウトしたような形でもいいので「/etc/mpd.conf」の中に優先度設定の記述を入れておいてほしいのですが、そのあたりは各自の判断でチョイスしろと言うことなのでしょう。
MPD本体にはすでにyanさんのパッチが当てられているので、必要なのは設定ファイルに優先度の記述を追記するだけです。
必要な記述は二つです。
＜ごめんなさい m(_ _)M＞
このサイト全体に言えることなのですが、なぜか「”」や「’」が全角に化けてしまうことがあります。なぜだかよく分からないのですが、現状では手直しができていませんので、そのままコピーして貼り付けるとエラーになってしまいます。
面倒ですが、適当なテキストエディタで「全角→半角」の変換をしてから貼り付けてください。
＜ごめんなさ 終わり(^^;＞
＜一つめの追記＞
realtime_option {
memlock “yes”
stack_reserve “2048”
heap_reserve “10240”
main_priority “OTHER:0”
player_priority “FIFO:53”
decoder_priority “FIFO:51”
update_priority “OTHER:0”
}
この部分はデフォルトでは全く記述がないので、設定ファイルの頭の部分に追記します。
＜二つめの追記＞
audio_output {
type “alsa”
name “hiFace Evo”
device “hw:0,0”
format “44100:24:2” #optional
priority “FIFO:52” #追記する
# mixer_device “default” optional
# mixer_control “PCM” optional
# mixer_index “0” optional
dsd_usb “yes”
}
MPDは「main thread」「player thread」「decoder thread」「update thread」「output thread」という5つのスレッドで音楽再生という一つのジョブを実行しています。このうち音楽再生に直接関わるのが「player thread」と「output thread」なので、このスレッドの優先度を上げます。
さらに、私の場合はデジタルイコライザを使っているので、イコライジングに伴うビット落ちの影響を小さくするためにMPDで24ビットにアップコンバートしています。よって、「decoder thread」の優先度も上げておきます。そんな必要がないという人はこの部分は「OTHER:0」でいいかと思います。
①上記の編集を行い保存する
# vi /etc/mpd.conf
②MPDを再起動する。
# /etc/init.d/mpd restart
[ ok ] Stopping Music Player Daemon: mpd.
[ ok ] Starting Music Player Daemon: mpd.
③設定が反映しているかどうか確認する。
# ps -eLo pid,lwp,rtprio,priority,time,cmd | egrep “mpd”
3499 3499 – 20 00:00:00 /usr/bin/mpd /etc/mpd.conf
3499 3500 – 20 00:00:00 /usr/bin/mpd /etc/mpd.conf
3499 3502 53 -54 00:00:00 /usr/bin/mpd /etc/mpd.conf
3499 3503 51 -52 00:00:00 /usr/bin/mpd /etc/mpd.conf
3499 3505 52 -53 00:00:00 /usr/bin/mpd /etc/mpd.conf
無事に優先度があがっています。
音質改善効果ですが、これも劇的に変わるわけではないのですが、それでも微妙な向上は認められると思います。おそらく、このあたりのレベルになると何か一つの対策で劇的に風景が変わることはないようです。しかし、微妙ではあっても着実に一つずつ対策を積み上げていくことで結果としてワンランクくらいは上の世界へいけそうな気がします。
チューニングはまだまだ続きます。
非常に基本的な事で質問が有ります。カーネルがRTオプションを組み込んでいない場合、yanさんのパッチは効果が有りますでしょうか。又、どうすればRTカーネルであるかどうかが見分けられるでしょうか。
ｋｉｄさん
まず
＞カーネルがRTオプションを組み込んでいない
というのはどういうことでしょうか。
私ら一般人もこのサイトとコメントをいつも見て参考にしていますから、話をできるだけわかりやすくお願いします。
kid さん
redr390 です。RealTime Kernel については詳しくないんですが、Voyage MPD 0.92 の素のカーネルは、CONFIG PREEMPT RT Patch が当たっていないと思います。しかしながら、config を見ればわかりますが、Multi-core scheduler support の Voluntary Kernel Preemption が選択されています。つまり、擬似的にlow latency(低遅延)カーネルになってるみたいです。ですから、yan さんのパッチはある程度有効ではないかと思います。あまり自信ありませんが…
>old boy さん。
私も一般人なのですが、Cuboxを所持している関係で、Voyageの本家(?Hongkong)のVoyageMuboxのページを見ています。そこで目にした記事が「[CuBox] Real-time Kernel and Tuning」と題したページです。
http://mubox.voyage.hk/realtime_kernel
ここには、「まずReal-time Kernelをインストールする」「次にreal-time support付きのMPDをインストールする」「そしてmpd.confに追加記入する」と書いて有ります。
で、発生した疑問が「eal-timeカーネルで動いているなら、confの無記入は変ではないか」と言うことです。
で、uname -a とすると Linux voyage 3.10.11-voyage #1 SMP Mon Sep 16 10:53:01 HKT 2013 i686 GNU/Linux と出ます。
で、kernel.orgへ行くと、3.10.11に対するrtパッチが見当たりません。となると、このカーネルはRTパッチは適用されていない可能性が高いと言うわけです。
ところが一般人の悲しい所で、RTパッチが適用されていなくて優先順位の設定が効果が有るのかどうかがわかりません。これが今回の質問の動機です。
カーネルとは、Linux(Voyageもその一つ)の基幹部分の事で、real-time(実時間と翻訳)処理が出来るように(正確にはみかけだけの話ですが)修正を加えた(パッチを当てた)ものをRTカーネルと呼ぶそうです。
表現を変えれば「RTオプションを組み込んでいる」となります。
kidさん
詳しい説明ありがとうございます。私は一般人とも云えない初心者ですが、何となく雰囲気が分かりました。
yungさんの記事に従って、ＶｏｒｔｅｘでＬｉｎｕｘに少しなじんだ後、Ｃｕｂｏｘｉ４－ＭｕｂｏｘからＡＰＵ１Ｃ－Voyage ＭＰＤへと進み、それぞれ音が出たと喜んでいるだけで、こういう話にはほとんど関係ないのですが、そんな世界もあるのかと思って読んでいます。
RTカーネルとはリアルタイムオペレーティングシステム (RTOS; Real-time operating system) のことです。
リアルタイムカーネルとは、一言で言えば、「OSの主要な機能である資源管理において、時間資源の優先度に基づく配分と実行時間の予測可能性を提供することに特化している、ないし、そういった機能に力を入れているシステム」と言うことになる・・・そうです。（＾＾；・・・私もよく分らん！！
ただ、私たちにとって重要なメリットは、このシステムが「高優先度のタスクが確実に実行されることを保証するスケジューリング規則」をもっていることです。
もっと具体的に言いますと、通常のOSシステムでは音楽再生に関わるタスクに高い優先度を与えても、その優先度が必ずしも保証されるとは限らないけれど、リアルタイムカーネルだとそのことを保証しますよ・・・と言うことです。
たとえば「MPD」で音楽を再生しようと思えば、一般的には「main thread」「player thread」「decoder thread」「update thread」「output thread」という5つのスレッドが必要になります。このうち、yanさんのパッチを当てて、「player thread」と「output thread」の優先度を上げます。なぜならば、音楽再生に重要なそれらのスレッドが優先的に実行されれば音質面でのメリットも大きいからです。
ただし、通常のOSだと、その高い優先度は必ずしも保証されませんよ、もしもそれを必ず保証してほしければリアルタイムカーネルに置き換えなさいよ！というわけです。
もしかしたら間違っているかもしれませんが、とりあえず私個人は大雑把にそのように理解しています。
ちなみに、Ubuntu Studioのサイトではリアルタイム性能とカーネルについて次のように解説しています。
「Ubuntu Studioは製作環境とパフォーマンス環境の充実のために、リアルタイムカーネルを標準としてきました。リアルタイムカーネルとは、 Linuxの標準カーネルにパッチ「CONFIG_PREEMPT_RT」を適用して設定を変更し、より強力なリアルタイム性能を持たせたものです。
リアルタイム性能とは、アプリケーションからの処理を、決められた期限までに終了する能力のことです。ある程度早い終了期限（デッドライン）のリアルタイム性能を持たせたカーネル（リアルタイムカーネル）を使うことで、特定のアプリケーションが行う仕事の処理を期待の時間までに終え、遅延（レイテンシ）を短縮することができます。」
これでも、いまいち分かったような・・・、分からないような説明ですね。
ただし、このカーネルのリアルタイム化を目指す試みの成果は最新の通常のカーネルにも取り込まれるようになってきましたので、適切にチューニングすれば妥当なリアルタイム性能を得ることができるようになってきました。
たとえば、長くリアルタイムカーネルにこだわっていた「Ubuntu Studio」なんかも、最近はリアルタイムカーネルから標準カーネルへ移行したようです。
特殊なカーネルを使えば当然のことながらメインテナンスの労は増えます。その労とメリットを天秤にかければリアルタームカーネルにこだわる必要はないという判断だったのでしょう。
ですから、
>非常に基本的な事で質問が有ります。カーネルがRTオプションを組み込んでいない場合、yanさんのパッチは効果が有りますでしょうか。
と言う問いに対しては、効果があります・・・と言い切って大丈夫かと思います。
と言うか、間違いのない効果が確認できたから「Voyage MPD」の作者もデフォルトでパッチを当てているのだと思います。
なお、上記のリアルタイムカーネルに関わる記述には間違いを含んでいる可能性が高いので（＾＾；、誰か補足してくれるとありがたいです。