SANYO LC7881 DAC その１０ (PIC32MX編)

その９の続き。

データを一時保管するバッファの構造を変えたりしたが、
44.1kHz再生でノイズが消えずに１週間経ってしまった。

最終的にはUSBHandleGetLengthの使い方が間違って
いた様だ。正しい手順を書いておく。

初期化部分USBCBInitEPで、まずUSBHandleBusyで受信
できるか確認する。受信可能になればUSBRxOnePacketの
受信サイズを考えられる最大サイズを指定して呼び出す。
つまり48kHzで49サンプル分ｘ4byte=196を指定。

メインのループUSBAudioTasks内にて、USBHandleBusyで
できるか確認する。受信可能になればUSBHandleGetLength
を呼び出し、前回受信したサイズを取得する。その後で
USBRxOnePacketの受信サイズを考えられる最大サイズを
指定して呼び出す。以降繰り返し。

つまり受信サイズは次回USBHandleBusyで受信可能になる
まで取得できないと考えられるので注意が必要だ。メーカー
サンプルを修正するなら一部48のところを49に修正するのを
忘れない様に。

その７のusb_descriptors.cについて修正した方が良さそうな
部分があったので、その７に追記しておいた。

SANYO LC7881 DAC その９ (PIC32MX編)

SANYO LC7881への変換を検討せずに、数日かけてPIC32MXで
44.1kHzを出そうとするとノイズが入る原因について調べていた。
Micorochip社のサンプルプログラムは48kHzと32kHzしか対応
してなく44.1kHzが出せない。他にも挑戦した人が居る様だが、
うまく動作しなかった様だ。

Micorochip USB Digital Audio Accessory Board(DM320014)の
回路とサンプルプログラムを使ってみようと思う人の為に私の実験
結果を書いておく。

USBからのデータ読み込みは”USBRxOnePacket”で行っているが、
サンプルプログラムでは周波数による固定値になっている。これを
”USBRxOnePacket”の前に”USBHandleGetLength”で読む込むべき
サイズを取得すれば理論上44.1KHzでも全データを読み込む事が
できる。

しかし、実際にプログラムを修正した結果”USBRxOnePacket”を
修正すると処理時間が増えてしまい、パケットを処理中に割り込み
入った様な場合などに次のパケットを受信してしまうと考えられる
状態になった。つまり、処理が間に合っていない。

私もプログラムの大部分を調べてプログラムのスリム化や高速化を
行ってかなり良くはなったが、現状でノイズが入ったり止まったり
するのでもう少し改良が必要な状態だ。

結論はサンプルプログラムそのままでは、無料のC32コンパイラは
スピード不足で動作しない可能性が高い。現行のXC32でコンパイル
できる様に変更し有料オプションを使って高速化するか、CPUの
クロックを現在の40MHzから50MHzに設定変更するか、パケット
処理プログラムを高速化させる等の対策が必要と考えられる。

あと参考に書くと、Micorochip USB Digital Audio Accessory
Board(DM320014)で使用してるPICはPIC32MX250F128Bだが、
録音部分を削除してheapの量を減らすとPIC32MX220F032Bでも
使用可能だった。

SANYO LC7881 DAC その８ (PIC32MX編)

その５で書いたボリュームとミュートが使えない件だが、
usb_descriptors.cを修正してみた。

修正したところ、DACの回路側でボリュームとミュートを
使用せずにコントロールができる様になった。

私の場合はプログラムは公開しない方だが、この部分は
参考になるかもしれないから書いておく。

//----------------------------------------------------------------
// usb_descriptors.c configDescriptor1
//----------------------------------------------------------------
ROM BYTE configDescriptor1[] ={
    0x09,0x02,0x67,0x00,0x02,0x01,0x00,_DEFAULT | _SELF,0xFA,
        0x09,0x04,0x00,0x00,0x00,0x01,0x01,0x00,0x00,
            0x09,0x24,0x01,0x00,0x01,0x1c,0x00,0x01,0x01,
            0x0C,0x24,0x02,0x01,0x01,0x01,0x00,0x02,0x03,0x00,0x00,0x00,
            0x09,0x24,0x03,0x02,0x01,0x03,0x00,0x01,0x00,
    0x09,0x04,0x01,0x00,0x00,0x01,0x02,0x00,0x00,
    0x09,0x04,0x01,0x01,0x01,0x01,0x02,0x00,0x00,
        0x07,0x24,0x01,0x01,0x01,0x01,0x00,
        0x0E,0x24,0x02,0x01,0x02,0x02,0x10,0x02,0x80,0xBB,0x00,0x00,0x7D,0x00,
        0x09,0x05,0x01,0x09,AUDIO_MAX_SAMPLES * sizeof (AUDIO_PLAY_SAMPLE ),0x00,0x01,0x00,0x00,
            0x07,0x25,0x01,0x01,0x00,0x00,0x00,
};
//----------------------------------------------------------------

2021/04/29追記
上記赤の0x01,0x03部分は0x02,0x06の方が良いかもしれない。

