Select Your Language

免責事項

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

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

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

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

スポンサー

« IOデータのオーディオ専用NAS 「Soundgenic」 | トップページ | 無料CADソフト"DraftSight"が使いやすい »

2019年1月16日 (水)

NASを交換したら音が変わった。その謎に迫る?

ネットワークオーディオで、NASを交換したら音が変わったという意見は、複数の方から聞いたことがありました。先日、自分自身も経験しました。

これは一体どういうこと?

TCP/IPでの転送なのでデータ自体はビットパーフェクトを保っているハズです。

ということで、MPDを使ったネットワークオーディオのシステムの中のデータの流れを視覚化してみました。

Nas_mpd01

このように、データがNASから送られてきてI2Sで出力するまでの間に沢山のバッファを通ります。cifs以下はラスパイの中です。Pi2以降ではメインメモリが1GBもあるので、各所のバッファを大きめにしても大丈夫かと思うのですが、実際には限界があります。

 

これらデータバッファは、FIFO(おそらくRingバッファ)を使うものです。データ転送時のジッターはデータバッファがあるシステムのクロック依存となり、当然、入力されたときの受信時間バラツキ(ジッター?)は出力時には排除されます。

メモリバッファ式DAI(DAC)の効果と同じと考えて差し支えありません。が、そもそもTCP/IPでもらってくるデータは一定速度ではありません。

 

 

cifsマウント部

ラズパイに入ってくる最初のバッファがcifsマウント部です。samba(winのファイル共有)サーバーが公開しているネットワーク上のファイルを取り込んでいます。

VolumioやMoode Audioでアルバム1枚分をリピート再生された方はご存知だと思うのですが、再生2周目以降はラズパイの中のRAMに残ったデータが使われてNASから読まなくなるので、しばらくするとNASのHDDは停止します。

 

ということで再生1周目と2周目の音が違う可能性があるのですが、時間が経っているのではっきりと体感出来ておりません。(RockDiskNEXTでは体感できていたと思う)

アルバム1枚分のデータは、CDをリッピングしたFLAC(fs44.1k/16bit)ならFLACのままcifsのキャシュとしてラズパイのRAMに保存されています。

Mpd_system02

cifsで使っていると思われるキャッシュの量はtopコマンドで見ることが可能です。 再生時間と共にどんどん増えて行きます。上の画像では約370MBほどのキャッシュが使われています。再生2周目以降キャッシュがヒットするとNASまでデータを取りに行かず、ローカルのデータで済ませるようになります。

つまり2周目以降の再生はどう考えてもNASの影響は無いと思われます。

 

 

 

MPD部

mpd.confの中で指定するaudio_buffer_sizeは、デコード済みのデータ(PCM)を置くバッファサイズです。このバッファが一杯になるとデコードを停止し、buffer_before_playで指定した%まで送り出すとデコードを再開します。

つまり、圧縮音源のデコードは間欠動作しています。標準サイズの4MBでbuffer_before_playを10%にしていると約1秒間デコードして20秒間停止という間欠デコードを再生のバックグラウンドで繰り返しています。

 

CDフォーマットなら10MBで約1分間のPCMを展開できる大きさです。5分の曲なら50MBに設定するとまるまる1曲分をデコードしてから再生できます。(正確には再生開始から7~10秒間くらいはバックグラウンドでデコードしています)

ということでNASからリアルタイムにデータを引き出しているわけではありません。1曲分まるっとデータをローカルバッファに展開してしまえばNASの影響はなくなると考えられます。しかし、しかし、残念ながら、audio_buffer_sizeを大きくしすぎるとMPDの操作系のレスポンスが極端に悪化するというバグ(?)があり、実用的とは言えません。 が、興味がありましたら試してみると面白いと思います。

まあ、標準でも数十秒に1秒間くらいデコードが走るという間欠動作ですから、さほど気になることもないと思いませんか?

 

