コグノスケ

カーナビを買いました

一昨年にカーナビが壊れて（2017年 9月 3日の日記参照）以来、カーナビを使わず過ごしていました。大阪、東京では車に乗らないし、あまり困りませんでしたが、先日遠出したとき道がわからなくなって、適当に大きな道を走っていたら渋滞に巻き込まれ難儀しました。

以前使っていた Panasonic Strada Pocket CN-SP700L-K は、なかなか良かったですが、シリーズごと廃止されて後継機がありません。

前回お世話になったお礼もこめて、同メーカーである Panasonic Gorilla を購入しました。CN-G1300VD という一番良いグレードの製品を選びました。Amazon で 47,000円くらいです。

今日、さっそく設置して、1〜2時間走りつつ、帰りはナビ機能も使ってみたんですけど、残念ながら「これは売れないだろうな」というのが正直な感想でした。

製品の名誉のために書いておくと、製品に欠陥はありません。各機能はいたって正常に動きます。

まるで成長していない……

では何がダメかというと「10年前」の仕様のまま時が止まってることです。正直 10年前に買った Strada Pocket と何が変わったのかわかりません。

使ってすぐに気づく欠点は 2つあります。

地図スクロールが遅い

触って真っ先に気づきます。スマホと比較すると天と地の差です。カーナビは 10年の間、スマホの何を見ていたんだ？

昔はスタンダードだった「拡大」「縮小」ボタン方式も、2本指のピンチ操作が当然となった今、逆に戸惑います。ちょうど良い拡大倍率にならなくてイライラします。

検索機能が弱い

「地名の検索」「施設名の検索」が別で、なぜか同時に検索できません。不思議仕様です。

間違って地名検索モードで、近所の大鳥居駅（京急の駅）を探そうとしたところ、千葉だとか滋賀だかの大鳥居という地名がワサワサ出てきて「？」で一杯でした。

読みを「前方一致で」正確に入れなければ候補に出ない点も、今時としては辛いです。うろ覚えの場所が探せません。

冗談みたいな話ですが、Google で検索して、目的地の電話番号を調べて、カーナビに電話番号を入力する方法が一番早いです。この状態で何年放置したのでしょうか。非常にマズいと思います。

10年前は普通でしたが、今や欠点に成り下がっている点もあります。

文字入力がショボい

せっかくタッチパネルなのに、フリック入力も、2タッチ入力も、一切何もありません。カーナビは 10年の間……もういいか。

あいうえお表で入力しなければなりません。ドラクエのパスワード入力画面みたいで、すごいイライラします。

解像度が低い

2019年の製品で WVGA（800x480）ですよ？カタログを二度見しました。

型落ちの格安スマホでも HD（1440x720）は当たり前だと思いますが、これ本当に 5万円近くするカーナビなの……？

車関連の会社に転職したおかげで、車向けの製品はおいそれと設計変更できないことは良く分かっていますが、それにしても時代遅れです。私に言われるまでもなくメーカー側もわかっているとは思いますが、このままだとポータブルカーナビは滅びさるでしょう。

メモ: 技術系の話は Facebook から転記しておくことにした。全体的に小修正。

ROCKPro64 とアナログオーディオ - その 3 - DAC ボリュームの仕様？

目次: ROCK64/ROCKPro64 - まとめリンク

引き続き ROCKPro64 のアナログオーディオと闘っています。ROCKPro64 には RK3399 という SoC と Everest ES8316 という DAC/ADC が搭載されています。

ES8316 のドライバは既に linux-next に存在しており、ボリューム調整の機能も実装済みです。ボリューム調整は alsamixer を使うと便利です。CUI ながら、下記のように GUI 風に表示されます。

Headphone（左端）と Headphone Mixer（左から 2番目）ボリューム

Headphone Mixer（左から 2番目）ボリュームの設定値は先日（2019年 8月 31日の日記参照）直しましたので、最大値にしても問題ありません。ただし、まだ linux の upstream ツリーには取り込まれていないので、5.3 か 5.4 を待たなければなりません。

今回、問題を見つけたのは、ずっと右の方にある DAC というボリュームです。初期値はおそらく最大値である 100（= 0dB）になっていると思います。

