Select Your Language

免責事項

  • 本サイトの情報の利用、内容、サービスによって、利用者にいかなる損害、被害が生じても、著者は一切の責任を負いません。ユーザーご自身の責任においてご利用いただきますようお願いいたします。

    本サイトで頒布している基板およびキットは、技術者、またはそれに準ずる電気的知識をお持ちの電子工作ファンの方のためのものです。 一般のオーディオファンの方のためのものではありません。
    また、頒布基板およびキットは、いかなる条件でも動作を保証するものではございませんので、あらかじめご了承ください。

    電子工作では、火傷、感電、火災などの可能性があります。 十分に注意をして作業して下さい。

    営利目的のご使用は認めておりません。  記事の転載や、基板・キットの商用利用の方は、ご連絡ください。
    学生やサークルの学習目的でまとめてご購入する場合は特別なコースをご用意させていただきます。

スポンサー

« Raspberry Pi 2で MPD再生する意義があるかも DSD再生の謎に迫る | トップページ | 一度RaspberryPiで使ったSDカードを簡単にFAT32へ戻す方法 »

2015年2月15日 (日)

ラズパイ2に搭載しているARMv7のNEONとは? 最適化する方法は意外と簡単

RaspberryPi (1)は、いわゆるARM11というCPUでした。 RaspberryPi 2ではCortex-A7というCPUに変わっています。 

Armprocessor 

少しややこしいのが、CPUの名称と、アーキテクチャナンバー。 詳しくはこちらをご覧いただくとして、ここでは概略と、新命令NEONを有効にする方法だけを取上げたいと思います。

 

ARMには、CPUの名称とは別にアーキテクチャナンバーがあり、命令はアーキテクチャナンバーによって変わってきます。 つまりARM7とARMv7は全く別物です。 

ARM7はあのポケットステーションにも使われていたように、かなり昔からある低消費電力なCPUです。 

対してARMv7(アーキテクチャ)は、最近のCortex-Aシリーズに採用されている命令セットです。 なにやら沢山命令があります。 いわゆるコプロセッサ、x86でいえば、80287のようなものがVFP(浮動小数点演算器)にあたります。 NEONはSIMD命令なのでMMXとかSSEにあたるモノだと思います。 

ラズパイ2に追加になった命令(VFPv3とNEON)を有効につかってみようというのが今回の趣旨です。  オーディオの演算には掛算がとても多く使われるので、コプロセッサを使うと処理が劇的に速くなるんじゃないかと思ったからです。  

 

 

 

つい数年前(2007年くらい?)まではCコンパイラは自動でコプロセッサの命令を吐いてはくれず、手でアセンブラをかかないといけませんでした。 ところが、gccのあるバージョンからVFPやNEONの命令を自動で作ってくれるようになっています。 

では、どうやってVFP/NEONを使うようにするのか? 調べてみました。 

コンパイルオプションに下記を付け足せばOKらしい。  

 -mfpu=neon -mfloat-abi=softfp -march=armv7-a

なんだ、簡単じゃん。 と試してみたものの、コンパイルに約2時間、最後、ライブラリなどリンカーがまとめる時に

 /usr/bin/ld: error: xxxx  uses VFP register arguments, xxxx.o does not

というエラーが沢山出てしまい、コンパイルが完了しません。  

コンパイルに2時間もかかるので、あれこれ試したくても1日にできる作業はほんの数回で、気がつけば3日もトライしてました。 

 

 

さてさて、何が原因だったのかといいますと、「-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_neon  

 

このコンパイル済み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+でも実行できるハードウェアフローティングのバイナリになります。 (2種類のバイナリを置いておきました) 

 

 

 

 

 

にほんブログ村 PC家電ブログ PCオーディオへ にほんブログ村
ブログランキングに参加中です。 めざせ1位! 
もしよろしければ「ぽちっと」お願いします。 



« Raspberry Pi 2で MPD再生する意義があるかも DSD再生の謎に迫る | トップページ | 一度RaspberryPiで使ったSDカードを簡単にFAT32へ戻す方法 »

Raspberry Pi」カテゴリの記事

コメント

 DSD5.6の再生は、再生音がブツブツと切れるので難しいですね。mpdのCPU使用量が100%を超えています。ほかの3っのCPUは手伝ってはくれないのでしょうかね。

 あと少しCPUの能力があればとクロックアップをしたら、Pi2が立ち上がらなくなり、32GBのuSDを作り直す大騒ぎになってしまいました。

 今回の、mpd_neonも期待してインストールしてみました。説明の通り、問題なく動くのですが、アップサンプリング等の設定をいじると、再起動してこないことがありました。mpd.bakを復活させれば、ほぼ動きますが、restartで
   mpdWARNING Ignoring invalid value 'share' for parameter 'security'