逆にaudio_buffer_sizeを非常に小さくすると、デコーダが頻繁にON/OFFするので別の意味で音に変化が現れます。例えば1秒間に20回とかデコード動作がON/OFFするならトレモロのような効果が出るかもしれません。デコードの間欠動作はCPU負荷が増減するので、CPUの電流にも変化を及ぼし、結果的に音へ影響が出るというのは納得できるかと思います。

audio_buffer_sizeで再生音のチューニングをされている方がいらっしゃるのもわかりますね。

 

 

ALSAドライバ

Linuxの標準オーディオドライバです。jackやpulseaudioなど上位のオーディオサーバーを使うよりもコアなドライバだけを使うとCPU負荷を無駄につかわずに済みます。

 

 

シリアル出力部

Pi 3の SoCチップのシリアル出力部にもハードウェアバッファが入っています。TX、RXともに64x32bitです。このバッファが空にならない様にDMA(Direct Memory Access)というハードウェアのデータ転送機能を使ってデータをもらってきます。DMAの設定自体はALSAドライバが行っていますが、実動作はCPU(ソフトウェア)を介在しないでデータ転送できるのが特徴です。

I2Sをスレーブにした場合は、DAC側のBCKに同期してシリアルデータを出力するようになります。

 

 

こうしてデータの流れを解析するとNASによる音の変化という謎は一層深まります。

 

LANの配線から伝わってくる外来ノイズという観点では、ラズパイの直前のEthernet-HUBが最も影響力が大きいと思われます。が、LANケーブルを引っこ抜くと再生が止まってしまうのが惜しいです。。。

 

 結局、NASでなぜ音が変化するのでしょうか?

 

オーディオ用を謳うNASを作っているメーカーの特設サイトを見ると天板の厚さを替えて試聴を繰り返したとか、コンデンサの位置にこだわったとか。。。

 

うーん。 と頭をかかえてしまいますね。

 

 

 

ここまで書いていて気がついたのですが、

アルバム1枚ではなく1曲のみキューに登録すれば1周目と2周目とで音に変化があるのか、聴き比べしやすいかも。。 

NASのHDDが停止するのは30分後(設定次第?)だったりもしますが、、、とりあえず耳に自信がある方は試してみてください。

 

 

 

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

« IOデータのオーディオ専用NAS 「Soundgenic」 | トップページ | 無料CADソフト"DraftSight"が使いやすい »

PCオーディオ」カテゴリの記事

コメント

 なんでNAS を変えると音が変わるのか、考えると頭が混乱してきます。NASの電源を変えても音は大きく変わる経験をしています。DC-ARROWは5Vですが、12V仕立てにして聞いてみていただきたいと思うのです。ノイズの影響くらいしか思いつきません。悩んでいます。
 新DAC楽しみに待っています!

audio_buffer_sizeを小さくする手法は、レイテンシを短くして高音質を目指すためです。
音質はレイテンシに左右され、短ければ短いほど良いのです。

 はじめまして。
マークオーディオの代理店フィディリティムサウンドのお手伝いをしているKazと申します。
 実は来週のオーディオイベント用にSabreBerry32を購入し、ラズパイ再生のサブシステムを組もうと思っていたのですが売り切れで…

 そのオーディオイベントの準備としてフィディリティムサウンドのPi3を借りて聴いてみたところNASストレージとUSBストレージの音質差が大きくて驚きました。私のPi3+はNASストレージとUSBストレージ再生で音質差が少ないので、USB周りが改良されてるっぽいですね。

 新DACが発売されたら導入しようと思っておりますので、発売をたのしみにしてます。

そういやちょっと前に、Windowsのソフトで一曲丸ごと自分のバッファに取り込んでから再生するソフトがありました。
メモリー食いで32bitソフトなんで、再生に関わらないプロセスは全部抜いとけとか書いてありました。

さて、音でしたが…私では(笑)