おそらく HW の仕様だと思いますが、ボリュームの挙動がちょっとおかしく、0dB にすると波形が歪みます。

出力波形を見る

テストデータとしてサンプリング周波数 48kHz で 8kHz の矩形波を使います。まずは DAC ボリューム最大で試します。

ES8316 8kHz 矩形波（Fs = 48kHz）、DAC ボリューム 0.0dB

矩形波の周波数が 1/6 Fs の場合、矩形波の天辺は緩やかに波打つはずです。しかし ES8316 の場合、頭打ちするのか、ギザギザになってしまいます。

周波数が 1/6 Fs の場合の波形（2014年 11月 25日の日記より）

ここで DAC ボリュームをわずかに下げてみます。

DAC ボリュームを -2.0dB に変更

音量的にはほとんど変わりませんが、波形はかなり綺麗になります。ちなみに私の耳では聞き比べても全く違いを感じません。オシロスコープ様で見ないとわからないです……。

お試しいただく際の注意点ですが、8kHz の矩形波は中途半端に高い「キィーーン」という音で、かなり不快な部類の音に入ります。あまり長く聴かない方が良いと思います。

ES8316 8kHz 矩形波（Fs = 48kHz）、DAC ボリューム -2.0dB

SoC 側から出力しているクロック、I2S データともに全く同じなので、DAC ボリューム最大で波形が歪むのは ES8316 の特性でしょう。おそらく。

音質に少しでもこだわりたい人は DAC ボリュームは -2.0dB で運用するのが良さそうです。音量調整の手段は Headphone や Headphone Mixer がありますし、そちらの 2つはボリューム Max にしても波形が歪まないので、お勧めです。

ROCKPro64 対 ONKYO で Sin 波の美しさ勝負

目次: ROCK64/ROCKPro64 - まとめリンク

最近 linux-next で ROCKPro64 のアナログオーディオ出力を使いたくて、色々やっています。デバッグの都合上、ROCKPro64 の DAC/ADC である Everest ES8316 の出力波形をオシロスコープで見ることが多いです。

私が音楽を聴く程度では、特に何も思いませんが、オシロスコープで見てしまうと、波形がやや歪んでいることに気づいてしまいます。

我が家で一番の波形の綺麗さを誇る ONKYO U33GXV2 と比較してみたいと思います。

テストその 1 - 48kHz Sin 波

最初はサンプリング周波数（以降 Fs と書く）= 96kHz のときの、48kHz Sin 波を入力してみます。振幅は最小から最大です。

まずは ES8316 から。DAC ボリュームを最大にすると波形が歪む（2019年 9月 6日の日記参照）ので、今回の計測では -2.0dB に設定しています。

Everest ES8316 48kHz Sin 波（Fs = 96kHz）

U33GXV2 だとこんな感じです。

ONKYO U33GXV2 48kHz Sin 波（Fs = 96kHz）

雲泥の差というほどでもないですが、ONKYO はやっぱり歪みが少なくて綺麗ですね。

テストその 2 - 24kHz Sin 波

上記の比較をしたあとに気づいたのですが、ES8316 は Fs を 50kHz 以上にする場合、異なるモードに設定しなければならないらしく、linux-next はその設定に対応していませんでした。

つまり ES8316 側は設定不足で不利な状態にあり、公平な比較ではなかったようです。というわけで、次はサポートの範囲内である Fs = 48kHz の 24kHz Sin 波で比較しようと思います。

Everest ES8316 24kHz Sin 波（Fs = 48kHz）

時間分解能の設定のせいかもしれませんが、先ほどより歪んでいるように見えます。Sin 波と三角波の間のような波形になっています。

ONKYO U33GXV2 24kHz Sin 波（Fs = 48kHz）

こちらは歪みが見当たらない（少なくとも私のオシロでは）レベルです。さすがですね……。

台風 15号

超強力な台風 15号（Faxai）が来るということで、家でじっとしていました。

家

我が家は北と東に窓がありまして、北側の窓にガンガン風と雨が吹き付けていました。あまりの風圧にサッシが耐えらず、雨が窓サッシの隙間から霧吹きのように吹き出していました。途中で気づいてテープや紙で抑えたので、畳が水浸しになる被害は防げました。

