SabreberryDAC ZERO2 第２試作
下の写真は第１試作と第２試作基板を並べたところです。
殆ど違いは見えませんね。僅かに配置を変えたくらいです。
つぎに裏面を見てみましょう。
こっちは違いが判りますね。 上の基板がミュート回路を追加した分、部品が増えています。
早速、聴き比べてました。
電源ON時のポップノイズも抑えられて小さな音で「チっ」というくらいです。 第１試作の時は「バツン」と大きなエネルギーがヘッドホンへ漏れていましたので改善できました。（SabreBerryDAC Zeroに戻っただけともいう）
今回はOPAMPにOPA1612というやや高級なものを使ってみました。デジキー/マウザーで1000円をちょっと超えるくらいの価格です。
これまで使ってきたOPA1662よりも全体的に明瞭で空間が広く、楽器やボーカルも丁寧な描写という印象を受けます。OPA1612から雑味というか元気さが減った分、もう少し高域側にパンチが欲しくなります。
この辺りは好みでLPFなど定数を調整してみるのも趣味としては面白いですね。回路図は公開する予定ですのでご自身の裁量で好きにしてください。
現在、15～２0時間ほどエージングしているのですが100時間くらい経ったころ再評価して私も定数検討してみようかと思います。
ちなみに、ラズパイ駆動とBM83基板駆動とで比較すると、さすがにラズパイの方がピュアオーディオ的な音になります。
BM83はSBC接続、AAC接続とも試しました。
AACの方が少し詰まった感じがしますね。 再生機器がiPad（AAC）とAndroidスマホ（SBC）との違いもあるため何とも判断しにくいです。
とはいえ、スマホやiPadからBT接続できるという手軽さはあるので、BM83で程よく聞こえるようにチューニングするというのもアリな気がしています。
いかがでしょうか。
追記＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
BM83基板＋SabreberryDAC Zero2 を電池駆動してみました。
3本でも動作するのですがホワイトノイズ多めです。 電圧不足ぎみ？？？
電池4本のBOXはデモ機に組み込んで貸し出してしまったので、買わないといけないっす。
あ、デモ機貸出し案件の記事も書かないと・・・ Twitterでは書いたけど某雑誌に掲載してもらっています。
« 小さい基板がいっぱい | トップページ | stereo 2024年8月号に禁断のヘッドホンアンプが紹介されました。 »
「SabreberryDAC ZERO」カテゴリの記事
- UPS HAT(C) という名前のラズパイZero用バッテリー(2024.10.23)
- RPiZeroRP2040 ラズパイZERO形状USB-DDC基板(2024.10.20)
- SabreBerryDAC Zero2用のアクリル板キット(2024.10.05)
- SabreBerryDAC Zero2用のケース 3Dデータ(2024.09.17)
- RPiZeroRP2040 USB-DDC基板試作(2024.09.01)
コメント
« 小さい基板がいっぱい | トップページ | stereo 2024年8月号に禁断のヘッドホンアンプが紹介されました。 »
ラズパイ駆動の方がピュアオーディオ的な音なんですね。BT接続のデータ転送の制限なんでしょうね。
たかじんさんのファンを広げる意味でBT接続に1票です。
UIの視点でも今時スマホやiPadベースに適うものはないと思いますので、BM83の延長線上でブラッシュアップされる方向が個人的には好みです。
拙宅ではSonyのHAPをメインにiPadのUIから操作してオーディオしていますが、（専用アプリになりますが）UIは流石と思います。
（あくまでも個人的にですが）オーディオの時にPCとかラズパイとか弄りたくないです（笑）
投稿: ま。 | 2024年7月26日 (金) 17時11分
SBCとAACとでは、SBCの方がAACより良かったとのことですが、ちなみに音源のフォーマットやビットレートなどは同じ条件なのでしょうか。
それがわかれば、BM83基板で音質を優先させるときの音源や再生機器の組み合わせが見つかりそうに思います。
投稿: 三毛にゃんジェロ | 2024年7月26日 (金) 18時42分
SabreberryDAC Zero2基板はローンチ間近なんですね。
OPAMPの選択肢があるのは遊べるので楽しみです。
おすそ分けしていただいた試作基板と違うOPAMPを使うのは既定路線ですね。
私はすでに初代をZMPDで復活させて
SDカードに音源データ入れてポータブル対応で使って居るので
新版ではちょっと変化させて組みたいです。
第一候補はBT版。
音質が劣っても許容範囲と体験で判明していますからね。
ただ、初代に対してどこまで便利か？が少し不明です。
第二候補はPicoのRasPiサイズUSB-DDC。
iPhone3GやiPod miniが使えると比較出来て面白いかも？？
iPhoneやiPodの雑っぽい音が改善できることを期待したいなぁ。
あ、Combo384互換のBT-DDCは使い道が思い浮かばない・・・・
Combo384をわざわざ置き換えることもないしなぁ。
投稿: sawanoriichi | 2024年7月26日 (金) 23時40分
ま。さん
BTは圧縮転送ですからね。 もとデータがFLACやPCMだったとしても転送するときにmp3のような非可逆圧縮で飛ばしています。
という訳でBTを使う限り、ラズパイのような音質は求めることができません。 おっしゃる通り、音質よりも手軽さがウリになります。
三毛にゃんジェロさん
流石のつっこみどころ・・・ 比較はAmazonMusicアプリで同じ曲を数曲聞いただけです。
そういう使い方が多いんじゃないかと勝手に推測したまでです。
FLACデータを高音質再生アプリで再生してもBT転送時に非可逆圧縮されますしね。
BM83内部のAACデコーダーの性能？ という可能性もあります。 AACの方が高圧縮率で高い音質が維持できるなんて話があったくらいですし。
そういえば、何年か前に完全ワイヤレスイヤホンをレビューしたときAAC接続するとホワイトノイズが大きめに出ていました。 SBC接続ではノイズが小さい。 あれは何だったのだろう。
sawanoriichi さん
市販されているBT受信機はバッテリーを長持ちさせるため、どうしても音質が犠牲になっている感が否めませんね。
便利につかえるかどうかは、電源とケースによるところが大きいように感じています。
BM83のデータシートでは最大定格は7Vと書いてあるので、ニッケル水素4本駆動が現実的かもしれません。
投稿: たかじん | 2024年7月27日 (土) 09時45分
たかじんさん
BM83基板+DAC Zero2基板ではスマートフォンからデータを送る形ですが、
RasPi Zero+初代SabreberryDAC Zeroもスマートフォンで操作するので
（音源データは128GBMicroSDに溜めて、ZMPD AP版を使用）
実使用上の差はどんなものなのか？というところです。
バッテリーはどちらが長く持つのか？や
スマートフォンのWiFi切り替えvsプレーヤアプリBT出力の操作性、とか。
先日試聴させていただいた時の操作からはそれほど差はないかも？
と想像はしております。
再生音の差は、戸外でのポータブル運用なので判断の埒外です。
（そもそも、高性能なヘッドフォンやイヤフォンを持っていないので）
ケーシングは、新基板の方が分がよさそうに感じています。
私のRasPi Zero+初代DAC ZeroはDAC基板裏に電解コンを増設して、
emerge+ with N2factoryさんのアルミプレートで挟んだので26㎜厚です。
新基板ではイヤフォンジャックを別置すればもう少し薄くできそうですね。
こんな夢想を働かせながら組立計画を立てるのが楽しいのですが。
ところで、OPA1612といえば、
2年ほど前にNFJさんがDIP化モジュールにして売っていました。
600円位の値段だった気がします。
で、先ほど調べたらDigiKeyでも１個1000円位、
Bispaさんはモジュール化したのが1500円位でした。
円安の影響おそるべし、です・・・・・
実は、NFJさんのモジュールが出た時に2個程購入ししました。
が、部品箱の肥し化させてしまっていました。
電気回路の知識が全くないプラモ組立型電子工作自作な者ですから
レール・ツー・レールのOPAMPってどう使うのか、よくわからないのです。
（ソケットのOPAMPをそのまま置換する、なんてナイーブさは流石にありません）
投稿: sawanoriichi | 2024年7月27日 (土) 11時09分
たかじんさん
自分の場合はiPod touchにAAC320kbpsで入れてます。
iPod touchとBM83の間でこのフォーマットのまま送信されていればいいのですが、ビットレート圧縮とかされてたら嫌だな〜。
投稿: 三毛にゃんジェロ | 2024年7月27日 (土) 13時18分
そうですね、Bluetoothは基本1Mbpsの帯域（ベアラ）だからそうですよね、、。
PCカード製品から始まって、やっとここ迄普及してメジャーになったのに、ちょっと残念です（笑）
投稿: ま。 | 2024年7月29日 (月) 08時28分
sawanoriichi さん
BM83基板の方は、Spotifyなどストリーミング再生が手軽ですね。Play/Pauseスイッチ、音量操作も効きます。 Youtubeなど動画の音声もOK。
一方、ラズパイを使ってSDメモリ内の楽曲再生は、音質的に有利になります。
バッテリーの持ちは、まだ測定していませんが似たような感じだと思います。
レール・ツー・レールは、電源電圧が低く限られているときに必要になってきますね。
三毛にゃんジェロさん
AAC320kbpsのまま転送してくれていれば良いですね。 近代的なOSでは、ソフトが役割を分担していることが多く、実際の所は分りません。
プレイヤーアプリ： ALAC、FLAC、MP3、AACなどデコードしてPCMでOSへ渡す。
OS： ミキシング＋音量操作した後、USB、BT、本体スピーカー、AirPlay などへそれぞれのフォーマットへ変換して転送。
ってのが順当な気がします。 データがAAC320kでBT接続AACモード時だけ、変換なしでダイレクト転送する。。。 というのはなかなか考えにくいような気がしませんか？
ま。さん
BTの1Mbps転送ってどこで使われているんでしょうかね。。。
投稿: たかじん | 2024年7月29日 (月) 21時30分
たかじんさん
プレーヤーが音量のみ変換したデータをOSに渡し、OSはそれをそのまま相手に送信するという形なら音質劣化は最小に留められると思うのですが。
ペアリングの時に対応コーデック情報とかもやりとりしているはずなので、未対応のコーデック以外は音量レベル調節以外の変換なしにオリジナルのコーデックで転送して欲しいもの。
ただ、BTの対応コーデックにAACとあっても、それが何を意味するのか余り明確になってないように思います。調べてないので単なる知識不足かもしれませんが。
投稿: 三毛にゃんジェロ | 2024年7月30日 (火) 00時25分
たかじんさん
OPA1612のデータシートを確認したら、出力のみレール2レールのようです。
「SabreBerryDAC ZERO 2 試作版」を見て入出力レール2レールが必要だと思っていましたが、入力のレール2レールは妥協も可なのでしょうか。
ここが必要かどうかで選択肢の数が違うと思いますのでご教示をお願いします。
投稿: デジタル | 2024年7月30日 (火) 12時48分
三毛にゃんジェロさん
音量を操作するのに一旦デコードしなければならないという宿命がありますね。
プレイヤーアプリ側からみて、出力先はOSに依存し、BT、USB、本体SP、本体イヤホンジャック、Airplay、など個別に作りこむのではなく、APIを通してOSへ渡すというのが近代アプリです。 着信などあったときフェードアウトして着信音、別アプリへシームレスに音を繋いだりもしますしね。
Swiftやobjective-Cなどのオーディオ出力系API仕様を見てみると面白いかもしれませんよ。
デジタル さん
OPA1662もです。 ただ、よく読むとOPA1612の入力レベルが明確に書かれていないため最大出力時にはクリップする可能性がありますね。
現在、ヘッドホンを直接ドライブしていて音量maxにはしないので気づきませんでした。HD490 PROで適度な音量は下から1/3のあたりです。 1/2まで上げると結構な爆音になります。
入力側でクリップするようでしたら、OPAMP部のゲインを僅かにUPして出力クリップと同じ程度にすると良いかもしれませんね。 音量を上げてクリップしてしまうならダイレクト駆動では（感度が低い）そのヘッドホンを鳴らしきれないと判断できます。
その時は外付けヘッドホンアンプを使うのが良いと思います。
投稿: たかじん | 2024年7月31日 (水) 22時00分
たかじんさん
某オーディオ機器メーカーのサポートに確認してみたところ、ワイヤレスヘッドフォンとプレイヤーとの間では対応しているコーデックのままデータを転送し、その後ヘッドフォン内でそのコーデックに従ってデコードして再生しているとのことでした。
たかじんさんのお考えの通りだとすると、そもそも再生側で多種コーデックに対応することは全く不必要ということになります。しかしながら、対応コーデックを明記してあるということはそのコーデックのままデータ転送しているに違いないと思い、その確認のためにメーカーに問い合わせた結果が上記です。
最初に互いにコーデックの確認を取ってから対応可能なコーデックを決定してそれに従ってデータを転送し、再生側は受信データをデコードした上で再生部に送り出していると考えるのが自然だとは思いますが、如何でしょうか。
投稿: 三毛にゃんジェロ | 2024年8月22日 (木) 16時01分
三毛にゃんジェロさん
その通信コーデックは、DAP ＜---＞ BTヘッドホン 間ですね。
SBC、AAC、apt-X、apt-XLL、LDACがそれにあたります。
いっぽう、三毛にゃんジェロさんが気にされていらしたのは、iOS機器内部の
再生ソフト ＜---＞ OS 間だと思われます。
OS側には、再生ソフトとの入出力（API）があり、APIの下にデバイスドライバとして、
・USB通信ドライバ
・BT通信ドライバ
・本体スピーカードライバ
・Airplayドライバ
という多層構造になっています。そして最終出力先の選択は再生ソフトではなくOS側が管理しています。つまり、調べるべきポイントはAPI仕様です。
BT通信ドライバが選択され、BT通信がAACで接続されて、尚且つ、通信状態（周囲により可変される）が大丈夫な転送レートで元ソースのAACファイルの圧縮レートが一致したときだけ直接流せる可能性がありますね。
そのような特定条件のダイレクトパスがAPIに用意されていれば行けると思います。（再生ソフトもそのダイレクトパスAPIを使うようにコーディングされている場合）
あとは、ファイルのAACとBTのAACの仕様が同一かどうかも・・・
ファイル形式では圧縮時間がかかっても高圧縮にするオプションをいくつも使って高音質にしていると思います。一方BT通信は動画再生で音の遅延が問題になるのでリアルタイム性を重視した軽い処理だけのAACという可能性もあります。
https://ja.wikipedia.org/wiki/AAC
投稿: たかじん | 2024年8月22日 (木) 21時06分
たかじんさん
自分が気にしていたのは、
プレイヤー内データ → BT送信 → ..... → BT受信 → コーデックに従ってデコード → D/A変換(LPF処理) → アナログ出力
における「BT送信 → ..... → BT受信」の部分でした。
もしかしたらどこかで行き違いが生じる表現をしてしまってたのかもしれません。
もし、そうでしたら申し訳ありませんでした。
プレイヤー内部では、
プレイヤー内データ → デコード → D/A変換 → アナログ出力
の過程において、各コーデックのライブラリがデコードを担って汎用フォーマットに変換し、そのデータをOSのAPIを通じてD/A変換および出力段に送出する構造だと理解しています。
仮に送信側、受信側のどちらもAAC対応だとしても、たかじんさんの仰るようにAACデータを100%忠実に転送しているかも不明だし、エンコード時のアルゴリズムとデコード時のアルゴリズムが異なるもの(実装は各メーカー独自であると仮定)である以上、エンコード前の音とデコード後の音が厳密には同じだとは思いませんが。
投稿: 三毛にゃんジェロ | 2024年8月22日 (木) 21時56分
三毛にゃんジェロさん
なるほど。 そこは、送信側、受信側で対応している方式で接続されます。
ファイルがAACであるかは全く関係ありません。
私が持っている機器ですと、受信側でLDACを有効化の設定があり、さらにはLDACに音質重視か接続性重視かの設定もあります。
そしてスマホ側でLDACを許可すると、LDACで接続されます。
どちらか一方でLDACを許可しないとSBCでの接続になります。
プレーヤー側でDA・AD変換はされていません。 デジタルのままフォーマット変換されます。
AAC/FLAC/mp3->PCM->Vol・Mix・SRC ->LDACエンコード -> BT転送 -> LDACデコード->PCM->DA変換
という感じじゃないかなと思います。
投稿: たかじん | 2024年8月22日 (木) 23時22分
たかじんさん
あ、前のコメントで第2段落のプレーヤーの話はあくまでもプレーヤーだけで完結してヘッドフォン出力する場合です。
これも、ちょっと舌足らずでしたね。
あと、データフォーマットのAACと通信コーデックのAACを混同して、データフォーマットのまま転送されると思い込んでいたのがそもそもの間違いだったようです。
さて、
AAC/FLAC/mp3 -> PCM -> Vol・Mix・SRC -> LDACエンコード -> BT転送 -> LDACデコード -> PCM -> DA変換
はあくまでも、たかじんさんの環境がLDACに対応しているので、それが前提と考えてよろしいですね。
さすれば、これを一般化すると
AIFF/WAV/AAC/FLAC/mp3 -> PCMにデコード -> Vol・Mix・SRC -> 送信側・受信側両対応のコーデック(なければSBC)にエンコード -> BT転送 -> PCMにデコード -> DA変換
となりますが、これで正しいでしょうか。
こうしてみると、2度のデコードと1度のエンコードが介在するので、やはり音質的にはワイヤード接続の方が精神衛生的にもいいなという感想です。
でも、送受信側共にSBC以外の複数のコーデックに対応している場合、特にコーデック選択操作が不要/不可の場合にはどうやってコーデックを決定しているんだろうという新たな疑問も。
投稿: 三毛にゃんジェロ | 2024年8月23日 (金) 00時22分
三毛にゃんジェロさん
ありがとうございます。 一般化するとそうなると思います。
仰る通り有線の方が有利なのは間違いないです。 無線で可逆圧縮で飛ばせているのはAirplayくらいだと思います。
BTコーデックは優先順位をつけているだけじゃないでしょうか。
投稿: たかじん | 2024年8月24日 (土) 08時49分