SPI通信追加

今までは、ZYBOにつなげるDAC基板を、設定の不要な “PCM1794A” 基板であると「デバイス・ツリー」に記述することで、実際には”PCM1792A”基板を接続しているにもかかわらず、ZYNQにSPIコントローラを実装しないで済ませていました。SPIとは、DAC ICなどのレジスタ等への通信用バスの一方式です。

DSD対応化にあたって、PCM1792Aの制御 (設定) が不可欠になりますので、今回、ZYNQにSPIコントローラを実装しました。実装しました、といっても、これはもともとZYNQのPS部に組み込まれた機能をハード的に有効にするだけで、回路設計が必要なわけではありません。とはいっても、FPGA設計ツールを立ち上げて回路の再構築をし、回路情報データを再度生成してLinuxの起動時に必要な”BOOT.bin” を作り直す、といったような作業は必要になります。その際にはFPGA設計ツールだけではなく、(Xilinxの) SDKも必要になります。

ZYNQにSPIコントローラを実装して、ZYBOのデバイスツリーからPCM1794Aを削除し、SPIコントローラ直下に新たにPCM1792Aを追加しました。組み込みLinuxはいわゆるPlug & Playではないので、その昔、MS-DOS PCのBIOS設定でメモリ領域を指定してアダプタ・カードを追加していたようなことを、テキスト (デバイス・ツリー) を書いて設定ファイルにし、Linuxブート用のバイナリ一式に含めるという形で、設計者は同様の作業をしなければなりません。

XilinxのWikiによると、ZYNQに組み込まれたSPIコントローラはケイデンス (ご同業の方でしたらご存知の会社ですね) のIPだということですので、Linuxカーネルのブート時に同社のデバイス・ドライバがロードされるようにデバイス・ツリーに記載しています。

再生ソフトが”Play”を開始するタイミングで毎回ZYBO(ZYNQ)からSPI通信で設定データが飛んできます。PCMだけなら不要な設定といえるもので、信号フォーマットがI2SかRJ(右詰)か、そしてそれらの場合にビット数が32(24)か16か、をチェックして切り替え設定をしているだけです。これらはダイナミックに変更する必要がないものといえますので、ソースのこのあたりを改造して、このPCM1792A用のLinuxドライバをDSD対応させてみるつもりです。

もっとも、その前に、今度こそ本当にARMのAXIバス対応DSDコントローラを設計しないといけません。

今のところ、ZYBO上でMPDが普通に動作しています。ちゃんと、PLLによらず発振器によるクロックで動作するようにしましたので、音質的にも、精神衛生上もGoodです。

PCMはできた

ZYBO基板向けのI2S-DAI-DAC基板が無事に動きました。

DAC基板側に2つの発振器を載せていて、再生するファイルのサンプリング周波数が44.1kHzの倍数か、48kHzの倍数かに応じて2つの発振器出力(22.5792MHz/24.576MHz)のイネーブル・ディセーブルを切り替えてZYBO側のI2Sコントローラ回路と、DACの双方に供給するというものです。

当面、PCM信号再生ならMPDからこの「出力先」へ信号を流して楽しむことができそうです。

次のステップは、ZYBOに搭載されたZYNQのAXIバスにぶら下がる形のDSDコントローラをインプリメントし、I2S-DAI-DAC基板にDSDファイルも出力できるようにすることです。

ところで、ZYBO上でこのZYNQプロセッサに繋がっている「カニ」さんは”realtek,RTL8211E”です。きちんと速度を検証していませんが、USDA_MINI基板をつないで、nfsマウントしたQNAPのTS119からDSD11.2MHzのファイルを30分連続で再生したところ、幸運にも音飛びが気になるようなことはありませんでした。ギガビットのおかげ?

先を越されました

先ずは実用的な状態でLinux のUSB Native 転送の動作確認をしようと思い、ZYBOにMPDを導入しました。https://github.com/lintweaker/mpd-dsd-018