真夜中に壁に飛来物が当たり、ものすごい音がしていました。窓の真横に当たったらしく、窓にはギリギリ当たりませんでした。窓に当たったら、窓が粉砕されていたと思います。本当に幸運でした。

後は何だろ、若干停電した程度でしょうか。特に被害はありませんでした。災害への備えは日頃からやっておいて損はないですね。

家財

台風が過ぎた後に車を見に行ってみましたが、特に飛来物が当たった形跡もなく、何ともなかったです。良かった良かった。

今まで知らなかった make の挙動

シェルから make に渡す環境変数と make 変数の関係を知らなくて、かなりハマったのでメモしておきます。

まず、どういう関係か説明します。下記のような Makefile を 2つ用意します。

$ tree
.
|-- Makefile
`-- sub
    `-- Makefile

VAR_A = aaa
VAR_B = bbb

all:
	@echo "In parent"
	@echo "VAR_A: '$(VAR_A)'"
	@echo "VAR_B: '$(VAR_B)'"
	@echo "VAR_C: '$(VAR_C)'"
	make -C sub

all:
	@echo "In sub"
	@echo "VAR_A: '$(VAR_A)'"
	@echo "VAR_B: '$(VAR_B)'"
	@echo "VAR_C: '$(VAR_C)'"

親 Makefile は変数 VAR_A, VAR_B を書き換え、子 sub/Makefile を再帰的に呼び出します。各 Makefile では変数の値を表示しています。

では、トップディレクトリにて make を実行してみましょう。

$ make
In parent
VAR_A: 'aaa'    ★VAR_A は設定した値になっている★
VAR_B: 'bbb'    ★VAR_B は設定した値になっている★
VAR_C: ''       ★VAR_C は特に書き換えていないので空★
make -C sub
make[1]: Entering directory '/home/katsuhiro/share/falcon/projects/c/makefile_env_var/sub'
In sub
VAR_A: ''    ★VAR_A は渡されない★
VAR_B: ''    ★VAR_B は渡されない★
VAR_C: ''    ★VAR_C は渡されない★
make[1]: Leaving directory '/home/katsuhiro/share/falcon/projects/c/makefile_env_var/sub'

ご覧の通り、親の Makefile で値を設定した VAR_A や VAR_B といった変数は、子の sub/Makefile に「引き継がれません」。

make 変数の渡し方

外部から make に変数を渡すには、下記の 2つの方法があります。

• 環境変数として渡す方法。例: VAR_A=A make
• make に渡す方法。例: make VAR_A=A

私は今まで、この 2つの渡し方に何も差はないと思っていたのですが、実は全く動きが違いました。

環境変数の場合

下記のように VAR_A, VAR_C を環境変数として与えると、子 Makefile 側の結果がかなり変わります。

$ VAR_A=A VAR_C=C make
In parent
VAR_A: 'aaa'    ★VAR_A は親が設定した値になる★
VAR_B: 'bbb'
VAR_C: 'C'      ★VAR_C は特に書き換えていないので、渡された値のまま★
make -C sub
make[1]: Entering directory '/home/katsuhiro/share/falcon/projects/c/makefile_env_var/sub'
In sub
VAR_A: 'aaa'    ★VAR_A が渡される、A ではなく親が設定した値 aaa になっている★
VAR_B: ''
VAR_C: 'C'      ★VAR_C が渡される、値は変わらず★
make[1]: Leaving directory '/home/katsuhiro/share/falcon/projects/c/makefile_env_var/sub'

何も渡さなかった場合の実行結果と異なり、子の sub/Makefile にも VAR_A, VAR_C が渡されます。もし、親 Makefile が変数の値を書き換えた場合は、書き換えた値が子 Makefile に渡されます。

この動作は知りませんでした。特に子プロセスへの変数の渡し方が変わる点が衝撃的です。

make に渡す場合

下記のように VAR_A, VAR_C を make に渡すと、環境変数として渡す場合とは違う結果になります。

