がとらぼ
INTAA.NET

RaspberryPi Zero WにDACを接続

RaspberryPi Zero W (以下RPi0W)を買って暫くいろいろやってみたけど、思ったより性能が中途半端で使い途に困った。結局音楽プレーヤーあたりが無難かなと。
でも、RPi0Wにはイヤホン端子が無い。
そこでDAC基板を購入することに。

DAC基板はとてもたくさん製品がある。USB接続は簡単だが今回はそれでは面白くないのでI2S接続にしたい。
RaspberryPiなどのシングルボードコンピュータでは音楽プレーヤーとしての操作性に難があるが、それを解決するために操作ボタン付きのDAC基板もある。でも、「がとらぼ」の中の人はRaspberryPiの音楽プレーヤーを家から持ち出すことはないと思うので操作ボタンは要らないかなと。
いろいろ比べていたらとても安くて良さげなのを発見。
売ってたのはNorthFlatJapan。

ぱっと見た感じDACチップの型番が違うだけっぽい。おそらくオーディオマニアならそのチップの違いを重要視するのだろうけど、そらちは全く疎いのでチップが違うとどう音が変わるのかわからない。DACのメインのチップ以外も重要なのだろうけど、カタログスペックとしてはメインのチップの比較だけになっちゃう。
で、本来ならこういう一見同じような選択肢がある場合は一番安いのを買うのだが、3つの価格差が1.5倍程度とはいえ絶対価格が物凄く安い。それならよくわからんけど一番高いのを買っちゃえということでPCM5102A搭載のモデルをポチった。
送料は200円なので合計1480円。騙されてんじゃないかなと心配になるほど安い。
ネットを見るとNFJ製と書いてるところがあったりするけど中国の通販で同じ設計のボードが同じくらいの価格で売られてるのでオリジナル製品ではないんじゃないかな。

激安DACをRaspberryPi Zero Wにつなぐ 1
輸送がヤマトのクロネコDM便だったので届いたのは発送から3日後(発送日込み4日)かかった。送料が安いのはいいんだけど遅いからDM便は嫌いよ。

激安DACをRaspberryPi Zero Wにつなぐ 2
中身はA5(A4の半分)の納品書とプチプチに包まれた基板だけ。説明書やその他付属品は無し。写真に写っている右の方のピンク色のは大きさ比較用のDVD-R(ケース入り)。

激安DACをRaspberryPi Zero Wにつなぐ 3
プチプチを剥がすと静電気防止の袋が出てきた。

激安DACをRaspberryPi Zero Wにつなぐ 4
基板の部品が実装されているオモテ面。良い感じ。千円前後の基板には見えないよね。

激安DACをRaspberryPi Zero Wにつなぐ DACチップ
基板の中央にDACチップのPCM5102Aがある。他の写真を撮ったカメラSony RX100にはチップの文字が写ってくれないのでスマホで撮影。

激安DACをRaspberryPi Zero Wにつなぐ 5
ウラ面は部品が無いこともあってショボい。

激安DACをRaspberryPi Zero Wにつなぐ 6
RaspberryPi Zero(W)と並べてみた。DAC基板だけの時はRaspberryPi Zeroよりだいぶ大きく見えたけど、横幅なんかRaspberryPi Zeroより短いのね。RaspberryPi Zero専用じゃないから四隅の穴の位置は合わない。穴の径も違うし。

激安DACをRaspberryPi Zero Wにつなぐ 7
RaspberryPi Zero(W)とつなぐにはジャンパーケーブル(写真右)をRaspberryPi Zeroの基板に直接ハンダ付けするという方法もあるけど、ピンヘッダ(写真上段)を付けちゃった方が後が楽。

激安DACをRaspberryPi Zero Wにつなぐ 8
RaspberryPi Zeroにピンヘッダを付けた。ハンダ付けは40箇所になるので近視兼老眼の進んだオッサンにはツラい作業。ハンダはたっぷり派ではないのでチョビ付け。ピンヘッダは2列のものを付けようとすると意外と苦労するので1列20ピンを奥側にハンダ付けしてから手前もというやり方の方が良いと思う。ただし片列のピンが斜めになると今後いつかピンソケットを被せたいという時に嵌まらないかもなのでまっすぐに付けるのだけ注意。

激安DACをRaspberryPi Zero Wにつなぐ 9
写真はピンボケ。ピンヘッダは一応2列とも並行にまっすぐ取り付けることができた。

激安DACをRaspberryPi Zero Wにつなぐ ピンレイアウト
NorthFlatJapanの商品ページにRaspberryPi3との接続写真兼接続図が載っている。RaspberryPiの40ピンのGPIOは互換なのでRaspberryPi Zero(W)でも同じ接続でいける。GNDは商品ページの接続図では39ピンを使っているけどジャンパーケーブルの長さの関係で今回は6番ピンにつないだ。問題は無い筈。
結線が1つ足りない気がしたが、マスタークロックはこの基板のDACチップでは要らないらしいので5本でOK、マスタークロックが無いRaspberryPiにつなぐならちょうどいいのかな？

激安DACをRaspberryPi Zero Wにつなぐ 10
実際につないだらこんな感じ。ジャンパーケーブルはもう少し長めの方が良かったかも。

激安DACをRaspberryPi Zero Wにつなぐ 11
RPi0Wに電源を投入したらDAC基板の赤LEDが光った。(写真では白っぽいピンクに写ってるけど目で見ると赤)
基板上のディップスイッチは2つ共にオフ(初期値)のまま。
RCAで接続する音響機器は持っていないので手持ちのイヤホンを繋いだ。
さて、もうフリスクの容器には収まらないのでRaspberryPi ZeroとDAC基板のケースはどうしようかしら。