ZYBOで同じような事をしていて、SDカードイメージを公開しているケースが見あたりませんでしたので、自分でソースファイルからクロスコンパイルしてZYNQ (ARM) 用 のMPDを作りました。FLACや各種AUDIOファイルアクセス用のライブラリも仕方なく全てソースからARM用にビルドしました。

まだシリアルコンソールから操作しないとIPアドレスの設定やSDカードのマウントなどができませんが、とりあえずMPODからSDカード内のFLACファイルやDSDファイルを選択して再生することができるようになりました。

ZYNQのUSBは、USB-シリアル変換用と、USB On-The-Go の2通り搭載していて、USBDACはOn-The-Goの方につなぎます。ですから、On-The-GoケーブルでつないでおかないとHOSTモードにならず、USBDACを認識しません。On-The-Goケーブルをつないでおけば、きちんとPnP動作をしてくれます。

予想通り、DSD Native転送になっています。ここでいうNativeというのは、DSD-PCM変換された信号ではなくてオリジナルのDSD信号を転送する、という次元の話ではなく、USBを使ったDSD転送において、DoP方式ではなくDSDのために定義された転送モードで送り出す、という意味です。

上のキャプチャはDSD256のファイルを転送中のUSBアナライザの画面です。1uフレーム期間(125us)に平均して352.8バイトのデータをUSDA_MINI基板へ送り込んでいます。

重要なのは、DSD256に対応できるということよりも、DSD64/128の場合も含めて、DoP転送よりも転送に必要な負荷が少ないことが期待できる、ということになります。

ただ、DoP転送、Native転送にかかわらずDSD転送の場合には少し問題があります。というのは、再生開始直後に、少しの期間”ゼロ”を送ってくるため、再生の頭でノイズが出てしまいます。ゼロではなくて”0x96,0x69,0x96,0x69,….” などを送ってくれれば良いのですが、そうはなっていません。

0x96,0x69,…ならば、1bitに展開すると”10010110….”といった1bit列になり、フィルタするとDCになりますが、”0x0,0x0,0x0,0x0,…”を送られると、bit列は”00000000….”となり、フィルタすると負のフルスケールに張り付いた値になりますので、どうしても再生の頭でノイズになってしまいます。

再生の頭だけはアンプのボリュームで回避して、アルバム単位で聴いていれば実用上問題はないのですが。Linuxのソースのどこを修正すればよいのかまだ調べていません。

ちなみに、lightMPDはすでにBBB用にDSD Native転送対応のバージョンがUPされています(先を越されました:笑)。対象のDDCをお持ちの方はお試しになる価値はあると思います。UDA2はうまく動作するか未確認なので多少不安ですが、USDA_MINIではとりあえずNative転送で動作しています。

USBなら本当はraspberry pi 2で動作すればクアッドコアですし一番コスパが高くて良さそうなのですが、何事も思った通りには行かないものです・・・。それともDoPはNGでもNativeはOKということなのでしょうか?

さて、 ひとまずUSBは置いておいて、I2Sを試してからAXIバスにぶら下がるDSDインターフェース設計を始めたいと考えています。

おまけ

前回の記事で、最近の新しいLinuxカーネルには、「一部のUSBオーディオ基板向けを想定して拡張フォーマットが新たに用意されている」 という旨を述べました。

再生しようとする信号のフォーマットを、ALSAアプリと出力先のデバイス・ドライバとの間で教え合うためのフラグのようなものなのですが、”SNDRV_PCM_FMTBIT_DSD_U32_LE” という「もの」と、”SNDRV_PCM_FMTBIT_DSD_U32_BE” といった「もの」などが追加されているのです。

そこで、とりあえず前者をI2Sコントローラ用に採用して定義しましたが、実は、「一部のUSBオーディオ基板」 にはUDA2基板、USBDAC基板やUSDA_MINI基板を含めることができることに気がつきました。