SANYO LC7881 DAC その７ (CPLD編)

信号のタイミングとかをチェックして回路を修正した。

出力側が48fs 右詰めなので、74165がもう１つ必要だった。
LRCKをずらす74164は7474にすると反転Qが使えるので
7486の段数が１つ減る。74165のビットシフトのクロックは
半クロック遅れるので信号を反転させる必要がありそうだ。

ここまで考えてから書くのもなんだが、この回路を作っても
汎用のUSB I2S変換で384fsを出せる品物が無いだろうから
PIC32MX専用回路になる。そもそも無いからPIC32MXを使う
事にしたのだし。(SPDIFから変換する方法はあるかもしれ
ないが・・・。)

PIC32MX専用なら、ここまでしなくてもPIC32MX側の設定を
変更すればもっと簡単な回路で済むだろう。

と言う事で、この回路は没にして別の方法を検討する事にする。

SANYO LC7881 DAC その６ (CPLD編)

VHDLを書く前に、どんな回路なら動きそうか考えた。

その２で作った図は64fs 16bit右詰めからの変換だったが、
今回は64fs 32bit I2Sを48fs 16bit 右詰めに変換になる。

とりあえず上図の様に考えた。当然、動作検証はしていない。

LRCKの変化をチェックする為の74164は実際には7474で
作れるが、まあ実際に作らないと思うのとICの数が減る訳
でも無いので上の回路のコピペで書いた。NOTの為に7404
を追加するのも勿体ないので7486でNOTを作った。

このままVHDLにするとxc2c64aに入らない気がする。
一番上のビットシフトの段数を減らす必要があるだろう。

ここまで書いて思ったのだが、I2Sからの変換よりも右詰め
からの変換の方が一番上のビットシフトの段数が減りそうだ。
(PIC32MXは右詰め出力も可能)

あと、FIFOメモリがあればもっと簡単になりそうな気がする。

※訂正、図に7447と書いてあるが、7474です。

SANYO LC7881 DAC その５ (PIC32MX編)

前回のPIC32MX基板にマイクロチップ社のデモプログラムを
入れて試した。基板にPICKITを刺そうと思ったら、ICとUSB
コネクタに干渉した。仕方がないのでコネクタを斜めに曲げた。

マイクロチップ社のデモプログラムはデモボード用なので、
PIC32MX+AK4645Aの組み合わせで動く様になってある。
AK4645AとはI2Cで接続され、AK4645AがBCKとLRCKを
発生させる仕様である。AK4645A無しでI2S信号出す様に
プログラムを修正する必要がある。

プログラム修正する場合、修正しすぎると元のプログラム
からかけ離れて問題が発生した時に戻れなくなる事だ。
だから、最初は最小限の修正でI2Sを出せる様にする事だ。
実際にプログラムを修正し始めて３日で鳴る所まで来た。
追加修正行が数行程度と、行を無効するコメントくらいで
済んだ。

ちゃんとWindows 10で認識した。

I2SのPCM5102Aと、メインシステムのI2S→PCM変換
回路でPCM1704が鳴ったのでちゃんと32bit I2Sで出力
されているだろう。

動作するにはしたのだが、何点か問題がある事も判った。

I2Sは出る様になったのだが、Windows 10で操作すると
ミュートとボリュームが使えない。ミュートしても音が
出るし、メインボリュームで音が小さくならない。この
処理はAK4645Aで行っていたのかもしれない。Windows
側でボリュームが下がればWAV信号を小さくすると思って
いたが、場合によってはPIC32MX内部でデータ計算をする
必要があるかもしれない。

次にLC7881を使う予定であるが、96fsか192fsができれば
良かったのだが、MCKからBCKを作る時に内部で分周する
場合は2の倍数しか使えないことが判った。つまり6分周に
なり384fsになるので、48kHz以上の再生は厳しい。

鳴らすだけなら問題ないとも考えられるので、とりあえず
次に進む予定だ。

プログラム修正は面倒だが、ここまでは動作して当たり前
の話だ。ここからが難関のCPLDを使ってビットシフトを
VHDLで書く事だ。

とりあえずCPLDでVHDLを書き込んで動作確認できる様に
LC7881基板とLPF基板を作った。

プリアンプ実験 その３

前々から作っていた実験用のプリアンプを改良した。
その１、その２

結局のところ、電源基板は２回オペアンプ基板は３回作り直した。
(失敗も含めて)

メインシステムのDAC内蔵電圧+電流アンプの結果より、オペ
アンプのバッファをLME49600からBUF604Aに変更した上で、
バッファの電源をオペアンプの電源から分離した。

オペアンプはLM317/337で約±12Vだが、バッファは前段の
コンデンサから直接で±17Vくらいだ。

バッファの出力をダイレクトにヘッドフォンに、R+Cの後ろを
プリアンプ用の出力にした。

この実験用アンプはディスクリートオペアンプの試験もできる様に
ICソケット間が離してある。画像はK田風オペアンプだ。

作ったけど使わない気もするが、たまにヘッドフォンで使かおう
かな？