nabeの雑記帳

PCM2704 DAC(Ver1)キットを再販にあたり、大幅強化してみました。

• 概要
• 回路図と部品表
• 設計方針と改良点
  • Ver1.4の問題点
  • Ver2.0での改良点
• Ver2の特徴
  • Ver2の欠点
• 音質比較
  • セルフ魔改造PCM2702 DACとの比較
  • msBerryDACとの比較
• まとめ

概要

委託しているPCM2704DACが2019年2月から在庫切れになっていて悩んでいました。

初期設計（Ver1.0）から10年以上が経過し、ハイレゾが普及しつつあるこの時代にPCM2704はチップの制限上48KHz/16bitまでしか再生できません。再販するにはある程度まとまった数を作る必要がありますが*1、不良在庫を抱えたくありません（苦笑）

しかしながら再販の要望も複数頂いており、どうにか応えたい。

それならばいっそのこと「音質に全振りしたVer2を作ってしまおう」というので作られたのがこのDACです。

回路図と部品表

設計方針と改良点

Ver1.4の問題点

Ver1.4の回路はある種の完成系で、これを改良するとなると大きな決断をせざる得ません。大きな決断というのは、何かを犠牲にしてでも音質を一番良くするということです。

Ver1.4の出力LPFにはいくつかの欠点がありました。

1. 出力抵抗がないため、使用できるオペアンプが限られる。
2. 電源電圧が±4V程度しかないため、使用できるオペアンプが限られる。
3. ベッセルフィルタ構成が良くない。*2

他にもオペアンプ電源が安定化されていないとか色々あるのですが、とにかくすべての原因は半ば強引にオペアンプでLPFを動作させていることにあります。ここは設計当時の「価格（回路規模）を抑えて音質を狙う」ために妥協した部分です。

Ver2.0での改良点

抵抗とコンデンサだけのシンプルなパッシブLPFのほうが（ほとんどのケースで）音質は良くなります。これは当たり前のことなのですが、なぜオペアンプが必要だったのでしょうか。

それはPCM2704の出力に含まれる出力オフセット（+1.64V）をキャンセルするためです。オフセットがなくなれば、音質低下の最大要因である出力カップリングコンを排除できます。このために多くのことが犠牲になっていました。

これをどうにか解決できないかと検討と試行錯誤を繰り返し、オペアンプを使わずに出力オフセットをキャンセルする方法を思いつきました。

オフセット分をマイナス電圧で引き下げる作戦です。オフセットを+1.64V、マイナス電源を-4.2Vとすると、R56は次のように求められます。

この5.1KΩは音質に関わるので（RT0603等を持っていないと）簡単には変更できません。よって、出力オフセットはR3の値で調整するのですが（50Ω増やすと出力電圧が+20mVぐらい変化する）、左右同時にしか調整できません。

とはいえ、USB電源電圧が5.00～5.05V付近ならば、コンデンサのエージング後にオフセットは20mV程度に収まるかと思います。

Ver2の特徴

• 出力オペアンプレス＋出力カップリングコンレスで音質が超進化。
• 音響用抵抗として、超高音質なRT0603を使用。
• 電解コンをすべて音質の優れる高分子コンデンサに変更。

Ver2の欠点

音質は最大限進化させてものの、これはこれで欠点があります。

• 出力電圧レベルが小さく、約1.3Vppしか出せない。

これが音質のために犠牲になった部分です。PCM2704は出力電圧範囲が元々小さめなところに、パッシブLPF＆オフセットキャンセルの回路を詰め込んだことが原因です。これは諦めるしかありません。

1Vppあれば最低限問題は起こらないと思いますが、そういうものだとご理解ください。

音質比較

手持ちのDACと比べてみました。

セルフ魔改造PCM2702 DACとの比較

常用している魔改造PCM2702ですが、今回のPCM2704-v2の圧勝という悲しい結末になりました……。

慌ててPCM2702を再改造するものの、再改造してもこのPCM2704-v2のほうが良いようです。*3

msBerryDACとの比較

去年まで頒布していたラズパイ用 384kHz/32bit DACです。PCM2704-v2の勝ちでした……。

「それはさすがにまずい」ので、msBerryDACを改造して C1/C2 を 10nF→1nF に変更しました。

C1/C2改造msBereyDAC > PCM2704-v2 > ノーマルmsBerryDAC

というわけで、DACはチップの性能もさることながら回路設計が重要というのがよく分かる結果になりました。

まとめ

• PCM2704 DACの出力電圧範囲を妥協して、音質を進化させた。
• 使用している部品も進化させた。

キットの購入は委託先から。このDACは再販しない可能性があります。

カメラ等で使われるRTSPストリームはブラウザとすこぶる相性が悪く、以前はFlashを使って親戚のRTMPが再生されたりしていましたが、もはや過去のお話。