カーネル・ソースの、/sound/usb/quirks.c のコードに下図の赤丸で囲んだ記述を追加することで、対応サンプリング周波数がDSD256にまで拡張され、同じサンプリング周波数のファイルを再生するためのCPUの仕事量が2/3に減り、かつ16bitにパックしたDSD信号にDoPマーカを付け足すという不毛な仕事からCPUが解放されます。 (すみません、256対応は実験上は未確認です) 。

quirks.c に該当する関数がない場合には、古いソースだと考えられます。また、連動してALSAのライブラリも新しいものにする必要があります・・・。 どうせなので最新版に・・・。

ZYBOのUSBでテストアプリを作って確認できました。他のARM系のボードでもおそらく大丈夫だと思います。BBBやRas-Piでもいけるのではないかと思います。もちろんパソコン上の各種ディストリビューションでも同様に行けるのではないでしょうか。

カーネルの再コンパイルをご自身でやらなければならないので、決してお勧めするわけではありませんが・・・。

もしかしたら、ですが、BBBやRas-Pi上のMPD再生で、音切れ対策に、ひょっとしたらですが、多少効果があるかもしれません。ネットワーク上のトラフィックに変化はないはずですが、USBバス上に送り出す時の負荷は減るはずですので・・・。

※動作を保証するものではございませんので、どうかご了承をお願いします。

目処が立つ

前回予想したとおり、このI2Sコントローラに入力するオーディオ系クロックを12.288MHzから倍の24.576MHzに変更するだけで、つまりZYNQプロセッサのペリフェラル・クロックのPLLコンフィギュレーションを変えるだけで、I2Sコントローラの回路やデバイス・ドライバを変更することなく、192kHzまでのサンプリング周波数に対応できることが動作確認できました。

気を良くして、サンプリング周波数が48kHzの倍数 (あるいはやろうと思えば44.1kHzの倍数) にしか対応できないという現行の装置の限界を破るべく、再生オーディオファイルのサンプリング周波数に応じて、このシステムクロックの周波数を、2つのクリスタル発振器、24.576MHzか22.5792MHzのいずれかを切り替えて供給できるようにI2Sコントローラと、そのデバイス・ドライバを改造してみました。

当然、ALSA準拠のアプリ再生で切り替わるようにしてあります。まずはI2Sコントローラに発振器切り換え用のレジスタを追加しました。そして、アプリからALSA経由で再生サンプリング周波数のパラメータを受け取ったデバイス・ドライバが、その追加したレジスタに値をセットすると改造I2Sコントローラが発振器の切り替えセレクタを制御する、という寸法です。なのでデバイス・ドライバにも変更を入れました。

これで、UDAなどと同じように、愚直に原始的に、ではありますが、ピュア・オーディオ品質のクロックが使えるI2Sコントローラができあがりました。 そういうことで必然的にDAC基板も作らざるを得なくなります。

クリスタル発振器はDACが載った基板上に2個置かれることになります。選択されたクロックがDAC ICとZYBOに供給されます。

DAC ICとしてPCM1792Aを載せましたので、CPU(ARM)から設定ができるようになる (する) 予定です。LinuxにはPCM1792Aのデバイス・ドライバも入っていますので、こちらも改造して使うことになると思います。

改造が必要になる理由はDSD対応です。今回の検討で、I2SコントローラにDSD対応の機能を追加すれば普通にNative DSD再生ができるはずであることを確認しました。

最近のALSAライブラリには、”SND_PCM_FORMAT_DSD_U32_LE” というフォーマットが追加されています。調べてみると、元来、一部のUSBオーディオ基板向けに新たに用意された拡張フォーマットのようですが、自作のALSAアプリからARMのAXIバスにぶら下がる形のこのI2Sコントローラに対しても、再生時にデバイス・ドライバ経由でこのフォーマット情報を伝えることが可能であると実験で確認しました。

つまり、アプリが再生開始する直前に、再生信号のフォーマット情報 として “SND_PCM_FORMAT_S32_LE” を送ってくればI2Sモードに、”SND_PCM_FORMAT_DSD_U32_LE” を送ってくればDSDモードへと、I2Sコントローラの機能が切り替わるようにI2Sコントローラのロジック回路とデバイス・ドライバを作りこんでおけば良いというわけです。

