目次: apt
Packagesには各Debianパッケージのハッシュ値が記述されていて、悪意ある者がDebianパッケージを改変しても検知できるようになっています。ReleaseにはPackagesのハッシュ値が記述されていて、Packagesを改変されても検知できるようになっています。
Releaseの改変に対しては、サーバーの作成者が署名を付け、Releaseが作成時から改変されていないことを保証します。
パッケージ(*.deb) <--(ハッシュ値)-- Packages <--(ハッシュ値)-- Release <--(署名)-- InReleaseもしくはRelease.gpg
保証の関係を図示すると上記のとおりです。前回のapt-get updateのエラーメッセージはInReleaseもしくはRelease.gpgが存在しない、もしくは、あっても信頼できない署名だと言って怒っているのです。
最初からapt-getに信頼されている鍵は公式サーバーが使っている鍵ですが、当然ながら私は知りません。ですので、
という手順を取ります。
# gpg --gen-key gpg (GnuPG) 2.2.12; Copyright (C) 2018 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Note: Use "gpg --full-generate-key" for a full featured key generation dialog. GnuPG needs to construct a user ID to identify your key. Real name: ...
名前やメールアドレスを聞かれるので適宜答えてください。途中でパスフレーズを聞かれます。今回はテストなので、名前はTest User、パスフレーズはabcd1234にしました。
自作した鍵をaptに信用してもらうには、公開鍵(秘密鍵ではありません)をaptの信頼済み鍵束に登録します。
# gpg --list-keys /root/.gnupg/pubring.kbx ------------------------ pub rsa3072 2019-08-11 [SC] [expires: 2021-08-10] A24D479395FF7F2B4A787D29439D445DCA4AF8F6 ★このIDを指定する uid [ultimate] Test User sub rsa3072 2019-08-11 [E] [expires: 2021-08-10] # mkdir /var/www/linux/debian/gpg # gpg --export A24D479395FF7F2B4A787D29439D445DCA4AF8F6 > /var/www/linux/debian/gpg/public.key # curl http://192.168.1.1/linux/debian/gpg/public.key | apt-key add - # apt-key list /etc/apt/trusted.gpg -------------------- pub rsa3072 2019-08-11 [SC] [expires: 2021-08-10] A24D 4793 95FF 7F2B 4A78 7D29 439D 445D CA4A F8F6 ★自作の鍵が追加された uid [ unknown] Test User sub rsa3072 2019-08-11 [E] [expires: 2021-08-10] /etc/apt/trusted.gpg.d/debian-archive-buster-automatic.gpg ---------------------------------------------------------- pub rsa4096 2019-04-14 [SC] [expires: 2027-04-12] 80D1 5823 B7FD 1561 F9F7 BCDD DC30 D7C2 3CBB ABEE uid [ unknown] Debian Archive Automatic Signing Key (10/buster) <ftpmaster@debian.org> sub rsa4096 2019-04-14 [S] [expires: 2027-04-12] /etc/apt/trusted.gpg.d/debian-archive-buster-security-automatic.gpg ------------------------------------------------------------------- pub rsa4096 2019-04-14 [SC] [expires: 2027-04-12] 5E61 B217 265D A980 7A23 C5FF 4DFA B270 CAA9 6DFA uid [ unknown] Debian Security Archive Automatic Signing Key (10/buster) <ftpmaster@debian.org> sub rsa4096 2019-04-14 [S] [expires: 2027-04-12] ...
自分で作った鍵ペアのうち、公開鍵をgpg --exportでファイルにエクスポートし、HTTPサーバーに配置します。公開鍵ファイルをapt-key addで信頼済みの鍵束に追加します。
今回作成した鍵はテストが終わったら不要なのでapt-key del ’キーID’ で削除してください。apt-key listで出てきたキーIDをコピペすれば良いです(スペースもそのまま入れてOK)。
最後にReleaseファイルに署名します。Releaseファイルの署名には2種類あって、署名をReleaseファイルと一緒に書くInReleaseファイルと、署名だけを別に書くRelease.gpgファイルがあります。
InReleaseだけ作成すれば機能するようですが、とりあえず両方の作り方を紹介しておきます。
### GnuPGでReleaseファイルに署名
# echo -n "abcd1234" | gpg --batch --passphrase-fd 0 --pinentry-mode loopback --clearsign -o InRelease Release
# echo -n "abcd1234" | gpg --batch --passphrase-fd 0 --pinentry-mode loopback -abs -o Release.gpg Release
# chmod 644 Release InRelease Release.gpg
署名が完了したらapt-get updateしてみましょう。
# apt-get update Get:1 http://192.168.1.1/linux/debian buster InRelease [3941 B] Hit:2 http://ftp.jp.debian.org/debian testing InRelease Get:3 http://192.168.1.1/linux/debian buster/stable amd64 Packages [1752 B] Get:4 http://192.168.1.1/linux/debian buster/stable amd64 Contents (deb) [1242 B] Fetched 6935 B in 0s (25.7 kB/s) Reading package lists... Done
うまくいきました。apt-get install docker-ceを実行すると、、、
# apt-get install docker-ce Reading package lists... Done Building dependency tree Reading state information... Done Package docker-ce is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: docker-ce-cli E: Package 'docker-ce' has no installation candidate
どうやら依存関係を無視してDockerのパッケージを1つしか登録しなかったため、依存関係のエラーが出てしまったようです。
他のパッケージ(docker-ce_cli, container.io)もダウンロードしましょう。pool/stable/amd64の下に追加し、apt-ftparchiveと署名をやり直します。
linux |-- conf | |-- apt_generate_debian_buster.conf | `-- apt_release_debian_buster.conf `-- debian |-- dists | `-- buster | |-- InRelease | |-- Release | |-- Release.gpg | |-- packages-amd64.db | |-- pool | | `-- stable | | `-- amd64 | | |-- containerd.io_1.2.6-3_amd64.deb | | |-- docker-ce-cli_19.03.1~3-0~debian-buster_amd64.deb | | `-- docker-ce_19.03.1~3-0~debian-buster_amd64.deb | `-- stable | |-- Contents-amd64 | |-- Contents-amd64.bz2 | |-- Contents-amd64.gz | `-- binary-amd64 | |-- Packages | |-- Packages.bz2 | `-- Packages.gz `-- gpg `-- public.key 10 directories, 16 files
以上のようなディレクトリ構成になるはずです。もう一度apt-get install docker-ceしてみましょう。
# apt-get install docker-ce Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: aufs-dkms aufs-tools cgroupfs-mount containerd.io docker-ce-cli Suggested packages: aufs-dev The following NEW packages will be installed: aufs-dkms aufs-tools cgroupfs-mount containerd.io docker-ce docker-ce-cli 0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/88.0 MB of archives. After this operation, 390 MB of additional disk space will be used. Do you want to continue? [Y/n] Selecting previously unselected package aufs-dkms. (Reading database ... 325385 files and directories currently installed.) Preparing to unpack .../0-aufs-dkms_4.19+20190211-1_all.deb ... Unpacking aufs-dkms (4.19+20190211-1) ... Selecting previously unselected package aufs-tools. Preparing to unpack .../1-aufs-tools_1%3a4.14+20190211-1_amd64.deb ... Unpacking aufs-tools (1:4.14+20190211-1) ... Selecting previously unselected package cgroupfs-mount. Preparing to unpack .../2-cgroupfs-mount_1.4_all.deb ... Unpacking cgroupfs-mount (1.4) ... Selecting previously unselected package containerd.io. Preparing to unpack .../3-containerd.io_1.2.6-3_amd64.deb ... Unpacking containerd.io (1.2.6-3) ... Selecting previously unselected package docker-ce-cli. Preparing to unpack .../4-docker-ce-cli_5%3a19.03.1~3-0~debian-buster_amd64.deb ... Unpacking docker-ce-cli (5:19.03.1~3-0~debian-buster) ... Selecting previously unselected package docker-ce. Preparing to unpack .../5-docker-ce_5%3a19.03.1~3-0~debian-buster_amd64.deb ... Unpacking docker-ce (5:19.03.1~3-0~debian-buster) ... Setting up aufs-tools (1:4.14+20190211-1) ... Setting up containerd.io (1.2.6-3) ... Created symlink /etc/systemd/system/multi-user.target.wants/containerd.service -> /lib/systemd/system/containerd.service. Setting up docker-ce-cli (5:19.03.1~3-0~debian-buster) ... Setting up aufs-dkms (4.19+20190211-1) ... Loading new aufs-4.19+20190211 DKMS files... Building for 4.19.0-5-amd64 Building initial module for 4.19.0-5-amd64 Done. ...
以上のようにapt-getもうまくいきました。良かった良かった。
目次: apt
まとめです。
ディレクトリ構成は下記のとおりです。Dockerのパッケージサーバーを参考(リンク)にしています。
linux |-- conf | |-- apt_generate_debian_buster.conf | `-- apt_release_debian_buster.conf `-- debian |-- dists | `-- buster | |-- InRelease | |-- Release | |-- Release.gpg | |-- packages-amd64.db | |-- pool | | `-- stable | | `-- amd64 | | |-- containerd.io_1.2.6-3_amd64.deb | | |-- docker-ce-cli_19.03.1~3-0~debian-buster_amd64.deb | | `-- docker-ce_19.03.1~3-0~debian-buster_amd64.deb | `-- stable | |-- Contents-amd64 | |-- Contents-amd64.bz2 | |-- Contents-amd64.gz | `-- binary-amd64 | |-- Packages | |-- Packages.bz2 | `-- Packages.gz `-- gpg `-- public.key 10 directories, 16 files
パッケージの情報ファイルを作成するapt-ftparchiveの設定ファイルは2種類あり、下記のとおりです。
Dir::ArchiveDir ".";
Dir::CacheDir "dists/buster";
Default::Packages::Compress ". gzip bzip2";
Default::Packages::Extensions ".deb";
Default::Sources::Compress ". gzip bzip2";
Default::Contents::Compress ". gzip bzip2";
Default::FileMode 0644;
TreeDefault::Directory "dists/buster/pool/stable/stable/amd64";
TreeDefault::Packages "dists/buster/stable/binary-amd64/Packages";
Tree "dists/buster" {
Sections "stable";
Architectures "amd64";
};
BinDirectory "dists/buster/stable/binary-amd64" {
Packages "dists/buster/stable/binary-amd64/Packages";
Contents "dists/buster/stable/Contents-amd64";
};
APT::FTPArchive::Release {
Architectures "amd64";
Components "stable";
Label "Test Label";
Origin "Test";
Suite "buster";
};
Tree::Sections, Tree::Architecturesに複数の値を指定したとき、他の設定をどのように書けばよいのか?についてはこれからの課題ですね。
設定ファイルを作ったらapt-ftparchiveコマンドを実行し、Releaseファイルに署名します。
export TARGET=debian
export DIST=buster
export SECT=stable
export ARCH=amd64
mkdir -p /var/www/linux/${TARGET}/dists/${DIST}/${SECT}/binary-${ARCH}
mkdir -p /var/www/linux/${TARGET}/dists/${DIST}/pool/${SECT}/${ARCH}
# *.debファイルをコピーする(モジュールによってコピー元は違うと思うので、これは一例)
# cp *.deb /var/www/linux/${TARGET}/dists/${DIST}/pool/${SECT}/${ARCH}
# Packages, Contentsファイルを作る
# linux/debianの下でapt-ftparchiveを実行しないと *.debが見つからないといわれる
cd /var/www/linux/${TARGET}
find . -name "Contents-*" -or -name "Contents-*.*" | xargs rm -f
find . -name "Packages" -or -name "Packages.*" -or -name "packages-*" | xargs rm -f
find . -name Release -or -name Release.gpg -or -name InRelease | xargs rm -f
apt-ftparchive generate ../conf/apt_generate_${TARGET}_${DIST}.conf
# Releaseファイルを作る
# linux/debian/dists/busterの下でapt-ftparchiveを実行しないと、
# 後ほどapt-getを実行した際にパッケージが見つからないといわれる
cd /var/www/linux/${TARGET}/dists/${DIST}
apt-ftparchive release -c=../../../conf/apt_release_${TARGET}_${DIST}.conf . > Release
# GnuPGでReleaseファイルに署名
echo -n "abcd1234" | gpg --batch --passphrase-fd 0 --pinentry-mode loopback --clearsign -o InRelease Release
echo -n "abcd1234" | gpg --batch --passphrase-fd 0 --pinentry-mode loopback -abs -o Release.gpg Release
chmod 644 Release InRelease Release.gpg
GnuPGの鍵ファイルの作成と、aptへの登録方法については、その3をご参照ください。
スマホを買い替えました。Zenfone 6が出るとか出ないとか言われているなか、あえて型落ちのZenfone 4 (ZE554KL) を買いました。Amazonで32,000円でした。
高性能処理が必要なゲームなどはしませんし、CPU/GPUともに最高性能のいわゆるハイエンド機種は不要です。ハイエンド機は値段も高いですし……。
CPU/GPUはそこそこで電池持ちが良く、メモリが多くて動作が快適な、いわゆるミドルハイと呼ばれる機種が欲しいのですが、世の中的に人気がないらしく、作ってくれるメーカーはどんどん減っています。
最初はZenfone 5の購入を検討していましたが、ASUSもZenfone 5からミドルハイ(Snapdragon 66xクラス)の機種を出さなくなったようで、購入したい機種がありませんでした。
そんななか、Zenfone 4はSnapdragon 660と6GB RAM搭載で、ドンピシャの機種でした。もう今後、このタイプのミドルハイ機種は出ないかもしれないですねえ。
今日Zenfone 4が家に届いたのですが、SIMカードがnano-SIMしか対応していませんでした。
現在使っているZenfone 3 Deluxe 5.5 (ZS550KL) はmicro-SIMなので、そのまま差し替えという訳にはいきません。困ったなあ。
ドコモショップに行かないとnano-SIMは手に入らないようです。ドコモショップは行きたくないんだけど、今回ばかりは仕方ないか……。
メモ: 技術系の話はFacebookから転記しておくことにした。
目次: ROCK64/ROCKPro64
ROCKPro64でRockchipの公開しているLinux(以降、Rockchip Linux)ではヘッドフォン出力できるのに、linux-nextだとできないのはどうして?と思って調べていたところ、悲しいことがわかりました……。
ROCKPro64はEverest ES8316というDACを搭載しています。ドライバはsound/soc/codecs/es8316.cです。なんとこのドライバはですね、Rockchip Linuxに実装されているドライバ(Rockchipの人が書いた)と、linux-nextのドライバ(Everestの人がUpstreamした)が全然違う実装になっています。
ES8316のドライバが全く違うお陰で、Rockchip Linuxからdevicetreeを持ってきてもウンともスンとも言わないのです。まさかES8316のドライバ実装が全く違なんて想像していませんでした。どうしてこんなことに……。
しばらく戦ってみましたが、linux-nextのES8316ドライバの動きは良くわかりませんでした。clocksプロパティにダミーの12MHzクロックを指定すると、とりあえずドライバは文句を言わなくなるものの、肝心の音は鳴りません。
残念ながらRK3399側の問題(例えばMCLKが出力されていないなど)なのか、ES8316側の問題なのか切り分けができていません。
各端子に来ている信号をオシロスコープで見れば、原因の切り分けができるのはわかっていますが、ROCKPro64はプローブを当てることなど考慮して作っておらず、端子に名前が書いてないし、非常に細かいです。変にプローブを当てるとショートさせてしまいそうです。
AKG K240に似ていることで有名(?)なSuperlux HD681Bを買いました。Amazonで3,000円程度です。噂通り音は良いです。
残念ながら数万円する高級ヘッドフォンを使った経験はほぼないので、高級な音かどうかまではわかりません。
現在使っているaudio-technica ATH-TAD500はかなりシャリシャリ気味の音ですが、HD681Bはさらに輪をかけて高音が強いです。かなりキンキンしています。
普段聴いている音楽をHD681Bで聴いてみると、今まで聞いたことのない「キーン…、キーン…!」という音が聞こえます。こんな音鳴ってたのか…??
大きさの割に軽いし、圧迫されるような感じはしませんが、長時間使うとちょっと耳が痛くなります。
この製品に限った話ではありませんが、レザータイプのイヤーパッド(=汗を吸わない)、セミオープンエアー型(=音漏れが激しい)なので、室内用に最適だと思います。
メモ: 技術系の話はFacebookから転記しておくことにした。後半を追記。
目次: apt
前回、Tree::Sectionsには複数のセクションが指定でき、Tree::Architecturesには複数のアーキテクチャが指定できますが、TreeDefault::Packagesとの対応がよくわからない。と書きましたが、複数のセクションを同時に指定する手段が見つかったので、メモしておきたいと思います。
書き方は簡単で、前回TreeDefaultのパスに出現するセクション名をstableと決め打ちで書いていました。これを $(SECTION) に置き換えるだけです。アーキテクチャ名なら $(ARCH) です。
Dir::ArchiveDir ".";
Dir::CacheDir "dists/buster";
Default::Packages::Compress ". gzip bzip2";
Default::Packages::Extensions ".deb";
Default::Sources::Compress ". gzip bzip2";
Default::Contents::Compress ". gzip bzip2";
Default::FileMode 0644;
TreeDefault::Directory "dists/buster/pool/$(SECTION)/$(ARCH)";
TreeDefault::Packages "dists/buster/$(SECTION)/binary-$(ARCH)/Packages";
Tree "dists/buster" {
Sections "stable testing nightly";
Architectures "amd64";
};
それともう一つ差分がありまして、BinDirectoryの指定はなくても動くことがわかりましたので、削除しています。
セクションを複数指定できるようになりましたので、スクリプトも若干変わります。
export TARGET=debian
export DIST=buster
export ARCH=amd64
for SECT in stable testing nightly
do
mkdir -p /var/www/linux/${TARGET}/dists/${DIST}/${SECT}/binary-${ARCH}
mkdir -p /var/www/linux/${TARGET}/dists/${DIST}/pool/${SECT}/${ARCH}
done
### *.debファイルをコピーする(モジュールによってコピー元は違うと思うので、これは一例)
### cp *.deb /var/www/linux/${TARGET}/dists/${DIST}/pool/${SECT}/${ARCH}
### Packages, Contentsファイルを作る
### linux/debianの下でapt-ftparchiveを実行しないと *.debが見つからないといわれる
cd /var/www/linux/${TARGET}
find . -name "Contents-*" -or -name "Contents-*.*" | xargs rm -f
find . -name "Packages" -or -name "Packages.*" -or -name "packages-*" | xargs rm -f
find . -name Release -or -name Release.gpg -or -name InRelease | xargs rm -f
apt-ftparchive generate ../conf/apt_generate_${TARGET}_${DIST}.conf
### Releaseファイルを作る
### linux/debian/dists/busterの下でapt-ftparchiveを実行しないと、
### 後ほどapt-getを実行した際にパッケージが見つからないといわれる
cd /var/www/linux/${TARGET}/dists/${DIST}
apt-ftparchive release -c=../../../conf/apt_release_${TARGET}_${DIST}.conf . > Release
### Releaseファイルに署名する
echo -n "abcd1234" | gpg --batch --passphrase-fd 0 --pinentry-mode loopback --clearsign -o InRelease Release
echo -n "abcd1234" | gpg --batch --passphrase-fd 0 --pinentry-mode loopback -abs -o Release.gpg Release
chmod 644 Release InRelease Release.gpg
これで粗方、やりたかったことができたのではないかと思います。
今回もDockerのリポジトリから *.debを拝借します。セクションStableにはcontainerd.io、Testingにはdocker-ce-cli、Nightlyにはdocker-ceを配置するなど、各セクションに全く違う *.debを配置すると後で見やすいです。
# tree linux/
linux/
|-- conf
| |-- apt_generate_debian_buster.conf
| `-- apt_release_debian_buster.conf
`-- debian
|-- dists
| `-- buster
| |-- InRelease
| |-- Release
| |-- Release.gpg
| |-- nightly
| | |-- Contents-amd64
| | |-- Contents-amd64.bz2
| | |-- Contents-amd64.gz
| | `-- binary-amd64
| | |-- Packages
| | |-- Packages.bz2
| | `-- Packages.gz
| |-- packages-amd64.db
| |-- pool
| | |-- nightly
| | | `-- amd64
| | | `-- docker-ce_0.0.0-20180901050402-e5babb2-0~debian_amd64.deb
| | |-- stable
| | | `-- amd64
| | | `-- containerd.io_1.2.0-1_amd64.deb
| | `-- testing
| | `-- amd64
| | `-- docker-ce-cli_18.09.0~3-0~debian-buster_amd64.deb
| |-- stable
| | |-- Contents-amd64
| | |-- Contents-amd64.bz2
| | |-- Contents-amd64.gz
| | `-- binary-amd64
| | |-- Packages
| | |-- Packages.bz2
| | `-- Packages.gz
| `-- testing
| |-- Contents-amd64
| |-- Contents-amd64.bz2
| |-- Contents-amd64.gz
| `-- binary-amd64
| |-- Packages
| |-- Packages.bz2
| `-- Packages.gz
`-- gpg
`-- public.key
18 directories, 28 files
上記はリポジトリ情報を生成した後の状態です。各セクションの下にContentsとPackagesが生成されます。ファイルが生成できたら /etc/apt/sources.listにこのサーバーを指定して、apt-get updateを実行します。
deb [arch=amd64] http://192.168.1.1/linux/debian/ buster stable
-> containerd.ioがインストールでき、他のdocker-ce-cliやdocker-ceはインストールできないはず
deb [arch=amd64] http://192.168.1.1/linux/debian/ buster testing
-> docker-ce-cliがインストールでき、他のcontainerd.ioやdocker-ceはインストールできないはず
deb [arch=amd64] http://192.168.1.1/linux/debian/ buster nightly
-> docker-ceがインストールでき、他のcontainerd.ioやdocker-ce-cliはインストールできないはず
指定の方法は上記のとおりです。セクション名stableの部分をtestingやnightlyに入れ替えても、apt-get updateが成功すれば、複数セクションの扱いはうまくいっています。
また、セクションstableを選んだときはcontainerd.ioがインストールできて、他のものはインストールできないはずです。testingだとdocker-ce-cli、nightlyだとdocker-ceがインストールできて、他の2つはインストールできなくなります。セクション指定が機能していることがわかると思います。
目次: ROCK64/ROCKPro64
ROCKPro64に搭載されているCODEC(※)はEverest ES8316というICです。このICをlinux-nextのドライバで制御すると、異常な動作をします。
具体的には、Headphone Mixerのボリュームを5以上に変更すると、突然、ほぼ最大音量の馬鹿デカい音になり、バリバリというノイズが載ります。あまりにノイズがひどくて、聴くに堪えないレベルですし、音がうるさくてたまらないです。
ボリューム5〜7は使い物にならないようなので、ボリュームを4にリミットするパッチをLinux Kernel MLに投稿したところ、ドライバの作者が現れ「今の実装の設定値はおかしい」とアドバイスをくれました。作者曰く現在のドライバは、禁止された設定値をレジスタに書いているそうです。正しい設定値も教えてくれました。
教えていただけるのはありがたいんだけど、既に知っていたなら直してほしかったな……。さておき、正しい設定値を入れたパッチを再作成して、投稿しました。
動作テストしているときに、左右のボリュームの「効き」が反転しているバグにも気づいたので、問題を修正するパッチも合わせて投稿しました。
両パッチともに、先日Linux ASoCツリーに取り込まれたようです。このままLinux 5.3に取り込まれると思われます。良かった良かった。
(※)LinuxではI2Sなどのデジタルオーディオとアナログオーディオ間を変換するDAC/ADCをCODEC と呼びます。
確かにCode/Decodeを行うため、使い方としては合っているし、こちらの方が一般用語かもしれないが、テレビ系SoCとの関わりが深かったので、codecと言われるとMPEG2やAACのような動画像、音声圧縮展開の方を思い浮かべてしまう……。
メモ: 技術系の話はFacebookから転記しておくことにした。全体的に小修正。
一昨年にカーナビが壊れて(2017年9月3日の日記参照)以来、カーナビを使わず過ごしていました。大阪、東京では車に乗らないし、あまり困りませんでしたが、先日遠出したとき道がわからなくなって、適当に大きな道を走っていたら渋滞に巻き込まれ難儀しました。
以前使っていたPanasonic Strada Pocket CN-SP700L-Kは、なかなか良かったですが、シリーズごと廃止されて後継機がありません。
前回お世話になったお礼もこめて、同メーカーであるPanasonic Gorillaを購入しました。CN-G1300VDという一番良いグレードの製品を選びました。Amazonで47,000円くらいです。
今日、さっそく設置して、1〜2時間走りつつ、帰りはナビ機能も使ってみたんですけど、残念ながら「これは売れないだろうな」というのが正直な感想でした。
製品の名誉のために書いておくと、製品に欠陥はありません。各機能はいたって正常に動きます。
では何がダメかというと「10年前」の仕様のまま時が止まってることです。正直10年前に買ったStrada Pocketと何が変わったのかわかりません。
使ってすぐに気づく欠点は2つあります。
読みを「前方一致で」正確に入れなければ候補に出ない点も、今時としては辛いです。うろ覚えの場所が探せません。
冗談みたいな話ですが、Googleで検索して、目的地の電話番号を調べて、カーナビに電話番号を入力する方法が一番早いです。この状態で何年放置したのでしょうか。非常にマズいと思います。
10年前は普通でしたが、今や欠点に成り下がっている点もあります。
車関連の会社に転職したおかげで、車向けの製品はおいそれと設計変更できないことは良く分かっていますが、それにしても時代遅れです。私に言われるまでもなくメーカー側もわかっているとは思いますが、このままだとポータブルカーナビは滅びさるでしょう。
メモ: 技術系の話はFacebookから転記しておくことにした。全体的に小修正。
目次: 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ボリュームをわずかに下げてみます。
音量的にはほとんど変わりませんが、波形はかなり綺麗になります。ちなみに私の耳では聞き比べても全く違いを感じません。オシロスコープ様で見ないとわからないです……。
お試しいただく際の注意点ですが、8kHzの矩形波は中途半端に高い「キィーーン」という音で、かなり不快な部類の音に入ります。あまり長く聴かない方が良いと思います。
ES8316 8kHz矩形波(Fs = 48kHz)、DACボリューム -2.0dB
SoC側から出力しているクロック、I2Sデータともに全く同じなので、DACボリューム最大で波形が歪むのはES8316の特性でしょう。おそらく。
音質に少しでもこだわりたい人はDACボリュームは -2.0dBで運用するのが良さそうです。音量調整の手段はHeadphoneやHeadphone Mixerがありますし、そちらの2つはボリュームMaxにしても波形が歪まないので、お勧めです。
目次: ROCK64/ROCKPro64
最近linux-nextでROCKPro64のアナログオーディオ出力を使いたくて、色々やっています。デバッグの都合上、ROCKPro64のDAC/ADCであるEverest ES8316の出力波形をオシロスコープで見ることが多いです。
私が音楽を聴く程度では、特に何も思いませんが、オシロスコープで見てしまうと、波形がやや歪んでいることに気づいてしまいます。
我が家で一番の波形の綺麗さを誇るONKYO U33GXV2と比較してみたいと思います。
最初はサンプリング周波数(以降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はやっぱり歪みが少なくて綺麗ですね。
上記の比較をしたあとに気づいたのですが、ES8316はFsを50kHz以上にする場合、異なるモードに設定しなければならないらしく、linux-nextはその設定に対応していませんでした。
つまりES8316側は設定不足で不利な状態にあり、公平な比較ではなかったようです。というわけで、次はサポートの範囲内であるFs = 48kHzの24kHz Sin波で比較しようと思います。
Everest ES8316 24kHz Sin波(Fs = 48kHz)
時間分解能の設定のせいかもしれませんが、先ほどより歪んでいるように見えます。Sin波と三角波の間のような波形になっています。
ONKYO U33GXV2 24kHz Sin波(Fs = 48kHz)
こちらは歪みが見当たらない(少なくとも私のオシロでは)レベルです。さすがですね……。
超強力な台風15号(Faxai)が来るということで、家でじっとしていました。
我が家は北と東に窓がありまして、北側の窓にガンガン風と雨が吹き付けていました。あまりの風圧にサッシが耐えらず、雨が窓サッシの隙間から霧吹きのように吹き出していました。途中で気づいてテープや紙で抑えたので、畳が水浸しになる被害は防げました。
真夜中に壁に飛来物が当たり、ものすごい音がしていました。窓の真横に当たったらしく、窓にはギリギリ当たりませんでした。窓に当たったら、窓が粉砕されていたと思います。本当に幸運でした。
後は何だろ、若干停電した程度でしょうか。特に被害はありませんでした。災害への備えは日頃からやっておいて損はないですね。
台風が過ぎた後に車を見に行ってみましたが、特に飛来物が当たった形跡もなく、何ともなかったです。良かった良かった。
< | 2019 | > | ||||
<< | < | 08 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | 1 | 2 | 3 |
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
合計:
本日: