NASを交換したら音が変わった。その謎に迫る?
ネットワークオーディオで、NASを交換したら音が変わったという意見は、複数の方から聞いたことがありました。先日、自分自身も経験しました。
これは一体どういうこと?
TCP/IPでの転送なのでデータ自体はビットパーフェクトを保っているハズです。
ということで、MPDを使ったネットワークオーディオのシステムの中のデータの流れを視覚化してみました。
このように、データが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に保存されています。
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分後(設定次第?)だったりもしますが、、、とりあえず耳に自信がある方は試してみてください。
にほんブログ村
ブログランキングに参加中です。 めざせ1位!
もしよろしければ「ぽちっと」お願いします。
« IOデータのオーディオ専用NAS 「Soundgenic」 | トップページ | 無料CADソフト"DraftSight"が使いやすい »
「PCオーディオ」カテゴリの記事
- RaspberryPi Pico USB-DDC化 I2SとMSBファースト後詰め出力対応(2022.03.21)
- RaspberryPi Pico USB-DDC化? I2S出力調査(2022.03.20)
- efuさんのWaveSpectraが公開停止していた(2022.03.09)
- ラズパイをUSB-DACとしてスマホに認識させる方法 gadget mode(USB Audio Class 2.0)(2020.10.16)
- PCに組み込むヘッドホンアンプ Sound RABBIT & 900万PVありがとう企画(2020.10.10)
コメント
« IOデータのオーディオ専用NAS 「Soundgenic」 | トップページ | 無料CADソフト"DraftSight"が使いやすい »
なんでNAS を変えると音が変わるのか、考えると頭が混乱してきます。NASの電源を変えても音は大きく変わる経験をしています。DC-ARROWは5Vですが、12V仕立てにして聞いてみていただきたいと思うのです。ノイズの影響くらいしか思いつきません。悩んでいます。
新DAC楽しみに待っています!
投稿: ろぺ | 2019年1月17日 (木) 01時35分
audio_buffer_sizeを小さくする手法は、レイテンシを短くして高音質を目指すためです。
音質はレイテンシに左右され、短ければ短いほど良いのです。
投稿: let31 | 2019年1月17日 (木) 09時32分
はじめまして。
マークオーディオの代理店フィディリティムサウンドのお手伝いをしているKazと申します。
実は来週のオーディオイベント用にSabreBerry32を購入し、ラズパイ再生のサブシステムを組もうと思っていたのですが売り切れで…
そのオーディオイベントの準備としてフィディリティムサウンドのPi3を借りて聴いてみたところNASストレージとUSBストレージの音質差が大きくて驚きました。私のPi3+はNASストレージとUSBストレージ再生で音質差が少ないので、USB周りが改良されてるっぽいですね。
新DACが発売されたら導入しようと思っておりますので、発売をたのしみにしてます。
投稿: Kaz | 2019年1月17日 (木) 09時54分
そういやちょっと前に、Windowsのソフトで一曲丸ごと自分のバッファに取り込んでから再生するソフトがありました。
メモリー食いで32bitソフトなんで、再生に関わらないプロセスは全部抜いとけとか書いてありました。
さて、音でしたが…私では(笑)
投稿: 天 麩羅夫 | 2019年1月17日 (木) 11時58分
ろぺさん
色々考えるとNASの電源は影響がでそうですね。やっぱりノイズの可能性が高いですかね。
LANケーブルにノイズフィルタを入れて直接的に変化させてみるのもいいかもしれません。
let31 さん
レイテンシを小さくすると良いと言われている分野もありますね。特にDTMなど。
録音済みの音楽を再生するときは、レイテンシは特に関係ないと思っているのですが、検討の価値はあるかもしれません。
Kaz さん
sabreberry32はデジットではまだ扱っていると思います。がフル実装版ではありません。 手持ちで在庫がありますので、お送りいたしましょうか?
スイッチサイエンスに補充するには数日かかりますのでイベントには間に合いそうにありません。
新DACは2月上旬になる予定ですが、まだ確定ではありません。
よろしくお願いいたします。
天 麩羅夫さん
そんなソフトもあるのですね。いま思えば、Volumio 1.XXのときはRAMディスクからの再生ができましたね。 あれ、音が良かったと記憶しております。
再生している最中に、イーサネットやUSBなどにアクセスするかしないかで音が違うのかもしれません。。
奥が深いです。
投稿: たかじん | 2019年1月17日 (木) 18時48分
たかじんさん
ありがとうございます、早く連絡を取ればよかったです…失敗しました。
今回のイベント用に間に合わせるためにHiFiBerry DAC+ Pro XLRを発注してしまったんです。
投稿: Kaz | 2019年1月17日 (木) 22時45分
すこし横から失礼します。RAMからの再生の話ですが、mpdに手を加えビルドすれば、だいたいのディストリで似たようなことはできるように思ってます。
たかじんさんのvolumioの記事を参考にしたことですが、一曲再生のたびファイルを一度tmpfsに(自動で)置いて、そこからmpdに読ませるという動作をさせる方法です。そうすれば、ストレージによる差をいちおう心配する必要なくなるかな…と思うわけです。
ちなみに「lightmpd ramplay」などで検索すると、そちらの掲示板に私が以前投稿したmpdのpatchが見つかるんではと。じつは先週くらいにB4dac用のシステム更新をしたので、mpd-0.20.23のビルド時に直したpatchも手元にあったりします。
話がかわるのですが、sebreberry32のようにヘッドホンを直接使える基板にちかごろ興味があります。新基板はそうしたことが可能なものでしょうか?さしつかえなければ、そのあたり、お聞きしたいです。
投稿: にいむら | 2019年1月19日 (土) 20時09分
Kazさん
大変申し訳ございません。
品切れにならないようにしようとは思っているのですが、気がつくといろいろ品切れになってしまっています。
HiFiBerry DAC+ Proもマスタークロックを搭載したモデルですので、ラズパイのジッター問題がでないもののハズです。
にいむらさん
なるほど、その手があるのですね。 市販のネットワークオーディオ機器ではなく、自作でプログラムするからこそできる芸当ですね。 素晴らしいと思います。
ちょっと調べて試してみたいです。
新DAC基板は、sabreberry32と同様にヘッドホンを直接ドライブできるタイプです。 そうは言っても強力なドライブ回路を持った専用のヘッドホンアンプを通した方が音が良いこともございます。 このあたりは、ドライブしやすいヘッドホンと、ドライブの難しいヘッドホンとで差がでるので、ヘッドホン次第かと思います。
投稿: たかじん | 2019年1月21日 (月) 21時54分
初めまして。Pal8000と申します。
趣味でWindows上で走るVUメーターソフトを作っていますが、最近Volumio2対応をしています。
MPDからの音量データを横取りして、HTTPでWindows上のクライアントに配信し、アナログメーター表示をするものです。
今のところ動作確認中なのですが、Volumio2側で4時間くらいの長いファイルを再生すると、時間が経過するにつれて針が先に振れてしまう、という面白い現象が出ています。
ネットで検索してもなかなかMPDの情報が見つかりませんが、今回の記事で、もしかすると先読みしたデータがたまってしまい、取るべき場所が判らないのかもしれないと思いました。
FIFOからの取り出し方には、もう一工夫必要なようです。
タイムリーでしたので、お礼を兼ねてポストしました。
投稿: Pal8000 | 2019年1月22日 (火) 12時54分
たかじんさんへ。前のコメントでちゃんと書くのを忘れてましたが、長らくB4dacは愛用させていただいております。
mpd改造の件は、Googleの掲示板は投稿へのリンクが作れるようなので張ってみます:
https://groups.google.com/d/msg/lightmpd/T73SRLcqyjM/NmT_AFd3DwAJ
の投稿の(3)の部分です。ご参考まで…。(細かいことですが、シェルを呼んでるところはC++の関数でも済むと思いますが、まあ機能的には変わらないので…。といいますか、C++をちゃんと知ってる人なら、全体的にもっと綺麗にできそうに感じてます。)
また、新基板の情報ありがとうございます。楽しみにしております。
家でじっくり音楽を聞く時間もなかなか少ないので、据置きとは別に、移動時・出張時などのポータブル用途も自作すると満足度が増すかな?とこのごろ思ってました。携帯性との兼ね合いが難しい感じですが、場合によってはポータブル・アンプ的なものも併せて、考えてみようかと思います。
投稿: にいむら | 2019年1月24日 (木) 21時54分
Pal8000 さん
それはおもしろいソフトですね。 alsaからレベル情報をもらってくると時間ずれが起きないかもしれません。
ただ、4時間という楽曲はなかなか無いので問題にならないような気もします。
にいむらさん
B4DACのご利用ありがとうございます。
webサイト拝見させていただきました。 mpdにパッチを当ててデータ読み出し時にtmpfsに保存するような感じなのですね。これなら使用上も何も意識しないでメモリ再生になりますね。 素晴らしいと思います。
試してみようかと思います。 最近のmpdは、今までのコンパイル方法ではなくなりましたね。。。 NEONなどのSIMD命令を使うにはどう指示すれば良いのかまだわかっていません。
投稿: たかじん | 2019年1月26日 (土) 09時01分
たかじんさん
以前、ALSAにも興味を持ったのですが、リアルタイム音量でなく、音量設定を取得する方法しか見つけられませんでした。
ひとつのAPI名が手がかりになることもあるのですが、先日Pythonでaudioopというのを見つけて取り組んでいます。
今回の記事でもaudio_buffer_sizeが出てきますが、検索したら興味深かったです。コメントありがとうございます。
投稿: Pal8000 | 2019年1月26日 (土) 18時14分
たかじんさん。
最新の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 などが見えるので、直接このファイルを編集するやり方で、いちおうオプションをつけられるかな?と思いました。このへん、ご参考になるかわかりませんが…
投稿: にいむら | 2019年1月26日 (土) 21時50分
Pal8000 さん
以前試したときにはここを参考にしました。
https://github.com/pimoroni/phat-beat
できたものはこちら。
https://twitter.com/TakazineZone/status/917020880462503937
にいむらさん
なるほど。色々調べていけば道筋が見えてきそうですね。ありがとうございます。
それにしてもmesonの情報が少ないですね。makeに代わってメインになりそうな雰囲気もあるのに。
投稿: たかじん | 2019年2月 6日 (水) 23時32分