ラズパイ２に搭載しているARMv7のNEONとは？ 最適化する方法は意外と簡単
RaspberryPi （1）は、いわゆるARM11というCPUでした。 RaspberryPi 2ではCortex-A7というCPUに変わっています。
少しややこしいのが、CPUの名称と、アーキテクチャナンバー。 詳しくはこちらをご覧いただくとして、ここでは概略と、新命令NEONを有効にする方法だけを取上げたいと思います。
ARMには、CPUの名称とは別にアーキテクチャナンバーがあり、命令はアーキテクチャナンバーによって変わってきます。 つまりARM7とARMv7は全く別物です。
ARM7はあのポケットステーションにも使われていたように、かなり昔からある低消費電力なCPUです。
対してARMv7（アーキテクチャ）は、最近のCortex-Aシリーズに採用されている命令セットです。 なにやら沢山命令があります。 いわゆるコプロセッサ、ｘ86でいえば、80287のようなものがVFP（浮動小数点演算器）にあたります。 NEONはSIMD命令なのでMMXとかSSEにあたるモノだと思います。
ラズパイ２に追加になった命令（VFPv3とNEON）を有効につかってみようというのが今回の趣旨です。 オーディオの演算には掛算がとても多く使われるので、コプロセッサを使うと処理が劇的に速くなるんじゃないかと思ったからです。
つい数年前（2007年くらい？）まではCコンパイラは自動でコプロセッサの命令を吐いてはくれず、手でアセンブラをかかないといけませんでした。 ところが、ｇｃｃのあるバージョンからVFPやNEONの命令を自動で作ってくれるようになっています。
では、どうやってVFP/NEONを使うようにするのか？ 調べてみました。
コンパイルオプションに下記を付け足せばOKらしい。
-mfpu=neon -mfloat-abi=softfp -march=armv7-a
なんだ、簡単じゃん。 と試してみたものの、コンパイルに約２時間、最後、ライブラリなどリンカーがまとめる時に
/usr/bin/ld: error: xxxx uses VFP register arguments, xxxx.o does not
というエラーが沢山出てしまい、コンパイルが完了しません。
コンパイルに２時間もかかるので、あれこれ試したくても１日にできる作業はほんの数回で、気がつけば３日もトライしてました。
さてさて、何が原因だったのかといいますと、「-mfloat-abi=softfp」です。
soft 浮動小数点演算をソフトウェアで肩代わりする（互換性重視）
softfp 浮動小数点演算をハードウェアで行なうがsoftと互換性を持たせる
hard 浮動小数点演算をハードウェアで行なう
勝手に、標準はsoftだろうと決め付けていたのがいけなかったようで、RaspberryPiは「hard」なんだそうです。
リンカーエラーだったので、リンカー設定を調査して、あれこれ試すことで無駄に時間を潰してしまいました。
気を取り直して、
-mfpu=neon -mfloat-abi=hard -march=armv7-a
と、コンパイラにオプション指定することで、コンパイルは無事に通りました。
結果は、下記のようにDSD2PCMでDSD再生中のCPU負荷が約95％から91-90%へと、若干ですが余裕ができました。 この差が大きいのか小さいのか。。。 微妙なところですね。
このコンパイル済みMPDの導入方法は、
SSHでログイン
root
volumio
cd /usr/bin
wget nw-electric.way-nifty.com/blog/files/mpd_0.19.7neon
cp -f mpd mpd.bak
cp -f mpd_0.19.7neon mpd
chmod +x mpd
reboot
です。 昨夜から一晩DSDを再生し続けても止まらず再生できていますが、動作を保証するものではありません。
MPDでは、劇的な効果は得られなかったのですが、他のソフトでは効果が出るものもあると思うので試してみてはいかがでしょうか。
ちなみに、上記の mpd_0.19.7neon と書いてある部分を
mpd_0.19.7hf
とすると、従来のB、B+でも実行できるハードウェアフローティングのバイナリになります。 （２種類のバイナリを置いておきました）
にほんブログ村
ブログランキングに参加中です。 めざせ１位！
もしよろしければ「ぽちっと」お願いします。
« Raspberry Pi 2で MPD再生する意義があるかも DSD再生の謎に迫る | トップページ | 一度RaspberryPiで使ったSDカードを簡単にFAT32へ戻す方法 »
「Raspberry Pi」カテゴリの記事
- 1.3インチの超小型カラーLCDに動画を表示してみました。(2019.08.14)
- RaspberryPi 4 Model B発表されました(2019.06.24)
- コミックマーケット96 ラズパイ本に寄稿しました(2019.06.19)
- 現代に甦るLUXKITはソフトもハードもイジりたい放題！？(2019.05.06)
- symphonic-mpd v0.8 以降はR&D Club限定に(2019.04.14)
コメント
« Raspberry Pi 2で MPD再生する意義があるかも DSD再生の謎に迫る | トップページ | 一度RaspberryPiで使ったSDカードを簡単にFAT32へ戻す方法 »
DSD5.6の再生は、再生音がブツブツと切れるので難しいですね。ｍｐｄのCPU使用量が100%を超えています。ほかの３っのCPUは手伝ってはくれないのでしょうかね。
あと少しCPUの能力があればとクロックアップをしたら、Pi2が立ち上がらなくなり、32GBのｕＳＤを作り直す大騒ぎになってしまいました。
今回の、mpd_neonも期待してインストールしてみました。説明の通り、問題なく動くのですが、アップサンプリング等の設定をいじると、再起動してこないことがありました。mpd.bakを復活させれば、ほぼ動きますが、restartで
mpdWARNING Ignoring invalid value 'share' for parameter 'security'
が出ています。
mpd_0.19.7hfに換えたら、問題なく動いています。
投稿: nzato | 2015年2月18日 (水) 23時22分
nzato さん
ご報告ありがとうございます。 neonはコンパイラオプションだけでしたので、実際のデータストリーム処理上、何かが起こっているんですね。
> ｍｐｄのCPU使用量が100%を超えています。ほかの３っのCPUは手伝ってはくれないのでしょうかね。
MPDというソフトはマルチスレッドでプログラミングされていないということだと思います。 同時平行で複数のCPUに処理させて、最終的なデータをまたひとつにしてリアルタイムに出力するのは、少し難しいです。 マルチスレッドプログラミングに精通した人が改変しないといけないと思います。
そういう意味では、４コア低速CPUより、２コア高速CPUの方が汎用性が高いと思うんです。 細かい仕事を同時に多数処理するようなサーバー的使い方ならマルチコアCPUでもメリットはだせると思うのですが。。
投稿: たかじん | 2015年2月19日 (木) 20時08分
nzato さん
追加情報です。 lightMPD-v0.09 でラズパイ２対応されました。
https://sites.google.com/site/digififan/
こちらによると、DSD128（5.6M）のDSD2PCMができるようです。
試してみてはいかがでしょうか。
ラズパイ２の能力を存分に堪能できる仕様で、あまりに素晴らしすぎます。
私のようなエセlinuxユーザには到底できません。
近いうちに報告できたらと思います。
投稿: たかじん | 2015年2月19日 (木) 22時11分
nzatoさん
たかじんさん
SaberBerry+Pi2でvolumio1.5で快適に再生していたところ，lightmpdの0.09のPi2対応版が出たので，早速導入しました。
その結果，DSD2PCMで，DSD128も問題なく変換され再生しました。
音質的にもDSD対応のUSBDACに比べて遜色ありません。
ただし，USBだとノイズの問題がありますし，Pi(2なし)に比べてUSBDDCの相性が厳しいようです。また，USBの電源供給能力がPiより小さく，バスパワーのUSBDACが動作しないものがあります。
やはりラズパイはi2sに限る？という感じですね。
本当に感謝，感謝です。ありがとうございます。
投稿: Jiro | 2015年2月20日 (金) 00時31分
Jiroさん
色々検証もされたようで、ありがとうございます。 とても参考になりました。
RaspberryPiのUSBの弱さは、基板上でEthernet-USB変換を行なっているために、NASからデータを持ってきて、USB-DACへとデータを出すという処理に、USB通信に余裕が殆ど無くなってしまうことに起因しています。
> やはりラズパイはi2sに限る？という感じですね。
USB-DACが苦手なのは確かですね。 特にハイレゾデータは厳しいんだと思います。
投稿: たかじん | 2015年2月21日 (土) 00時36分
いつも、勉強させていただいてます。
neonの件ですが、-mfpu=neonでビルドするとmake checkで1項目だけNGになるようです。
-O3 -mfpu=vfpv4にすると、dsd再生でcpu使用率78%くらいになりました。ご参考まで
投稿: hnishi | 2015年3月16日 (月) 20時29分
hnishi さん
有用な情報ありがとうございます。 バージョンの違いでしょうか。 私のところだとneonでもコンパイルは通ります。 が、O3にしても90%は下回りません。
MPDのコンパイル環境は昨年の今頃つくったものですから、古すぎたんでしょうかね。 新しいコンパイラで試してみます。
投稿: たかじん | 2015年3月21日 (土) 10時10分
たかじんさん。コメントありがとうございます。
こちらはmpd 0.19.1で試していました。
-mfpu=neonにするとbuildは通るのですが、binaryの動作テストでNGが１項目でるのでそちらはあきらめていました。
ところで上記でビルドした0.19.1のバイナリですが、
「デジファイのおと」さんのところにも書いてありますように、sampling convartにlibsoxrを使うとCPUの使用率が一気に減ります。
raspberry pi2でsamplerate_converter "soxr very high"の指定ですが、topで確認したところ、
DSD64でCPU負荷30%
DSD128でCPU負荷60%
で音切れなく再生できてます。
ちなみにraspberry pi b+で確認したところ、
samplerate_converter "soxr low"の設定でDSD64がやっという感じでした。
投稿: hnishi | 2015年3月21日 (土) 17時27分
hnishi さん
バージョンは、mpd本体の他、各種ライブラリのバージョンやgccのバージョンなど色々な組み合わせがでてきて完全に同じ環境を作るのは難しいかもしれません。
リサンプラーは、mpd標準の物は精度重視でちょっと重たいです。 soxリサンプラーは処理が上手なのか、とても軽いですね。 fooberのリアルタイムアップサンプラーでもsoxが使われていて評判はよいみたいですから、RaspberryPi向きかもしれません。
DSD再生で78％になったというのはsoxリサンプラーを選択したおかげなのでしょうか。 ラズパイ１でもDSD変換再生が可能というのであれば、それはそれでメリットありますね。
投稿: たかじん | 2015年3月24日 (火) 23時00分