Hifiduinoが完成したので、テストラン。
SDTrans384 =(HDMI)= BuffaloII + I/V => ヘッドフォン(面倒なので、アンプレス)
まぁ、無難に再生できる…かな、と思いましたが、1ファイルだけ雑音が混ざりますね、なんだろこれ…
当然っちゃ当然ですがLowestでもなんも問題なし(上記1ファイルを除く)。設定がどう響くかまでは未検証なので、アレですが…
気になるのが、ビットレートが刻々と変わる処。DSDのビットレートなんて変わらん筈なのに、なんでこう動的に変わるのか…不思議です…
後、HifiduinoでビットレートはCPUクロック使って演算して出してるんですが…そういやクロックシンクしてるので、CPUクロックが再生データで変わるんですよね…これが感知できないとすると…ビットレート計算して表示しても意味がないかもしれません…あと、2秒毎に計算するっていってますが、この2秒がArduino側のクロックだとすると、そっちの誤差が結構ありそうですね…I2Cでコマンド送って、その返却値を拾ってる筈だから、そこのディレイもある筈だし…というわけでいらないし潰しちゃおうかな、と思案中。
とりあえずこの設定でVolumate用のプログラムを書きますかね…
Hifiduinoでは、ES9018のDPLLのカウンタ値をI2Cで読み出しそれに比例定数の計算をして、サンプリング周波数にしています。(sampleRate関数)
返信削除MCLKが80MHzか100MHzかで定数を使い分けています。
今回はSDTransのMCLKの同期でお使いですか?それでDSD64, DSD128, DSD256を再生して同じ曲の中で表示がぶれる?
DPLLのカウンタ値そのものがぶれているのか、Aruduinoのシリアル出力表示して確かめてみてはいかがでしょう?
ところで、SPDIF_AutodetectをOFFにすることで1bit ConsortiumのWSDファイルもSPDIFと誤認識することなく再生できるようになりましたか?
返信削除SDTransのクロックを使っての同期再生時ですね。DSD64再生中に、同一の曲中でふらふらとビットレートが動いていました。I2Cでカウンタ参照に行くタイミングの問題かしら?とか思いつつ。
返信削除((Reg31-28の値) * Fcrystal)/2^32 でふらつく要素があるとしたら、レジスタの値くらいですよねぇ、とか思いつつ(FcrystalはHifiduinoでは定数ですし)。 I2Cの値を呼んでみますか。
現状うまく再生できてない曲は1曲だけ、になりました。この1曲がどういう経緯で手元にあるのかは確認中です(元データだったのか、なんか手を加えたのか、等)。DPLLとか変えてもノイズが載るのは変わらなかったので、なんだろなぁ、と。
ちなみに、添付写真をみると、上が 39041 で、下が 39043 になってるのがわかります。この時点で2ズレ。実際は100の桁までずれてる例を見かけたので、かなりのズレがあるなぁ、というのが感想です。
返信削除コード自体の定数は80MHz、実質のクロックは22.5792MHz*4=90.3MHz、39000*(80/90.3)=34551…ってことで…
DSD64のサンプル周波数は2.8MHz/1bitで、これを8bitに丸めたとして350kHzってことは、まぁ合ってる?(少し低い?)のかな…データ落ちしてないだろうなぁ、と考えつつ