おそらくは、最近のMPDではこのフォーマット、”SND_PCM_FORMAT_DSD_U32_LE” がサポートされているはずですので、ZYBOにも組み込んであげることで、出力対象がUSBアダプタではありませんが、Native DSD再生ができるようになるものと思われます。

ちなみにですが、ZYNQプロセッサのベンダであるxilinxや、あるいはZYBO基板をリリースしているDigilentが公開しているramdiskにはALSAのライブラリは組み込まれていませんので、自分で最新版のソースを引っ張ってきて、ノートPCにインストールしたLinux上でクロス・コンパイルして突っ込みました。

ALSAアプリにしても、デバイス・ドライバにしても、もちろんOS本体のカーネルにしても、すべてクロス・コンパイルということになってしまうのは同じですが・・・。

i2sコントローラ改造とDAC基板

このi2sコントローラの構成は、再生部のみですが前回のブログにブロック図を書き起こして掲載しました。

バスにぶら下がる構造のこの手のデバイスは、大抵が、バス経由(ARMの場合はAXIバス)でメインメモリ内のデータをそのデバイス内のFIFOに突っ込めるだけ突っ込んでおいて、データの抜き出し側で一定速で読み出すという方式になっています。この場合、FIFOにはバスのクロックに同期してデータを書き込み、読み出しはオーディオのクロック(22.5792/24.576MHz)に同期して行う、という事になります。

PC用のPCIバスに挿して使用するサウンドカードは、カード上のコントローラがマスタとなり、(自身で主導権を握って)メインメモリからデータを引っ張ってくるものがほとんどで、CPUはデータ転送に関わらないで済むように設計されています。それが合理的な考え方で、その分CPUが他の仕事に専念できるからです。CPUはファイルからオーディオデータを読み込み、必要に応じて各種デコードなどを行ってメモリ上に置いておく、という動作のみが必要になります。

それに対し、このi2sコントローラはマスタになるタイプではなく、あくまでもスレーブデバイスですから、メインメモリのデータは、他者に転送してもらわなければなりません。

通常はその役割をCPUが負うことになり、何もしなければデータ転送だけでCPUが忙しくなってしまうことになります。CPUは、FIFOが空いている限り(FIFOの状況を逐一チェックしながら、満杯でなくなれば)データをメモリから読んでFIFOに書き込むというプロセスを繰り返します。

これではまずいので、そこに登場するのがDMA(ダイレクト・メモリ・アクセス)コントローラ、略してDMACということになります。

あらかじめデータの転送元アドレスと転送先を設定しておけば、i2sコントローラから転送要求が伝わるたびに(1発パルスを受け取るたびに)、メモリからFIFOにデータを自動的に転送するようになっていて、CPUに替わってデータ転送の仕事を行ってくれるのがこのDMACということになります。

i2sコントローラは、自身のFIFOが満杯でない限り転送要求のパルスをDMACへ繰り返し出力します。これは簡単なロジック回路だけ構成することが可能で、こういう仕組みによって、i2sコントローラがマスタにならなくてもCPU負荷を上げることなくデータ転送を行うことができるようにしています。

どちらかというと、二昔前のISAバスのサウンドカードに近い動作方式ですが、ISAバスは1度に16bitのデータしか転送できないのに対してこちら(AXIバス)は32bit分転送できますし、バスのクロックに至っては、ISAバスが数MHzなのに対し、このi2sでは100MHzにしており、PCIバス比では3倍のクロック速度になっています。という事で性能的には段違いといえます。

さて、このi2sコントローラの回路とデバイスドライバを少し改変して上の図のようなDAC基板をつなげるようにしたいと思います。本来、発振器はZYBOのような基板上にあるのが筋だと言う感じもしますが、DAC基板側に置くことになります。

時間を見て、先ずはPCMだけでも192kHzまで普通に対応できるように進めようと思います。

つづく、かな?

I2S controller on ZYBO

前回の記事ではUSDA基板をZYBOにつないでALSA経由で再生実験をしました。

ZYBOの中心となるZYNQというSoCチップは、「PS」 部と「PL」部とからなり、「PS」部にはSoCチップには必須?の汎用外部バス(USBやLAN)などがすでにハードマクロで作りこまれています。「PL」部は現状のFPGAと同様に、設計者が実現したい機能をロジック回路として自由に作りこむことができるようになっています。

ですから、ARM社のAXIバス(ZYNQもご他聞に漏れずARMのSoCです)に繋がる様にI2Sのインターフェース回路を設計すれば、ドライバーソフトも用意する必要はありますが、OSから制御することができるものを作り込めるのです。Linuxを使ってALSA経由で動かせればソフト開発の負荷は下がるでしょう・・・。

ところで、ご存知のアナログデバイス社は、自社の販売するオーディオコーデックなどのデバイスを接続してもらうことを期待して?、VHDLというハードウェア記述言語でコーディングされたI2Sコントローラーの設計データを公開しています。

これを、ZYNQの製造メーカーであるXilinxの開発ツールを使って「PL」部に組み込むことで、容易にI2SコントローラーとARM(CPU)をつなげることができます。

ただし、最初から設計データがあるとは言っても、やはりあらかじめ論理シミュレーションをして動作の様子等を調査しておかないと自信を持って大本につなぐことはできません。

そこで、再生部分のみではありますが、ソースコードを読み、実際にVHDLシミュレータにかけて動作を調べるといったリバースエンジニアリングをしました。その過程でレジスタマップも書き起こしてしまいます。アナログデバイス社から同時に公開されているデバイスドライバーのソースコードの読み込みも、レジスタマップを理解するための助けになります。

オリジナルの設計ではどうやら96kHzまでの対応に限定されますが、ALSA経由でこのモジュールを動かすことができました。次のステップとして、このI2Sコントローラーを192kHz対応に改造し、マスタークロック(今現在でも外には出ています)関係を、22.5792/24.576MHz系で発振器を切り替えて使用できるような構成に変更しようと考えています。

USDA基板の時と同様に、aplayを使っての再生まで確認できました(上記のブートメッセージは再生前です・・・)。

2個の発振器の載ったDAC基板、例によって人気のない?PCM1792Aあたりを搭載し、DSD再生も可能なようにしようかなと思案中です。

I2Sコントローラ、デバイスドライバともに改変が必要になりますが、やろうと思えばできてしまうのが、このZYNQのようなデバイスの面白いところです。

以下、5/26追記:

ZYBOのシステムのデフォルト・コンフィグレーションではオーディオ系のシステムクロックが12.288MHzに設定されています。これは元々が50MHzの水晶発振クロックから、何回かPLLででっち上げられたクロックで、実は周波数も正確な12.288MHzではなく、ある程度偏差のあるクロックです。こういったSoCがらみの基板でオーディオクロックを得るためにはありがちな仕組みではありますが・・・。

少し脱線しましたが、このオーディオ用の大元のクロックを24.576MHzに設定すれば、I2Sコントーラのロジック回路も、そしてデバイスドライバーも変更することなく192kHzまで対応できるような気がしています。デバイスドライバのソースを読んでいたらそのような気がしてきました。

追って確かめてみようと思います。

ZYNQ

各社のFPGAはプロセスをはじめとして、機能・性能が向上しており、Xilinxのデバイスも進化しております。ボヤッとしているとどんどん取り残されてしまいます。

Xilinxは、Arm Cortex-A9のデュアルコアにDDRメモリインターフェース、そしてUSB、Gb EthernetやSDカードなどの周辺コントローラを組み合わせた、言ってみればラズパイに搭載されたブロードコムのプロセッサみたいなLSI、に、FPGAを組み合わせて1チップにしたZYNQというデバイスを出しています。

要するに、市販のプロセッサの物足りない部分に自作の大規模ロジックを組み合わせて使えますよ、という趣旨のデバイスなのです。