$ make VAR_A=A VAR_C=C
In parent
VAR_A: 'A'      ★VAR_A は親が設定した値にならない★
VAR_B: 'bbb'
VAR_C: 'C'
make -C sub
make[1]: Entering directory '/home/katsuhiro/share/falcon/projects/c/makefile_env_var/sub'
In sub
VAR_A: 'A'      ★VAR_A が渡される、VAR_A は親が設定した値にならない★
VAR_B: ''
VAR_C: 'C'      ★VAR_C が渡される、値は変わらず★
make[1]: Leaving directory '/home/katsuhiro/share/falcon/projects/c/makefile_env_var/sub'

環境変数で渡した場合と同様に、子 Makefile に変数の内容が渡されます。その点は同じです。しかし、親 Makefile で行っている aaa という値の代入が無効化され、渡される値が全く違います。

この動作も知りませんでした……。私は Makefile や make とは長い付き合いですし、動きも何となくわかっていた気分になっていましたが、勘違いだったようです。make は難しすぎます。

ハマったポイント

この動きによって、何が困ったかを紹介しておきます。同じ状況に陥る人は、まずもっていないと思いますけど、ご参考まで。

現象としては「make でビルドすると成功するが、debuild（Debian のパッケージング作成スクリプト）経由でビルドすると失敗する」です。この現象から原因が予想できた人、あなたは凄い（少なくとも私より凄い）です！この先は読む必要はございません。

下記のような感じの、ちょっと変わった Makefile を使っているソフトウェアをビルドしていました。

• 親 Makefile から、子の ./configure を呼ぶ
• 親 Makefile は CFLAGS や LDFLAGS を固定値に設定している（固有のライブラリをリンクするため）

もう一つ大事な点は、親 Makefile が使っている LDFLAGS を、子 ./configure に渡すと「そんなライブラリはないというエラー」になってしまう欠点があることです。

じゃあビルドエラーが起きるのか？というとそうではなく、先ほどご紹介した通り、何も指定せずに make を起動すれば、親 Makefile の変数は、子 ./configure に渡りませんから、make だけ実行すればエラーを起こさずビルドできるのです。

debuild と環境変数の罠

一見、正常にビルドできて問題ないように見えますが、このソフトウェアを *.deb にパッケージングしようとするとハマります。Debian のパッケージ作成スクリプト debuild は下記のような動作をするからです。

• debuild はエラーチェック、セキュリティ強化のため CFLAGS, LDFLAGS にいくつかオプションを指定する
• CFLAGS, LDFLAGS は「環境変数」で make に渡される

そろそろ何が起きるか予想が付くでしょう。そう、こうなるんです。

• debuild が、親 Makefile に環境変数で CFLAGS, LDFLAGS を渡す
• 親 Makefile が CFLAGS, LDFLAGS を書き換える
• 親 Makefile が、子 ./configure に書き換わった後の CFLAGS, LDFLAGS を渡す

この華麗なコンボが決まって、make とするとビルドが成功し、debuild 経由だとビルドが失敗する、謎のビルド環境ができあがります。

感想

こんなバグ、初見で分かる、はずもなし。

Makefile は大抵の人には難しすぎます。Makefile を手で書いているといつか地獄に落ちますよ、CMake とか automake を使いましょう。便利だよ！

linux-next が久しぶりに更新された

ここしばらく更新されていなかった linux-next が約 10日ぶりに更新（9/4 の次が 9/15）されたので、喜んで git fetch して Tinker Board のカーネルを書き換えたところ、ウンともスンとも言わなくなってしまいました。

質の悪いことにエラーメッセージも何も出さずにハングアップするため、起動しなくなった原因がさっぱりわかりません。

仕方ないので頑張って git bisect し、起動しなくなった原因のコミットを見つけましたが、実は 9/17 に LKML にて既に指摘済みで、直し方まで検討されていました（LKML へのリンク）。今までの苦労は何だったのか。

結果だけ見ると、最初に LKML のメールスレッドに気づいていれば bisect なんて不要でした。しかし、一切エラーメッセージを出さずにハングするので、検索のヒントがありません。ノーヒントで LKML の当該メールスレッドを探せたか？と考えてみると、ちょっと難しい気がします。

いわゆる鶏と卵の問題ですね……。