ろぺさん

色々考えるとNASの電源は影響がでそうですね。やっぱりノイズの可能性が高いですかね。
LANケーブルにノイズフィルタを入れて直接的に変化させてみるのもいいかもしれません。

let31 さん

レイテンシを小さくすると良いと言われている分野もありますね。特にDTMなど。
録音済みの音楽を再生するときは、レイテンシは特に関係ないと思っているのですが、検討の価値はあるかもしれません。

Kaz さん

sabreberry32はデジットではまだ扱っていると思います。がフル実装版ではありません。 手持ちで在庫がありますので、お送りいたしましょうか?

スイッチサイエンスに補充するには数日かかりますのでイベントには間に合いそうにありません。
新DACは2月上旬になる予定ですが、まだ確定ではありません。
よろしくお願いいたします。

天 麩羅夫さん

そんなソフトもあるのですね。いま思えば、Volumio 1.XXのときはRAMディスクからの再生ができましたね。 あれ、音が良かったと記憶しております。

再生している最中に、イーサネットやUSBなどにアクセスするかしないかで音が違うのかもしれません。。

奥が深いです。

  たかじんさん
ありがとうございます、早く連絡を取ればよかったです…失敗しました。
今回のイベント用に間に合わせるためにHiFiBerry DAC+ Pro XLRを発注してしまったんです。

すこし横から失礼します。RAMからの再生の話ですが、mpdに手を加えビルドすれば、だいたいのディストリで似たようなことはできるように思ってます。
たかじんさんのvolumioの記事を参考にしたことですが、一曲再生のたびファイルを一度tmpfsに(自動で)置いて、そこからmpdに読ませるという動作をさせる方法です。そうすれば、ストレージによる差をいちおう心配する必要なくなるかな…と思うわけです。
ちなみに「lightmpd ramplay」などで検索すると、そちらの掲示板に私が以前投稿したmpdのpatchが見つかるんではと。じつは先週くらいにB4dac用のシステム更新をしたので、mpd-0.20.23のビルド時に直したpatchも手元にあったりします。

話がかわるのですが、sebreberry32のようにヘッドホンを直接使える基板にちかごろ興味があります。新基板はそうしたことが可能なものでしょうか?さしつかえなければ、そのあたり、お聞きしたいです。

Kazさん

大変申し訳ございません。
品切れにならないようにしようとは思っているのですが、気がつくといろいろ品切れになってしまっています。

HiFiBerry DAC+ Proもマスタークロックを搭載したモデルですので、ラズパイのジッター問題がでないもののハズです。

にいむらさん

なるほど、その手があるのですね。 市販のネットワークオーディオ機器ではなく、自作でプログラムするからこそできる芸当ですね。 素晴らしいと思います。
ちょっと調べて試してみたいです。

新DAC基板は、sabreberry32と同様にヘッドホンを直接ドライブできるタイプです。 そうは言っても強力なドライブ回路を持った専用のヘッドホンアンプを通した方が音が良いこともございます。 このあたりは、ドライブしやすいヘッドホンと、ドライブの難しいヘッドホンとで差がでるので、ヘッドホン次第かと思います。

初めまして。Pal8000と申します。
趣味でWindows上で走るVUメーターソフトを作っていますが、最近Volumio2対応をしています。
MPDからの音量データを横取りして、HTTPでWindows上のクライアントに配信し、アナログメーター表示をするものです。
今のところ動作確認中なのですが、Volumio2側で4時間くらいの長いファイルを再生すると、時間が経過するにつれて針が先に振れてしまう、という面白い現象が出ています。
ネットで検索してもなかなかMPDの情報が見つかりませんが、今回の記事で、もしかすると先読みしたデータがたまってしまい、取るべき場所が判らないのかもしれないと思いました。
FIFOからの取り出し方には、もう一工夫必要なようです。
タイムリーでしたので、お礼を兼ねてポストしました。