で、このZYNQというデバイスを積んだ評価ボードであるZYBOという基板が市販されており、私も1年ほど前に入手しておりまして、まずいことに長いこと死蔵していました。最近では秋月でも売っているんですね。敷居が下がったものです。

ラズパイB2は確かにすごいと思うのですが、私としては「オリジナルな回路で付加価値を!」、といった考え方を貫いていないとまずいですので、重い腰を上げてこの基板に取り組み始めました。はっきり言って面白いです。

仕事の用途ですと、画像に絡ませるといった方面のご要求が多そうですが、ここに書くからにはオーディオ用途でないとまずいわけで、まずはFPGA部の回路的にはZYBOのリファレンスデザインを使い、Linuxを載せてとにかく動かしてみました。

この基板もSDカードにファイル一式を入れておいてブートさせる仕組みですが、こういった組み込み開発ものは、OSを立ち上げるまでが第一の関門で、例外なく苦労させてくれます。

オーディオ的には、まずはLinux上のALSA経由で、SDに格納したWAVファイルを、ZYBOとUSB接続したUSDA_MINI基板から出力してみました。。

実験、という以外は特に面白くもないですね。おそらくMPDみたいなものを載せてもう少し実用的なものは作れるかもしれません。

FPGA部にまともなI2Sのコントローラ(24/192とDSD128くらいまで入出力できて、信号のサンプリング周波数(44.1kHz/48kHz)の倍数にあわせた水晶発振器クロックを外から入れられる)を作りこみ、プロセッサクロックの逓倍×分周に起因する、ジッタや大きな周波数偏差のない水晶発振クロックでI2Sから録音・再生できるようなものを作りたいと思っています。もちろんMCLKもきちんと出力して・・・。

また、ソフト的には、MPDよりもDLNAを実装したいな~、という想いがあります。

 

 

活動状況

大変ご無沙汰しております。消費税率の年度途中変更等による確定申告の煩わしさや、アベクロ景気?の影響なのか本業が忙しくて更新をすっかりサボってしまいました。死亡説が出る前に兎に角何か記事を書かなくては・・・、とずっと思っておりました。

昨年末に、割と自宅から近いところに昭和の香りを色濃く残す喫茶店を発見しました。店主がクラシック音楽好きで、棚にはおびただしい枚数のLPやCDが収納され、店内の装置で演奏されています。

これらの装置が昭和末期の代物たちでして、なかでもSANSUIのアンプ、AU-X707の黒光りする様が異彩を放っておりました。初めて店内に入ったときに、その黒光りする物体を凝視してしまったが最後、あまりの懐かしさに当方もSANSUIを自宅に迎え入れたくなってしまいました。

しばらくの間ヤフオクの画面と格闘し、手始めに?「動作確認済」という触れ込みの、ランクAと出品者が謳うAU-X607を落としてしまいました。

このシリーズはα-Xバランスサーキットという回路が売りで、チャンネル毎にプラスとマイナスのアンプを持っていて、SPをプラスとマイナスの両側からドライブするという構成になっています。また、入り口から出口までAC結合を持たない完全DCアンプです。個性的ですよね。さらに、電源トランスには中点タップが無く、整流ノイズがアースへ流れ込まないとかどうとか、当時謳われていたような気がします。

送られてきたブツをとりあえず確認してみたところ、確かに音は出ていましたが、30年近く昔の電気製品ですので、念のため完全オーバーホールを敢行することにしました。

具体的にはケミコンは問答無用で交換し、酸化して足が黒くなっているTrも交換する。溶剤系の接着剤が染み出て腐食した抵抗、さらに出力リレーも新品交換することにしました。リレーも、オリジナルのOMRON互換品で、今は無き富士通高見澤製の貴重な金貼り接点タイプを保有していますので問題ありません。

ケミコンはオリジナルはニッケミのAWDという音響用が多用されていますが、すべて同じニッケミの新品KMGに交換します。Trもストックしてある同一銘柄品が使えました。

完全オーバーホールなので写真のように基板は外してメンテします。