が出ています。

 mpd_0.19.7hfに換えたら、問題なく動いています。

nzato さん

ご報告ありがとうございます。 neonはコンパイラオプションだけでしたので、実際のデータストリーム処理上、何かが起こっているんですね。

> mpdのCPU使用量が100%を超えています。ほかの3っのCPUは手伝ってはくれないのでしょうかね。
MPDというソフトはマルチスレッドでプログラミングされていないということだと思います。 同時平行で複数のCPUに処理させて、最終的なデータをまたひとつにしてリアルタイムに出力するのは、少し難しいです。 マルチスレッドプログラミングに精通した人が改変しないといけないと思います。

そういう意味では、4コア低速CPUより、2コア高速CPUの方が汎用性が高いと思うんです。  細かい仕事を同時に多数処理するようなサーバー的使い方ならマルチコアCPUでもメリットはだせると思うのですが。。

nzato さん

追加情報です。 lightMPD-v0.09 でラズパイ2対応されました。
https://sites.google.com/site/digififan/

こちらによると、DSD128(5.6M)のDSD2PCMができるようです。
試してみてはいかがでしょうか。

ラズパイ2の能力を存分に堪能できる仕様で、あまりに素晴らしすぎます。
私のようなエセlinuxユーザには到底できません。


近いうちに報告できたらと思います。

nzatoさん
たかじんさん

SaberBerry+Pi2でvolumio1.5で快適に再生していたところ,lightmpdの0.09のPi2対応版が出たので,早速導入しました。
その結果,DSD2PCMで,DSD128も問題なく変換され再生しました。
音質的にもDSD対応のUSBDACに比べて遜色ありません。
ただし,USBだとノイズの問題がありますし,Pi(2なし)に比べてUSBDDCの相性が厳しいようです。また,USBの電源供給能力がPiより小さく,バスパワーのUSBDACが動作しないものがあります。
やはりラズパイはi2sに限る?という感じですね。
本当に感謝,感謝です。ありがとうございます。

Jiroさん

色々検証もされたようで、ありがとうございます。 とても参考になりました。

RaspberryPiのUSBの弱さは、基板上でEthernet-USB変換を行なっているために、NASからデータを持ってきて、USB-DACへとデータを出すという処理に、USB通信に余裕が殆ど無くなってしまうことに起因しています。

> やはりラズパイはi2sに限る?という感じですね。
USB-DACが苦手なのは確かですね。 特にハイレゾデータは厳しいんだと思います。

いつも、勉強させていただいてます。
neonの件ですが、-mfpu=neonでビルドするとmake checkで1項目だけNGになるようです。
-O3 -mfpu=vfpv4にすると、dsd再生でcpu使用率78%くらいになりました。ご参考まで

hnishi さん

有用な情報ありがとうございます。 バージョンの違いでしょうか。 私のところだとneonでもコンパイルは通ります。 が、O3にしても90%は下回りません。

MPDのコンパイル環境は昨年の今頃つくったものですから、古すぎたんでしょうかね。 新しいコンパイラで試してみます。

たかじんさん。コメントありがとうございます。
こちらはmpd 0.19.1で試していました。
-mfpu=neonにするとbuildは通るのですが、binaryの動作テストでNGが1項目でるのでそちらはあきらめていました。

ところで上記でビルドした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 さん

バージョンは、mpd本体の他、各種ライブラリのバージョンやgccのバージョンなど色々な組み合わせがでてきて完全に同じ環境を作るのは難しいかもしれません。
リサンプラーは、mpd標準の物は精度重視でちょっと重たいです。 soxリサンプラーは処理が上手なのか、とても軽いですね。 fooberのリアルタイムアップサンプラーでもsoxが使われていて評判はよいみたいですから、RaspberryPi向きかもしれません。 
DSD再生で78%になったというのはsoxリサンプラーを選択したおかげなのでしょうか。 ラズパイ1でもDSD変換再生が可能というのであれば、それはそれでメリットありますね。

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/587107/61138949

この記事へのトラックバック一覧です: ラズパイ2に搭載しているARMv7のNEONとは? 最適化する方法は意外と簡単:

« Raspberry Pi 2で MPD再生する意義があるかも DSD再生の謎に迫る | トップページ | 一度RaspberryPiで使ったSDカードを簡単にFAT32へ戻す方法 »

サイト内検索

Sponsors link

2017年10月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

最近のトラックバック

無料ブログはココログ