Volumioにmpd-dsd最新版を入れてみる。

作成日2014年3月25日
加筆　2014年3月26日

前回 の続きですが、長くなったのでページを分けました。

  • mpdの事

    • そもそもは、 こんなリリースを見つけてしまったのがきっかけです。

    mpd-0.18.9では「Raspberry Piのaudio driverのbugや曲間ノイズに対する処理を改良した。」とあります。

    ちなみに、volumioで採用されているmpdは、mpd-0.17.4です。
    0.17系から0.18系と系列まで変わっているので不安はありますが、Piのaudio driverのバグ対策が入っているのであれば、是非試してみたいです。
    入れ替える方法は、 ここにある方法で問題ありません。これはmpd-0.18.8へのアップデート方法ですが、mpd-0.18.9でも同じです。

    mpd-0.18.9にした際の最初の印象は....

    mpd-0.18.9ではaudio_buffer_sizeが512のままでも(mpd-0.17.4で)2048位にした音が出ます。

    どういう意味かと言うと...
    私はmpd-0.17.4では/etc/mpd.conf内のaudio_buffer_sizeを512にしています。
    これを2048にすると、音に滑らかさと厚みが増すのですが、音飛び(音切れ)の発生頻度も(感覚的にですが)上がる様に思えました。
    そのため、Raspyfiでは最終的に512にしていました。
    ただし、値を小さくすると音の先鋭度が上がるので、あくまで好みの問題とも言えます。

    と言う前提の元、mpd-0.17.4でaudio_buffer_sizeを2048位にした時の豊かな音が、mpd-0.18.9では512で出てきます。
    DSD曲間のポップノイズも消え、あとはaudio driver bug fixへの期待だけかと思っていたのですが...

    DSDを再生していたところ、次の曲へ進む瞬間に再生が停止しました。あれ?なんで次の曲に進まない??

    直接mpcコマンドを投入してみても、反応がありません。プロンプトも帰って来ません。

    ps コマンドで確認してみると...mpdプロセスがCPUを99%消費して暴走しています。

    service mpd restartコマンドでmpdの再起動すると、何事も無かったように次の曲の再生が始まりました。

    mpd的には次の曲へ処理が移った後で暴走していた様です。
    止まる前には何曲か続けて再生できていたので、曲間で必ず止まると言う訳でも無い様です。
    再生するファイルに依るのかもしれませんが、事象の発生するファイルでは再現性100%です。

    そしてこの現象が発生するのはdsdだけの様です。wavは特に問題なく再生できる様です。

    これじゃダメです。

    いやいや、私のコンパイル環境が悪いのかもしれないと、色々試してみました。

  • volumioと同じconfigureパラメータでcompileしてみてもダメ。
  • 0.18.9がダメなら0.18.8, 0.18.7, 0.18.5...とversionを落としてみても同じ現象..。

    • じゃ、volumioと同じ0.17.4ならどうか?...自前でコンパイルした0.17.4は問題無く動きます...。
    自前コンパイルが原因では無い様です。

    こりゃ0.18系はダメだけど、0.17系ならイケるのかな?
    と、既に本来の目的からズレまくってますが... 0.17系最終版の0.17.6を試そうとか思ってた時に...

    mpd dsdでgoogleさんに聞いていたら、こんなセンテンスがヒットしました。

    mpd-dsd

    なんと、mpdのdsd部分の実装を担っている方の私家版mpdの様です。

    release情報を見ると、
    02-Mar-14 Updated to MPD 0.18.9. Currently no (real) differences with upstream MPD.
    08-Mar-14 Added seek support for DSDIFF and DSF DSD decoders

    現時点ではmpd-0.18.9と(realな)違いは無い事になってますが、dsdのseekサポートが追加されている様です。

    まぁ、ここまできたら試さない理由もありません。
    最悪でもdsdがseek出来るようになれば、チャレンジとしては十分です。

    結論を先に書いてしまいます。realな違いが無いと言っていますが、明らかに違いました。

  • まだ1週間程しか使っていませんが、暴走は発生していません。
  • dsdのseekも問題なく使える様です。
  • dsdの曲間ポップノイズもなくなりました。
    •
    実にrealな違いがあります。

    ようやく、辿り着けた気がしました。


    ご参考までに、mpd-dsdのコンパイル方法を書いておきます。

    上記手順と本質的には変わらないのですが、GitHubからソースを取得する必要があります。


    # apt-get install git
    で、gitコマンドをインストールし、
    # git clone git://github.com/lintweaker/mpd-dsd-018
    とすると、
    Cloning into 'mpd-dsd-018'...
    remote: Reusing existing pack: 1185, done.
    remote: Total 1185 (delta 0), reused 0 (delta 0)
    Receiving objects: 100% (1185/1185), 1.22 MiB | 225 KiB/s, done.
    Resolving deltas: 100% (686/686), done.

    となり、カレントパスにmpd-dsd-018が作成され、全てのソースコードがクローニングされます。

    備忘録ですがproxy越えでcloneするには、
    # git config --global http.proxy 192.168.0.9:3128
    # git config --global https.proxy 192.168.0.9:3128
    の様にproxy serverとportを指定すれば良いです。

    あとは同じです。
    #sh autogen.sh
    #./configure
    #make
    #make install


    -------------------------------------------------------------------------

    飛び回ってしまって判らなくなりそうなので 上記の手順 を整理してみました。おまけ付きです。

    以下の手順はvolumioにroot権限でログインして実行することを前提に書きます。
    #に続く部分が入力するコマンドです。

    (1)(まだ実施していないなら)タイムゾーンを設定する

    # raspi-config

    メニューが表示されますので、カーソルキーで
    4 Internationalisation Options -> I2 Change Timezone -> アジア ->東京を選びます。
    finishを選べば終了です。

    別に日本を指定する必要も無いのですが、少なくとも日付は正しい年月になってないと、後のコンパイルに支障がでます。

    (2)rebootした後、dateコマンドで正しく日本になっていることを確認します。

    # date
    2014年 3月 24日 月曜日 23:43:41 JST

    何も手を加えていないpiならば、日付は1970年1月1日かもしれません。

    余談ですが、piには時計が内蔵されていません。
    但し、fake-hwclockと言う仕組みでpi内の時間が前回終了時より過去の時間に戻ることは防いでいます。
    piの中では一貫して時は未来に向けて流れている事にしているのですね。
    でも色々イジっているとそれだけじゃ困ることが多いです。

    私はsparkfunのBOB-00099と言うI2C接続のRTC(Real Time Clock)モジュールを内蔵しました。
    RaspberryPi用ではありませんが(pullup抵抗も入っていないので)使える様です。
    アキバの千石に売ってました。I2Cなのでなんとかなると買ってしまいました。
    スイッチサイエンスでも売っていますね。

    えー。話を戻します。
    また、日本語localeを作っていなければ、日本語では表示されないかもしれません。
    今回の作業では必須では無いはずですが、私は下記コマンドでja_JP.UTF-8を作成しています。

    # dpkg-reconfigure locales

    (3)日時が間違っていたら、正しい日時にしておきます。

    # date -s '2014/3/24 23:45:56'
    2014年 3月 24日 月曜日 23:45:56 JST

    (4)mpdプロセスを停止します

    # /etc/init.d/mpd stop
    [ ok ] Stopping Music Player Daemon: mpd.

    (5)必要なパッケージをインストールします。

    # apt-get update
    # apt-get install build-essential gcc automake1.9 libtool flex bison gdb git

    gitも追加することを忘れずに。
    1回実施すればokです。何回やっても、既に入っている物はskipされるので問題はありません。

    (6)mpdのソースを格納する場所を準備します。

    # cd /root
    # mkdir temp
    # cd temp

    場所は任意です。

    (7)GitHubからmpd-dsd-0.18系の最新版を取得します。

    # git clone git://github.com/lintweaker/mpd-dsd-018
    Cloning into 'mpd-dsd-018'...
    remote: Reusing existing pack: 1185, done.
    remote: Total 1185 (delta 0), reused 0 (delta 0)
    Receiving objects: 100% (1185/1185), 1.22 MiB | 225 KiB/s, done.
    Resolving deltas: 100% (686/686), done.

    カレントパスにmpd-dsd-018が作成され、全てのソースコードがクローニングされます。

    (8)コンパイルします。

    # cd mpd-dsd-018
    # sh autogen.sh
    # ./configure
    # make
    # make install

    raspyfiと同じコンパイルオプションにするなら、./configureの所を下記の様にします。

    # ./configure --disable-bzip2 --disable-iso9660 --disable-zzip --enable-id3 --disable-sqlite --enable-ffmpeg --enable-alsa --disable-wave-encoder --enable-pipe-output --enable-httpd-output --disable-recorder-output --disable-sndfile --enable-oss --enable-shout --disable-pulse --disable-ao --disable-mad --disable-inotify --disable-ipv6 --enable-curl --disable-mms --disable-wavpack --disable-lame-encoder --disable-twolame-encoder --enable-vorbis --enable-lsr --with-zeroconf=auto

    それなりに時間は掛かります。1GHzのpiでmake自体は20分程度だったと思います。

    (9)(おまけ)コンパイルを省略してチャレンジャーになりたければ

    (1)から(8)まで全てすっ飛ばして...

    これを/usr/local/binにコピーして以下のコマンドを実行する。

    # cd /usr/local/bin
    # tar zxvf mpd-dsd-0.18.9.tgz
    # ls -l mpd*
    -rwxr-xr-x 1 root staff 353112 3月 19 16:15 mpd-dsd-0.18.9

    多分、このmpdだけ入れ替えれば動くと思いますが、保証はできません。
    ダメな様でしたら教えて頂ければうれしいです。
    上記の様に正常に展開できたら、手順(10)の4行目、#cd /usr/binに進みます。

    (10)古いmpdを新しいmpdに入れ替えます。

    # cd /usr/local/bin
    # strip mpd
    # mv mpd mpd-dsd-0.18.9
    # cd /usr/bin
    # mv mpd mpd-0.17.4
    # ln -sf /usr/local/bin/mpd-dsd-0.18.9 mpd

    ちょっとオリジナルの手順とは違いますが、お好きな様に。

    (11)新しいmpdプロセスを起動します

    # /etc/init.d/mpd start
    [ ok ] Starting Music Player Daemon: mpd.

    この手順をせずにrebootしても可です。

    (12)mpdのバージョンを確認しておきます。

    # mpd -V
    Music Player Daemon 0.18.9-dsd
    :
    略
    :

    この様に0.18.9-dsdと表示されれば成功です。

    (0)元の状態に戻したければ...

    # /etc/init.d/mpd stop
    # cd /usr/bin
    # rm mpd
    # mv mpd-0.17.4 mpd
    # /etc/init.d/mpd start

    もし問題があるようだったら、この手順で元に戻せます。


    2014年3月26日加筆

    ところでAudio driverのbugはどうなったんでしょうか?

    「そう言えば音飛びが無いなぁ...治ったのか？」と思った瞬間に発生しました。

    超能力かよ。と言うタイミング。piの?

    直接の原因がソフトウェアやOSのbugなのか、何かの突発的な負荷に依存するのか、USB DACとの転送タイミングに依存するのか....

    少なくとも「滅多に発生しなくなったけど、根絶した訳でも無い。」が現状です。

    想像ですが私の言っている「音飛び」と「音切れ」は別の現象の様な気がしています。

    kernelパッケージ内のUSBコントローラのbugは、

    コントローラは正しいデータを送った事になっているが実は化けている。しかも「転送成功」になっているので訂正もしない。

    と言うことらしいです。
    このbugが「音飛び」「ドロップアウト」(と私が言っているだけですが）現象になる気がします。

    一方、「音切れ」は
  • USBメモリの読み出しが間に合わない場合
  • USB-DACへの送出が間に合わない場合
  • 他の負荷によるUSBコントローラの処理遅延
    • などの場合に発生する、「扇風機の前で声を出した」状態の様に一瞬途切れる現象の様な気がします。
    本来の意味での「扇風機の前」の現象になるのは、「音切れ」が連続した場合です。

    この連続した「音切れ」は簡単に確認できます。
    PiのUSBとLANは同じコントローラが制御しているので、単純にLANに負荷を掛ければ発生します。
    例えばDSDや192K WAVを再生中に大容量データをLAN経由でコピー(scp)すると、まさに「扇風機の前」状態になります。
    これは、LAN(eth0)のQOSを制御して帯域制限を掛けることで軽減することは出来ます。
    しかし、あくまで「軽減」です。
    例えばdmesgコマンドを投入した瞬間「一瞬」の音切れは確実に発生します。

    # tc qdisc add dev eth0 root tbf limit 10Kb buffer 5Kb/8 rate 1000Kbit

    このコマンドを投入する事で、転送量は1000Kbitに制限されます。
    当初は'500000bit'に制限していましたが、完全に音切れを防ぐ事はできないので、今はこの値にしています。

    現在の帯域制御状態は、下記のコマンドで確認できます。

    # tc -s qdisc
    qdisc tbf 8001: dev eth0 root refcnt 2 rate 1000Kbit burst 5Kb lat 41.0ms
    Sent 601406 bytes 1265 pkt (dropped 19, overlimits 926 requeues 0)
    backlog 0b 0p requeues 0

    上記の例では、帯域制御によりdropされたパケットも結構発生していることが判ります。
    (udpなど)シーケンスを保証できない通信を行う場合、問題となる事も考えられます。
    私の場合はLANに流すのはsshとdroidMPDの通信程度なので、特に問題は無いです。

    帯域制御を止めるには、下記のコマンドを投入します。
    制限値を変更する場合も、一旦、下記コマンドで削除する必要があります。

    # tc qdisc del dev eth0 root


    DSD64と192K WAVまでの範囲であれば、CPUのOver Clockなどにより通常時(外乱の無い状態)での「音切れ」は根絶できた様です。
    要するに、piを放置し、下手に触らずに音だけ聞くのであれば、「音切れ」しないと言う事です。

    やはり最大の問題は「音飛び」の原因と思われるUSBコントローラのbugだと思います。
    現時点ではbug対策は「beta test」の段階ですが、この対策に期待したいと思います。


    戻る

    inserted by FC2 system