nabeの雑記帳

おそらく上の回路ではCRDの定電流源としての安定性が良くないことが原因です。今回使用したCRDを安定動作させるためには、両端に8～10Vぐらいかけてあげる必要があります。実際10mAのCRDを使って6.2mAしか流れてないわけで、規定の飽和動作をしていません。飽和状態で使用しないと、（オペアンプの）出力電圧によってバイアス電流が非線形に変動してしまいます。*1

そんなわけでここ何年か抵抗を使用してきたのですが、一応カレントミラー回路も検証したほうがよいよね？　とも思っていました。放置された理由はカレントミラー回路を組み込むのが面倒なのと「回路的には超安定するけど、多分抵抗より音悪いんだよな……」という予想（苦笑）

検証したら、これまた明らかにカレントミラー回路のほうが音が良かったです。この回路だと（オペアンプから見たとき）理想定電流源に近いんですよね。つまりオペアンプ対して抵抗よりも負荷が軽くなることが大きな要因だと思われます。

勘の良い人なら正解するのは簡単

基本的に「バイアス電流が多いほうが音が良い」のですから、その知識があれば簡単に並べ替えできます。

なぜなら「それ単にバイアス電流が増えただけでしょ？」というツッコミをされないように（実験時にその要因を排除できるように）、回路の電流値を設定してあるからです。

バッファ回路のコンデンサどっちがいい？

左右の回路、どっちが音が良いと思いますか？

アンケートでは、およそ「左が良い:右が良い=2:1」という投票結果でした。

聴き比べた感想は、やや左が良いかな（大きな差はなさそう）。

回路を普通に考えてみる

まず普通に回路を考察してみます。C2に位置するコンデンサですが、これは経験上容量が大きいほど音が良くなることが分かっています。

右回路の中点と出力の接続を一度無視すると、単純に左から右の回路になった場合、C2に相当するコンデンサ容量が半分になっいます（コンデンサの合成容量）。

もうひとつ、X（Twitter）で指摘していた人が居てさすがと思ったのですが、右の回路は高周波特性が悪化します。オペアンプの高周波出力がC3/C4コンデンサを突き抜けて出力（負荷）に接続されているためです。

2つとも音が悪くなる要因として考えられます。

経過とか

どちらにもC1の820uFを付けた状態で、C2, C3に100uFを追加したとき追加したとき明らかに良くなったので、それならばってことで上の比較回路を考えてみたのですが、実際作ったら微妙な感じ。

もう少し回路を工夫して検証してみても良いかもだけど、820uF×3（C1-C3）してもC1単独より悪いっぽいからダメかも。

まとめ

思いつきを検証するのは大事。
追試しまくるので時間がかかって大変（コンデンサのエージングも必要ですし……）。
意外と思ったとおりの結果にはならない。

ところで全部正解した人は居ましたか？

コメント（0件）

2025/05/15(木)DACのLPFにフェライトビーズを使ってみる

戯言::技術電子::DAC/ADC

ヘッドホンアンプ回路をいじっているときに、ふと思い立って、DAC（PCM2702DAC魔改造品）のLPFを変更してみました。

作ったのはこんな回路

なんとなく「LPFは抵抗とコンデンサのみで構成する」ってイメージがあると思うんですが、ヘッドホンアンプでは出力フェライトビーズ（orコイル）が驚異的な性能と音質を実現している*1ので、別にフィルタに使ってもよくない？と。

PCM2702のDAC出力段も、LPFも結局オペアンプ回路なので、どちらもフェライトビーズにより負荷を軽くしてあげたことで、結構音質が良くなりました。

ついでにシングルオペアンプ比較

載せ替えた直後と時間たった後で音が変わるので、30分ぐらい鳴らした後で比較しました。

本当は回路調整とオペアンプ変更は同時にテストすべきだとは思いますが、時間がかかりすぎてやってられないため*2、適当なオペアンプにて回路を最適化したあとでオペアンプ選択しました。

LT1028ACN系: 定番の低ノイズオペアンプ。仕様書にある通り、入力抵抗の関係からLT1001ACNが一番よかった。
LT6018: 比較的新しい低ノイズ高音質オペアンプ。比べた中でも頭1つぐらい抜けてよい。1pin=Vee、8pin=Vcc接続が必要。THD+N -115dB。
LME49990: 往年の（製造終了している）低歪み、低ノイズオペアンプ。すっきりとした音で比較基準としてちょうどよさそう。THD+N -140dB。
AD8671: アナデバの石って使う人あんまりいないけど、結構良いの多いですよ。
OPA627A: 昔の高級オペアンプ。試す前は「今更だろう」と思いましたが、さすがに音は良かった。THD+N -130dB（グラフより）。
OPA211: 低ノイズのペアンプ。OPA627のほうが良いかな。THD+N -136dB。
OPA828: 低ノイズ、JFET入力オペアンプ。結構よかった。THD+N -130dB。
OPA1611: SoundPlusシリーズのオペアンプ*3。今回の中では一番良かった。THD+N -136dB。
補足: THD+Nは1kHz、Gain=+1の記載があれば抜粋。負荷や信号の大きさはまちまち。

ここに書いたやつは基本的にどれも良かったです。回路等によって最適は変わるという前提のもと、この中で特に印象深かったのは、LT6018、OPA828、OPA1611の3つで、そこまで差はないかなという感じです。

まとめ

未だにPCM2702をメインで使ってるのもアレな感じはしますが、その辺のスペックだけ384kHz/32bit DACよりは音も良いから困りもので……。

