I2S-DACを348kHzで駆動すると、どういうメリットがあるの?
RaspberryPiのI2S出力は最大で384kHzのサンプリング周波数で出力が可能であることは、日経リナックスに書かれていて、ご存知の方も多いと思います。
ここでは、実際に試してみた結果と、384kHzで出力できることのメリットとして、どんなケースが考えられるのかを書きたいと思います。
実は、日経リナックス2016年6月を号買ったのですが、この号の読者専用のダウンロードサイトから落としてきたドライバで348kHz駆動がすんなり出来たかというと、そうではありませんでした。
なぜかカーネル 4.1.21用という中途半端なバージョンになっていて、Rasbianイメージをダウンロードしたままでは組み込むことが出来ないのです。 ここの情報によると、各SDカードイメージのkernelバージョンは
Raspbian Jessie Lite 2016-02-09 (kernel 4.1.7+)
Raspbian Jessie Lite 2016-02-26 (kernel 4.1.7+)
Raspbian Jessie Lite 2016-03-18 (kernel 4.1.7+)
Raspbian Jessie Lite 2016-05-10 (kernel 4.4+)
Raspbian Jessie Lite 2016-05-27 (kernel 4.4+)
Linuxに精通している人はご存知とは思いますが、現在のLinuxのドライバはKernelのバージョンが末尾までひとつでも違うと組み込めません。
まあ、それはそれとして、384kHz再生の利用目的も私の考えていたのとちょっと違うなぁっと思いました。
というのも、
筆者さんは、CDからリッピングした44.1kHzの信号をそのままDACに出力した場合と、SoXリサンプラーを使ってソフトウェアアップサンプリングした場合とを比較されていました。
つまり、DAC内蔵オーバーサンプリングデジタルフィルタとSoXリサンプラーの比較(差換え)です。 (アップサンプリングしたらからといってハイレゾになる訳ではないというのは筆者さんと同意見です)
SoXリサンプラーは、動作が軽い割に特性も悪くなく、音もまあまあ良い(カラーレーションが少ない)ので、リアルタイム処理のときには良く使われていますが、ハードウェアによるFIR演算や、高精度なアップサンプリングソフトウェア(非リアルタイム系)と比較するとさすがに負けてしまいます。
実際にSoXを介した場合と、そのままDACへ送って内蔵アップサンプラーを使ったときとを比較試聴した場合、SoXは中高域にキラキラしたキャラクタを感じる人が多いのではないでしょうか?
一見、華やかで鮮度が高く感じますが、大音量で聴くと、じきに音量を下げたくなってしまう音というと解かり易いかもしれません。
PCM5102AクラスのDACでも44.1/48kHzは8倍、88.2/96kHzは4倍、176.4/192kHzは2倍のアップサンプリングがDAC内部で行なわれているため、CDを再生しても、よくハイレゾの説明で使われるようなギザギザ波形では再生されていません。 最低でも352.8kHzのサンプリングレートで滑らかにDA変換されています。
そして、PCM51xx系のDACに内蔵されているデジタルフィルタは、かなり音が良い(特性はソコソコの)ものが搭載されています。 このあたりは30年もの間、DA変換を専門でやってきたバーブラウンのノウハウの賜物でしょう。
前置きが長くなりすぎました。
さて、
私が384kHz再生でメリットがあるのでは? と思うのは、下図のようなケースです。
「意外と」 と言ってしまうとアレですが、MPDのDSD変換再生は、想像していた以上に上品で聴き応えのある音がしますね。 ですが、この図の上側のようにPCMに変換したあとSoXリサンプラーによって192kHzまでもう一度変換されていました。
これが、348kHzまで対応できるようになると図の下側のようにDSD to PCMで352.8kHz PCMに変換したあと、そのままDACへ出力できます。 無駄な変換がいらなくなり、よりストレートに再生が可能になりますね。
この図が実際にDSD2.8MHzから352.8kHzで再生しているときの証拠(?)です。
cat /proc/asound/card0/pcm0p/sub0/hw_params
とコマンドを打つと、再生しているサンプリングレートが分かります。 Alsaドライバは下記のサイトの352.8k and 384k 拡張パッチを実装しました。
https://patchwork.kernel.org/patch/9160203/
それに、SabreBerry32のドライバも合わせて拡張しています。
ただし、完全に音切れなく再生できるかというと、まだそこまでは到達できておらず、時折ノイズが混じってしまう問題が潜んでいます。 (low-latency-kernel なども検討中)
DSD変換再生のほか、DXDという348kHz(もしくは352.8k ) 24bitのPCMで録音されたものをNOS-DACで再生するというのも面白いと思います。
DXD録音のサンプリングレートなら、NOS(ノン・オーバー・サンプリング)で聴いても全く問題がないと考えられるからです。 さいわい2LのサイトにはDXDの無料サンプルが何曲か置いてありますね。(無料DSDサンプルもある)
352.8k and 384k 拡張Alsaドライバの対応方法の詳細は、また後日説明したいと思います。
現時点で2.8MHz のDSD再生の音飛びは、なんとなく解消されつつあります。(曲によっては飛ぶ。 5.6MHzDSDは全然NG )
DSDから352.8kHz PCM変換再生の音
肝心な音質の感想はといいますと、SoXを使っていたときのDSDの音とはかなり傾向が違います。 少し引っ込み思案で優しく響いていた音は、あれがDSDの音の良さなのかなと思っていたんですけども。。。
なんじゃこりゃ!? という具合の鮮烈な音に変わりました。
実はSABRE9018Q2Cの制約で384kHzのI2S入力時には、約74MHz以上というクロックを入れなければ 8倍の内蔵デジフィルの動作条件を満たせません。 SabreBerry32搭載のクロックは高い方で49MHz。 ということで、デジフィルバイパスモード(つまりNOS)で使用してみました。
DSDからPCMに一度は変換していますが、その後はDAC内蔵のFIRフィルタもバイパスするという荒業のためでしょうか。 こんなストレートで爽やか、そしてベールが一切かかっていない音をDSD音源で聴いたことがありませんでした。
好みの分かれる音かもしれませんが、選択肢のひとつとして面白いと思います。
コンパイルにはかなりの時間がかかるので、バイナリで提供できればと考えています。
352.8kHz / 348kHz 再生は必要なの?
実際にはDXDで録音されたものがそのまま聞ける(配信される)ケースは稀だと思います。
DSDも5.6MHz、11.2MHzと周波数の高いデータがごく一部で配信されていますが、DSD配信自体がPCMにとって代わるほど有利な訳でもありません。 多くのDSD配信が、PCMで編集(ミキシング、マスタリング)した後、DSDに変換、もしくは、一旦アナログに戻したあとDSDレコーダーで再録音されたものであるという事も忘れてはいけません。 (2Lでは明確にPCMからDSDに変換していると書いています)
ということで、348kHzをそのまま再生できないからといって、普段、音楽を楽しむ上で不都合があるのかと言うと、そんなことはないと思います。
今のところ、ちょっとした興味を満足させるための「調味料」的存在なのかもしれません。
にほんブログ村
ブログランキングに参加中です。 めざせ1位!
もしよろしければ「ぽちっと」お願いします。
« 気絶してしまいました。 ステレオ誌付録メタルコーンスピーカーの誘惑 | トップページ | (続) I2S-DACを348kHzで駆動すると、どういうメリットがあるの? »
「Raspberry Pi」カテゴリの記事
- OSC Tokyoの準備で「IGZO 7インチ」1920x1200 LCDを動かそうとしたら・・・(2024.03.08)
- Raspberry Pi5 が来た!(2024.02.26)
- Open Audio Lab.さんのPi4用ラズパイケース(2024.02.20)
- Raspberry Pi 5(2023.10.02)
- 来年からRapberryPiの供給が改善されるらしい。(2022.12.17)
コメント
« 気絶してしまいました。 ステレオ誌付録メタルコーンスピーカーの誘惑 | トップページ | (続) I2S-DACを348kHzで駆動すると、どういうメリットがあるの? »
たかじんさん はじめまして。
takobozuと申します。
私の環境でうまくいくかどうかを試させていただきました。
結果は、残念ながらサーというバックグランドノイズが出続けます。
試しました環境は以下のとおりです。
(1)kernel 4.6.6にalsaの上記パッチを当てコンパイルしました。
(2)mpd-0.19.17にlintweakerさんのdsdパッチを当てコンパイル
しました。
(3)ハードはrpi2B+usb-dac(combo384+pcm1795dac)
kernelはlowlatencyでコンパイルしております。
hw_paramsは上記表示と同じ結果ですのでパッチはしっかり
当たっていると思います。
上記記事とは環境が違いますので当然の結果ですかね。
うーん、たかじんさんのおっしゃるいい音が聴きたかったなあ。
kernelのalsaモジュールがそのままでは、384khz等が定義されてい
ないとは知りませんでしたので今回の記事は勉強になりました。
最後になりましたがお礼申し上げます。
投稿: | 2016年8月13日 (土) 15時45分
上記のノイズですが、352.8khzをcombo384は受けられても
pcm1795が受けられないんからなんでしょうか。
今さら気づきました、ガックリ。
takobozu
投稿: | 2016年8月13日 (土) 17時31分
takobozuさん
確かに、PCM1795はI2S入力時は192kHzまでですね。 外部デジフィルモード(DFTH)のときは1.5MHzくらいまでのサンプリングレートで入力できます。
combo384がそのフォーマットで出せるのかは分からないですが。。。
投稿: たかじん | 2016年8月14日 (日) 00時04分
たかじんさん
記事、興味深く拝見しました。
mpdのdsd2pcmはその後にフィルター(soxやlibsamplerateなど)を使うことが前提のようで内蔵のフィルターではノイズがとりきれません。
DACがNOSだとそれ以降のシステムによってはノイズがスピーカーにまで届くかもしれません。
lightMPDの掲示板でも384K対応のDACでdsd2pcmを行うとノイズがのるという報告がありました。
最後にdsd2pcmのフィルター係数をのせますので確認してみてください。
確認は
石川高専 山田洋士 研究室ホームページ Digital Filter Design Services
(http://dsp.jpn.org/dfdesign/)
でできます。
FIRフィルターの特性計算(http://dsp.jpn.org/dfdesign/gfir/fir.shtml)を開いて
インパルス応答長に96をインパルス応答の値に下記の係数をコピペして 送信ボタンを押すと
インパルス応答
振幅特性
位相特性
群遅延特性
が表示されます。
以前、お話したかもしれませんがlightMPDではdsdを直接指定したサンプリング周波数のPCMに変換することができます。
dsd64を352.8のpcmにするときの係数は
フィルタ長 321
窓の種類 Kaiser窓
正規化遮断周波数 0.0124(35KHz)
阻止域での必要減衰量 120db
です。
石川高専のhttp://dsp.jpn.org/dfdesign/fir/mado.shtmlで上記の値を入力すると
係数を計算してくれます。
> SabreBerry32搭載のクロックは高い方で49MHz。 ということで、デジフィルバイパスモード(つまりNOS)で使用してみました。
この機能は公開されるのでしょうか?
公開されるとlightMPDのdsd2pcmの拡張が生きてくるのですが。
ps3ではsacdをpcmに変換してましたが、音はとてもよかったです。(それでsacdを買い集めることになりました)
個人的にはdsd->pcmにも可能性があると思ってます。
mpdのdsd2pcmの係数
----- ここから -----
3.130441005359396e-08,
1.244182214744588e-07,
3.423230509967409e-07,
7.410039764949091e-07,
1.319400334374195e-06,
1.930520892991082e-06,
2.166655190537392e-06,
1.249721855219005e-06,
-2.017460145032201e-06,
-9.163058931391722e-06,
-2.17407957554587e-05,
-4.07492895872535e-05,
-6.577634378272832e-05,
-9.396247155265073e-05,
-0.0001189970287491285,
-0.0001304796361231895,
-0.0001140625650874684,
-5.279407053811266e-05,
7.002968738383528e-05,
0.000266446345425276,
0.0005381636200535649,
0.0008704322683580222,
0.001226696225277855,
0.001545601648013235,
0.001742046839472948,
0.001713709169690937,
0.001353838005269448,
0.0005700762133516592,
-0.0006922187080790708,
-0.002425035959059578,
-0.004535184322001496,
-0.006828859761015335,
-0.009007905078766049,
-0.0106813877974587,
-0.01139427235000863,
-0.01067241812471033,
-0.008080250212687497,
-0.003284703416210726,
0.003883043418804416,
0.0133774746265897,
0.02490921351762261,
0.0379429484910187,
0.05172629311427257,
0.06534876523171299,
0.07782552527068175,
0.08819647126516944,
0.09562845727714668,
0.09950731974056658,
0.09950731974056658,
0.09562845727714668,
0.08819647126516944,
0.07782552527068175,
0.06534876523171299,
0.05172629311427257,
0.0379429484910187,
0.02490921351762261,
0.0133774746265897,
0.003883043418804416,
-0.003284703416210726,
-0.008080250212687497,
-0.01067241812471033,
-0.01139427235000863,
-0.0106813877974587,
-0.009007905078766049,
-0.006828859761015335,
-0.004535184322001496,
-0.002425035959059578,
-0.0006922187080790708,
0.0005700762133516592,
0.001353838005269448,
0.001713709169690937,
0.001742046839472948,
0.001545601648013235,
0.001226696225277855,
0.0008704322683580222,
0.0005381636200535649,
0.000266446345425276,
7.002968738383528e-05,
-5.279407053811266e-05,
-0.0001140625650874684,
-0.0001304796361231895,
-0.0001189970287491285,
-9.396247155265073e-05,
-6.577634378272832e-05,
-4.07492895872535e-05,
-2.17407957554587e-05,
-9.163058931391722e-06,
-2.017460145032201e-06,
1.249721855219005e-06,
2.166655190537392e-06,
1.930520892991082e-06,
1.319400334374195e-06,
7.410039764949091e-07,
3.423230509967409e-07,
1.244182214744588e-07,
3.130441005359396e-08
----- ここまで -----
投稿: digififan | 2016年8月15日 (月) 00時35分
digififan さん
とても重要、かつ、貴重なご意見ありがとうございます。
添付いただいたデジフィルの特性を見てみました。 確かにカットオフ周波数が100kHzくらいと過剰に伸びていますね。
もう少し検証してみます。 NOS設定については、近いうちにメールいたします。
投稿: たかじん | 2016年8月16日 (火) 08時18分
github/raspberrypi/linuxのカーネルソースを眺めてまして
hifiberry-dacplus.c Fixed a bug when using 352.8kHz sample rate
という修正が入っているのを発見しました。中身を見ますと
+ case 352800
となっているだけです。
それと面白いのは、この修正は本日から3日前で、4.9.y(今は4.9.56)以外にはこの修正が入っていないことです。4.11.y、4.13.yで確認しましたがこの修正はされてません。これからされるんでしょうか。
あとどうせなら、+case 384000もいれとけばいいのにとか思いました。
すいません、前置きが長くなりましたがこれが本題ではありません。
symphonic-mpdでdsdがノイズまじりになるという投稿がありその後sox very highにすればなおるよ、みたいな投稿がありました。そこでたかじんさんの本記事を思い出しまして投稿した次第です。
kenelにパッチをあてて384kHzまで再生できるようにすればsox使わなくてもいいんじゃないかと。
4.9.56ならbcm2835_i2s.cを見ますと384000の修正が加えられてますが、include sound/pcm.hとなってます。だから、本記事で書かれているhttps://patchwork.kernel.org/patch/9160203/のパッチはあてないといけないのかなあと思います。(nanopi-neo2ではそうでした)
pcm.hを見ますと、やはり192000Hzまでしかdefineされてませんので。
それで、パッチをあててビルドしなおすことを考えるわけです。
smpdのカーネルは4.9.47-rt37です。モジュール使っておられるので
(おそらく)カーネルだけ入れ替えるわけにはいきませんよね。最新の4.9.56でビルドしてもいいのですが、rt-patchが9/6以降全く更新されてません。そこで、4.9.47を使うことを考えるわけですが、github/raspberrypi/linuxはdepth 1 でcloneすると最新の4.9.56しかもってこれません。そこで、リポジトリのすべてをcloneしてgit checkout するわけなんですが、そのソースをみるとbcm2710-rpi-3-b.dtsなどbcm2710関連のdts,dtsiが見当たりません。githubのcommitsのところから4.9.47のところまでさかのぼりそのソースを見てもbcm2710関連のdts,dtsiがありません。たかじんさんは過去のバージョンにさかのぼってrpiのカーネルのビルドをされたことがおありなら、アドバイスをいただけると助かります。
あと、gccのバージョンも合わせた方がよろしいんでしょうか?
smpdでcat /proc/versionすると Linaro gcc 7.1-2017.08となってますので。
ながながとすいません。このことはパパリウスさんには内緒でお願いいたします。笑
投稿: takobozu | 2017年10月20日 (金) 15時05分
takobozu さん
Moodeも今年に3月くらいにRTカーネル版で384対応してきてましたね。
hifiberryDACでもES9023でも384kHz/352kHz出てたと思います。 おっしゃっているカーネルソース修正とは別のパッチを当てていると考えられます。 Moodeを作っている人は、かなりマニアックで、私も、このパッチにSabreberry32を合わせるのに相当調べました。
RaspberryPiのカーネルソースの384kHz対応は、まだ中途半端ですね。
Soxをvery highにすればノイズが減るというのは、なんでしょう。 Sox very highじゃないとき、何が動いているのか気になります(笑
rtパッチは、安定しているバージョンと不安定なバージョンがあるので、だれかが検証されたものを使うのがラクです。
私が過去のソースを持ってくるときは、linux/Makefile の履歴からバージョンをみてそのcommit番号で落としてきます。
ただ、同じバージョンでも沢山の人がcommitしているので確実に同じソースになるかは分かりません。
https://github.com/raspberrypi/linux/commits/rpi-4.9.y
完全なcommit履歴はこっちです。
gccバージョンは合わせた方が無難ですね。 下一桁までは。
投稿: たかじん | 2017年10月20日 (金) 18時35分
たかじんさん
ご回答ありがとうございます。
commit番号を指定して落としてきても、bcm2710関連のdts,dtsiはないんですよ。この辺の仕組みがまだよくわからないですね。
暇を見つけては、色々調べたいと思います。
投稿: takobozu | 2017年10月20日 (金) 19時38分
takobozu さん
確かにないですね。 デバイスツリーはそんなに変わる事がないと思うので、近くのバージョンのものを持ってきてコンパイルするか、
別のバージョンでコンパイルしたdtboをコピーして持ってきても動作すると思います。
投稿: たかじん | 2017年10月21日 (土) 15時26分
kernel(4.9.58)をLowlatencyでビルドしなおし、symphonic-mpdでも384kHzまで再生可能にしました。NanoPi-NEO2と基本的には同じでした。本記事にある、dsd64がmpdのdsd2pcmで352.8kHzのpcmに変換され再生されていることもhw_paramsで確認いたしました。この音が聴きたかったわけです。dsdはusb-dacでnative-dsd再生させてきましたが、それに勝とも劣らない音のように感じました。soxrはもちろん使っておりません。(smpdは初期設定のまま)
最適化オプションなし、rt化なしでこれですから、また色々いじって遊びたいと思います。
投稿: takobozu | 2017年10月28日 (土) 08時49分
追加です。
patch-4.9.47-rt37.patchがkenel 4.9.58にも一部、rejがありますが問題なくビルドも通りました。(今すでに、4.9.59ですが)
これで、hifiberry-dacを使うdacはすべて384kHzまで再生可能となりました。めでたしめでたし。(pcm5102,es9023で確認済み)
投稿: takobozu | 2017年10月28日 (土) 09時56分
takobozu さん
素晴らしい成果ですね。 soxを使わないという所もさすがです。
symphonic-mpdはカーネルのパラメータもいじっているようなので、本家で384kHz対応されるともっと面白くなるかもしれませんね。
投稿: たかじん | 2017年10月28日 (土) 09時57分
たかじんさん
パパリウスさんにはメッセージを送りました。一応、こんな感じで遊んでみました、と。最適化について教えてもらってもいいのですが、そこはお任せします。(勉強のためにやるかもしれませんが)
投稿: takobozu | 2017年10月28日 (土) 10時07分