実は基板を外す以前に、視聴の際、念のためにオフセット調整を確認しておこうと信号を当たっているときに、あろう事か終段のパワトラを飛ばしてしまいました。例によって、バチン!と、ものすごい音がしました。調整中ということで、Harbeth君を繋いでいないでよかったです。

困ったことに同じ型番で同じHFEランクのデバイスが入手できませんでしたので、上位機種であるAU-X707に搭載されているものを使うことにしました。X607とX707のメインアンプは、基板自体はほとんど同一仕様ですのでなんとかなるでしょう。幸い秋月電子でリーズナブルな価格で入手できます。当然8個すべてを交換することになります。

この時代の製品は、コネクタが一般的ではなかったので基板の取り回しが大変で、色々苦労しましたが(写真では示していませんが)、サービスマニュアルがありますのでなんとかなります。

無事にSANSUIサウンドを奏でてくれます・・・。・・・(と言ってもそこはやっぱり \79,800のアンプ。後に上位機種のジャンクを再入手することに・・・)

こうして昭和末期のサウンドを堪能していると、ソースもやはり当時の機器やデバイスをつないで聴きたくなってくるものです。

当時はようやくCDがソースの主流になってくるかどうかという時期で、なんとなくTDA1541AというPhilipsの16bitDACを使ったCDプレーヤーを繋ぎたくなります。

とはいっても世はハイレゾの時代!24bitのソースをわざわざ16bitに切り捨ててしまうのも抵抗があります。

唐突な話ですが、KORGのAudioGateというソフトは、フォーマット変換の際にディザをかける事ができます。そのディザですが、一般的なTPDFのほかに、KORG AQUAというタイプが選択可能で、これが具合が宜しいのではないかと思っています。

適当なソフトでたとえば1kHzの正弦波信号を24bit/96kHzのフォーマットで作成し、AudioGatede で上記のディザをかけて16bit/192kHzに変換します。

できあがったそれぞれの16bit/192kHzのファイルをFFTにかけてみます。いつものWaveSpectraです。写真上がTPDFディザで、下がAQUAです。

AQUAってデルタシグマですよね。可聴帯域に16bit分を超越する量子化方向の情報を、16bit中に保持していることが期待できそうです。

誤解を恐れずに書けば、スーパービットマッピング以上、DSD未満、といったイメージではないでしょうか。

これなら、24bitのハイレゾファイルを16bitの176.4/192kHzにAQUAで変換し、TDA1541AのNOS DACへそのままのサンプリング周波数で送り込めば、そこそこのクオリティでハイレゾ再生が楽しめるのではないでしょうか。BeatlesのUSBあたりを楽しむのに最適なシステムのような気さえします。

物入れを漁っていたらこんな基板が出てきました。そのうちに試してみようと思っています。次、いつ時間が取れるかわかりませんが・・・。TDA1541AのNOS DACをお持ちの方で、興味のある方は試してみてはいかがでしょうか。

ただ、TDA1541Aの場合、I2S接続するには16bitスロットで接続する必要があったような記憶があります。その辺で引っかかることが多いかもしれません・・・。

謹賀新年。遅くなりましたが、今年もよろしくお願いします。

遅ればせながら、あけましておめでとうございます。本年もよろしくお願いします。

皆様は今年の聴きはじめはお済みになられましたでしょうか。実は当方は未だメインの装置の電源を入れておりませんでした。今朝から電源を入れましたので、本日が聴きはじめになると思います。最近ペンタトーンからリリースされたばかりの、小澤征爾さんのドイツグラモフォン原版のリマスターSACDから逝ってみようと思っています。

昨日は半日かけてFET一袋分のIdssを測定して選別をしていました。歳のせいか?同じ姿勢で作業を続けていると体中が固まってくるような感じがします(笑

老眼もさらに進みました。このままチップ部品の半田付けなんぞを続けていると眼の寿命を早めないだろうかと心配になってきました(笑

皆様もどうかくれぐれもご自愛ください。