過去の魔改造＋今回のLPF変更でPCM2704 Ver.2よりは多少良くなりましたが、msBerryDACには明らかに劣ります。~~msBerryDACなんて化け物DACを1万円以下で頒布した奴は、ほんと狂ってると思う。~~

ハイレゾDAC作りたいなあ。

コメント（2件）

2024/01/22(月)Acer H223HQの分解・修理？

戯言::技術電子::修理

H223HQという古いTN液晶モニターの調子が悪いので分解したメモ。

症状

電源ケーブル切断後、数秒～30秒ぐらいして電源を投入すると、電源ボタンが一切反応しなくなる（電源が入らなくなる）。
電源ケーブルを抜いて、2～3分ぐらい放置して再度電源を接続すると、今度は電源が入り使える。

電解コンデンサの劣化かと思ったのですが、よくよく思い返してみると購入間もない頃も同じ症状に見舞われたおぼろげな記憶があるため、仕様のような気もします……。

注意

情報提供のための記事です。分解等は必ず自己責任でお願いします。

コメント（2件）

2022/09/14(水)PS2 DUALSHOCK2のアナログ感圧ボタン修理

戯言::技術電子::修理

PlayStation2 のボタンが反応しなくなったので、デジタル化して修理したときのメモ。PS3コントローラーでもおそらく有効。

(Abstruct) Notes on repairing PlayStation2/DUALSHOCK2 analog pressure sensitive buttons by digitizing them.

※PS2実機での動作は未確認。

コメント（1件）

2022/06/17(金)OOM Killerでサーバが死んだ

戯言::技術Linux

ある日突然、Webサーバ（Apache）が死亡したときのメモと、実施した対策のまとめ。

OOM Killerとは

メモリが足りなくなったときに、負荷が高そうなプロセスを一撃必殺してくれるLinuxの機能です。

ログ

長いので別ファイルに。

この中で、rssが実消費メモリ~~(KB)なのですが、トータルしても209MBしかありません~~。ps auxの値（KB）と異なり、OOM Killerプロセス一覧数値はすべてページ単位（4kB単位）なので、836MB。このマシンの実メモリ1GBなのでほとんど無くなっています。

スワップもswapents（Anonymous swap entries）の合計が960589、エントリー1つあたり4KBですので、3.7GB。つまりスワップは完全に食いつぶしてる。

色々調べると、OOM発動時はこの辺を見ると良いらしい。

[7934037.757829] Node 0 DMA: 43*4kB (UME) 14*8kB (UME) 12*16kB (UE) 13*32kB (UME) 2*64kB (UE) 7*128kB (UME) 4*256kB (UME) 3*512kB (UME) 0*1024kB 0*2048kB 0*4096kB = 4476kB
[7934037.762116] Node 0 DMA32: 258*4kB (UME) 252*8kB (UME) 576*16kB (UME) 325*32kB (UME) 105*64kB (UME) 20*128kB (UME) 8*256kB (UE) 3*512kB (UME) 5*1024kB (UME) 0*2048kB 1*4096kB (M) = 44744kB

どれくらいのサイズの連続したメモリをいくつ確保できるかという表示ですが、一番大きいもので「DMA側が512kBを3つ」「DMA32側が4096kBを1つ」ということで、メモリの断片化してますし、そもそも両方合わせて48MBぐらいしか空きメモリがない。

OOM Killerが発生して当然の状況と言えます。

なぜApacheが死んだのか

OOM Killerが発動したのは、sys.fcgiというFastCGI（Apacheの子）プロセスなのですが、なぜかApache自体が死亡しておりました。daemon.logを見ますと、こんな感じ。

systemd[1]: apache2.service: A process of this unit has been killed by the OOM killer.
systemd[1]: apache2.service: Failed with result 'oom-kill'.
systemd[1]: apache2.service: Consumed 1h 21min 18.835s CPU time.

Apacheの子プロセスがOOM Killerされたので、systemdが善きに計らってApache自体を終了させた模様。……やめてくれー（苦笑）

子プロセスが死んでもApacheを生かす

メモリ食いつぶしcgiを作って実験してみたのですが、通常のcgiなら問題なくFastCGIのときだけこの問題が起きるようです。systemdの設定を変更して、Apacheを巻き添えにしないよう変更します。

# Debianの場合, rootでの作業
cd /etc/systemd/system
mkdir apache2.service.d
vi apache2.service.d/oom.conf
systemctl daemon-reload

# oom.confの中身
[Service]
OOMPolicy=continue

/etc/system/systemd/apache2.service.d/oom.conf がきちんと読み込まれてるか、設定を確認してください。

systemctl cat apache2

この状態でメモリ食いつぶしfcgiを実行してみましたが、無事(?)にfcgiだけプロセスkillされました。

その他の対策

Swap領域を3.7GBから10GBに増強。
sys.fcgiで不要になったメモリを開放することが難しかったので、メモリ使用量（/proc/[pid]/statusのVmHWM）が一定量を超えたら、処理終了後に自動でプロセスを終了するようにした。
mod_fcgidの設定を変更して、一定時間使われないプロセスはすべて終了するようにした。
```
FcgidMinProcessesPerClass	0
FcgidProcessLifeTime		600
FcgidIdleScanInterval		120
```

スワップは実RAMの倍（この場合2GB）という定説を昔読んだ気がしますが、「未開放メモリ→スワップアウト」というケースを考えると、多いに越したことはないかもしれません。

本当はApache側でメモリ制限を実施できたら楽なのですが、mod_fcgidの子プロセスには RLimitMem とか効かないんですよね……。