2018年7月16日追記:
RCA出力の場合だけときどき高い音で「ｷｰｰｰﾝ」と鳴り続けることがあって気になっていたが、どうやら周辺環境の影響を受けやすいらしい。ｷｰﾝ音がする場合は設置場所を変えるとかオーディオケーブル・電源ケーブルの引き回しを変えるなどで改善すると思われる。ラズパイなどの基板は至近にあっても影響は無さげ。ヘッドホン出力ではｷｰﾝ音は鳴らないのは何でかしら。

次は音楽プレーヤーの設定の予定。

関連記事:

Let's EncryptでECDSAな証明書

この記事の後にcertbotでオプション指定でECDSAな証明書が作成/更新可能になったので以下の手順は不要になっています。
certbotを使いLet's EncryptでECDSAな証明書を作る 2022年

個人的にはウェブサーバー用のSSL証明書はLet's Encryptを使うことが増えている。無料だからってだけでなくACME(クライアントのCertbot等)による証明書の新規発行・更新がアホみたいに簡単で楽だから。
同時に、SSLの証明書はそろそろRSAでなくECCなものにしたいという希望があるのだが、certbotにはRSA/ECCの切り替えオプションのようなものが無いみたい。
でも、Let's EncryptでECC(ECDSA)な証明書が発行できないわけではならしい

どうするか？

以前のECDSAな証明書の発行の記事の証明書発行手順で考えると、ECDSA用のCSRを認証局に送ったらECDSAな証明書を発行して貰えたわけだから、certbotを使う場合でもECDSA用のCSRを読ませて処理させれば良いってことになるよね。で、certbotにはたしかCSRファイルを指定するオプションがあった筈。

鍵(P-256)の作成
% openssl ecparam -name prime256v1 -genkey -out server.key
CSRの作成
% openssl req -new -sha256 -key server.key -out server.csr
certbotを使った証明書の発行
% /usr/local/bin/certbot certonly -w ウェブのドキュメントルート -d ドメイン/サブザメイン --csr 作成したCSRファイル --agree-tos --non-interactive --webroot --cert-path 発行したい証明書(単独)ファイル --fullchain-path 発行したい証明書(フルチェーン)ファイル

すでにcertbotで自動更新しているドメインでやるならcertbot delete等で、そのドメインを消しておいた方が良いかも。

Let's Encryptの証明書は3ヶ月で期限切れになるので頻繁な更新が必要。もちろん手動更新なんてやってられないので自動化させたい。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
#!/bin/sh

domain="example.com"
webroot="/usr/local/www/example.com"
certpath="/usr/local/etc/nginx/ssl/example.com"

rm ${certpath}/server.pem
rm ${certpath}/fullchain.pem

/usr/local/bin/certbot certonly -w ${webroot} -d ${domain} --csr ${certpath}/server.csr --agree-tos --non-interactive --webroot --cert-path ${certpath}/server.pem --fullchain-path ${certpath}/fullchain.pem
cp ${certpath}/server.pem ${certpath}/public/
cp ${certpath}/fullchain.pem ${certpath}/public/
/usr/sbin/service nginx restart

こんな感じ。
最後の行はFreeBSDでNginxを再起動するコマンド。

これだとドメイン毎にスクリプトファイルを用意しないといけないので1つのスクリプトファイルを複数ドメインで使いまわしたいなら引数$1 $2などを使ったスクリプトに修正すればOK。
あと、上のスクリプトはCSRが使いまわしになるのでそれが気に入らなければCSR作成コマンドも入れる。
Webサーバなどの設定で証明書ファイルとして指定するのは${certpath}/public/にあるファイル。上のスクリプトでは更新に失敗すると${certpath}内の証明書が存在しない状態になるのでそれを指定したWebサーバを起動・再起動しようとすると失敗する。${certpath}/public/内には証明書が存在し続ける筈なので更新失敗による期限切れはあっても証明書が存在しないことによる起動失敗はない。
これを2ヶ月毎程度の頻度でcronで動かす。頻繁に動かすと発行制限食らうので注意。

ウェブサーバ側の設定はECDSAな証明書の発行の記事のままでいける筈。

HPKP

HPKPのピンはCSRを固定(使い回し)なら変わらないのでピン再作成は必要ない。CAに署名して貰った証明書のピンもCSRのピンと同じになる。
CSRからピンを作成する場合。

% openssl req -pubkey < server.csr | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64

サーバー証明書からピンを作成する場合。
% openssl x509 -pubkey < server.pem | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64

ついでに。

Let's Encrypt Authority X3のピン: (2017年12月現在)
pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="


DST Root CA X3のピン: (2017年12月現在)
pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys="

2018年6月10日追記:
HPKPはもはや採用するべきではないでしょう。糞扱いされて主要ブラウザの非サポート化も進行中です。

代替技術(仕様)としてはCertificate Transparency(CT 証明書の透明性)が筋だろうけど面倒なのでHPKPとは別の面で質が悪い気がします。HPKPの代替にはなりえませんがDNS CAAあたりでお茶を濁すのが簡単でよろしいかと。

2020年1月27日追記:
CA側でCertificate Transparency対応が進んで、CAが証明書にSCTを埋め込んで発行するというのが当たり前になったので、もはやCTは全く面倒ではありません。証明書の更新以外にウェブサイトの管理者の手間になるものはありません。任意でExpect-CTレスポンスヘッダを付けるくらい？

関連記事:
Up