たかじんさんへ。前のコメントでちゃんと書くのを忘れてましたが、長らくB4dacは愛用させていただいております。

mpd改造の件は、Googleの掲示板は投稿へのリンクが作れるようなので張ってみます:
https://groups.google.com/d/msg/lightmpd/T73SRLcqyjM/NmT_AFd3DwAJ
の投稿の(3)の部分です。ご参考まで…。(細かいことですが、シェルを呼んでるところはC++の関数でも済むと思いますが、まあ機能的には変わらないので…。といいますか、C++をちゃんと知ってる人なら、全体的にもっと綺麗にできそうに感じてます。)

また、新基板の情報ありがとうございます。楽しみにしております。
家でじっくり音楽を聞く時間もなかなか少ないので、据置きとは別に、移動時・出張時などのポータブル用途も自作すると満足度が増すかな?とこのごろ思ってました。携帯性との兼ね合いが難しい感じですが、場合によってはポータブル・アンプ的なものも併せて、考えてみようかと思います。

Pal8000 さん

それはおもしろいソフトですね。 alsaからレベル情報をもらってくると時間ずれが起きないかもしれません。

ただ、4時間という楽曲はなかなか無いので問題にならないような気もします。


にいむらさん

B4DACのご利用ありがとうございます。

webサイト拝見させていただきました。 mpdにパッチを当ててデータ読み出し時にtmpfsに保存するような感じなのですね。これなら使用上も何も意識しないでメモリ再生になりますね。 素晴らしいと思います。

試してみようかと思います。 最近のmpdは、今までのコンパイル方法ではなくなりましたね。。。  NEONなどのSIMD命令を使うにはどう指示すれば良いのかまだわかっていません。

たかじんさん
以前、ALSAにも興味を持ったのですが、リアルタイム音量でなく、音量設定を取得する方法しか見つけられませんでした。
ひとつのAPI名が手がかりになることもあるのですが、先日Pythonでaudioopというのを見つけて取り組んでいます。
今回の記事でもaudio_buffer_sizeが出てきますが、検索したら興味深かったです。コメントありがとうございます。

たかじんさん。

最新のmpd-0.21系はmesonというものを使うんですよね。本家ページに標準的ビルドの解説があるくらいで、細かい情報が現状ない感じで、私自身は0.20系で様子見してました。上のパッチについては、もし0.21系を使うなら、FileReader.cxx 内で関数の記述に少し変更があったらしく、手作業の修正が必要と思われます。

あと、私自身は最適化オプションについて、たかじんさんの記事など真似するだけで深い理解はないのですが、たまたま meson の howto(https://mesonbuild.com/howtox.html)に、
$ CFLAGS=-fsomething LDFLAGS=-Wl,--linker-flag meson ..
と書いてあるのを見かけました。あと、mpd-git の
https://github.com/MusicPlayerDaemon/MPD/blob/master/meson.build
の30行あたりには common_cflags, common_cxxflags とあり、その下に test_common_flags とあって -ffast-math などが見えるので、直接このファイルを編集するやり方で、いちおうオプションをつけられるかな?と思いました。このへん、ご参考になるかわかりませんが…

Pal8000 さん

以前試したときにはここを参考にしました。
https://github.com/pimoroni/phat-beat

できたものはこちら。
https://twitter.com/TakazineZone/status/917020880462503937


にいむらさん

なるほど。色々調べていけば道筋が見えてきそうですね。ありがとうございます。
それにしてもmesonの情報が少ないですね。makeに代わってメインになりそうな雰囲気もあるのに。

コメントを書く

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

トラックバック


この記事へのトラックバック一覧です: NASを交換したら音が変わった。その謎に迫る?:

« IOデータのオーディオ専用NAS 「Soundgenic」 | トップページ | 無料CADソフト"DraftSight"が使いやすい »

サイト内検索(new)

2025年2月
            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