最近は、分割した MPEG4 ファイルを連続再生する HLS や MPEG-DASH が主流です。しかし、すべてを数秒に分割する仕組みのため通信効率が悪くなってしまいますし、どうやっても遅延の問題が避けられません。

かと言って WebRTC はP2P用に設計されていて、ブラウザ間ビデオチャットには向いていますが、配信等の目的に使うことは難しく、そもそもUDPが使えない環境では動作もしません。

そこで超低遅延（1秒未満）のストリーミング再生（配信）システムを構築しました。

更新履歴

• 2022/09/05 WebCodecs正式版に対応。
• 2021/04/29 H.265/HEVCに対応。
• 2021/04/21 エラー内容をHTML上で表示するよう変更。
• 2021/02/22 初版。

デモ

デモを設置しています。

rtsp:// で始まるURLを入力すると、RTSPをリアルタイムで変換を確認できます。残念ながら適当なフリーのRTSPソースがないため、各自ご用意ください（192.168.x.xxのアドレスで試す人が多いようですが、当然接続できません。グローバルIPを持ったRTSPサーバを指定してお試しください）。

• Chrome および Firefox が推奨です。
• 対応しているのは「H.264/avc1」か「H.265/hvc1(HEVC)」ストリームのみです。
• デモはセキュリティのため以下の制限を加えています。
  • RTSPパスワード認証は使用不可に設定しています。
  • RTSP接続ポートは 554 のみに制限されています。
  • 再生時間は60秒に制限されています。
• 「WebSocket Server Down」と言われた場合は、変換サーバの起動忘れなので、コメント or ご連絡ください。
• デモですので、常識の範囲内でご利用ください*1。

仕組み

RTSPサーバに接続して、リアルタイムでmp4に変換しています。コンテナ（フォーマット）を変換していますが再圧縮しているわけではないので高速に動作します。ffmpegを使っても同様のことが可能ですが、ffmpegでは変換過程で数秒程度の遅延が発生します。

ffmpeg -rtsp_transport tcp -i rtsp://<ip_address>/path -c:v copy -an -movflags empty_moov+omit_tfhd_offset+frag_keyframe+default_base_moof -f mp4 pipe:1

mp4に変換されたデータを WebSocket 経由でブラウザに送信し、受け取ったデータを JavaScript で MediaSource に入力し、VIDEOタグで表示しています。

let sourceBuffer;
const ms  = new MediaSource();
ms.addEventListener('sourceopen', function(evt){
	sourceBuffer= ms.addSourceBuffer('video/mp4; codecs=avc1.64001E');
});

const VIDEO = document.getElementById('video');
VIDEO.src   = window.URL.createObjectURL(ms);

const ws = new WebSocket('ws://example.com/');
ws.binaryType = "arraybuffer";

ws.onmessage = function(evt) {
	sourceBuffer.appendBuffer( evt.data );
}

実際はもう少し複雑ですが、フロントエンド（JavaScript）では難しいことはしていません。デモページ内のソースに、スクリプトが全部書かれていますので、興味のある方はご覧ください。

変換サーバは？

今のところ非公開です。興味のある方はメール等でご連絡ください。ライセンス等する予定です。

まとめ

• 映像が目的だったため、今のところオーディオには非対応です。
• H264の圧縮も伸張もしていないので、H264がらみの特許問題は起きないはずです。
• Windows Media ServerやReal Serverがそうだったように、将来的にはRTSPが廃れるか、ブラウザがRTSPやRTSPライクな何かをサポートして状況は変化するように思います。

参考文献

• html5_rtsp_player
  • WebSocket経由でRTSPサーバにアクセスし、JavaScript側でRTSP通信をしながらmp4を再構成しています。原理的には似ていますが、サーバ/クライアントでの処理分担が異なります。サーバはNode.jsで書かれていますが、30行程度のスクリプトでサーバを自作することも可能でした。
• v4l2rtspserver
  • V4L2を使用した、RTSPサーバ。H264で出力をするためには、カメラがH264エンコーダーを内蔵しているか、V4L2対応のH264ハードウェアエンコーダーが必要。
• fmp4streamer
  • V4L2(H264)なソースから、ブラウザで再生可能なH264ストリームを生成するソフト。やってることは一緒。ただ作り込みが甘いのか、試した限りだとリアルタイム性がいまいち。多少書き換えれば改善するかもしれもい。

メモ

Video4Linuxとffmpegを使用して、カメラからリアルタイムH265を吐き出す方法。

ffmpeg -f video4linux2 -i /dev/video0 -s 640x360 -c libx265 -pix_fmt yuv420p -fflags nobuffer -tune zerolatency -f rawvideo

これをそのままWebSocketで送信できれば、上記デモと全く同じ仕組みで、ブラウザ上にリアルタイムカメラ画像を取得可能。