link もっと前
   2019年 9月 7日 -
      2019年 8月 29日  
link もっと後

link 未来から過去へ表示(*)
link 過去から未来へ表示

日々

link permalink

Sin 波の美しさ勝負

最近 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)

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

[編集者: すずき]
[更新: 2019年 10月 21日 13:44]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

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

引き続き 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 6kHz 矩形波(Fs = 48kHz)、DAC ボリューム 0.0dB

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


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

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


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

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

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


ES8316 6kHz 矩形波(Fs = 48kHz)、DAC ボリューム -2.0dB

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

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

[編集者: すずき]
[更新: 2019年 9月 8日 12:51]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

カーナビを買いました

一昨年にカーナビが壊れて(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 から転記しておくことにした。全体的に小修正。

[編集者: すずき]
[更新: 2019年 9月 2日 02:38]
link 編集する

コメント一覧

  • hdk 
    車向けの製品の中でも、車載コンピューターと独立しているタイプのポータブルカーナビはかなり設計変更しやすい部類なはずだと思いますが、そこまで進化していないとは驚きです。

    最近スマートフォンホルダーを付けたら、スマートフォンのナビがすごく使いやすくなって、もっと早くつけておくべきだったと思いました (^_^; 
    (2019年09月02日 23:20:55)
  • すずき 
    私も正直びっくりです。間違って違う製品を買ったか?と思いました。

    毎回の付け外しが億劫でなければ、スタンド+7インチタブレット or スマホの方がはるかに快適だと思います。 
    (2019年09月04日 23:39:37)
open/close この記事にコメントする



link permalink

RockPro64 とアナログオーディオ - その 2 - Headphone Mixer ボリュームのバグ

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 から転記しておくことにした。全体的に小修正。

[編集者: すずき]
[更新: 2019年 9月 8日 12:51]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

独自の apt サーバー - その 5 - 複数のセクションに対応する

前回、Tree::Sections には複数のセクションが指定でき、Tree::Architectures には複数のアーキテクチャが指定できますが、TreeDefault::Packages との対応がよくわからない。と書きましたが、複数のセクションを同時に指定する手段が見つかったので、メモしておきたいと思います。

書き方は簡単で、前回 TreeDefault のパスに出現するセクション名を stable と決め打ちで書いていました。これを $(SECTION) に置き換えるだけです。アーキテクチャ名なら $(ARCH) です。

apt_generate_debian_buster.conf で複数の Sections を指定

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 の指定はなくても動くことがわかりましたので、削除しています。

セクションを複数指定できるようになりましたので、スクリプトも若干変わります。

apt-ftparchive を呼ぶスクリプト

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 を実行します。

/etc/apt/sources.list に独自 apt サーバーを追加

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つはインストールできなくなります。セクション指定が機能していることがわかると思います。

[編集者: すずき]
[更新: 2019年 11月 8日 00:41]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
   2019年 9月 7日 -
      2019年 8月 29日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 12/5 00:14

カレンダー

<2019>
<<<09>>>
1234567
891011121314
15161718192021
22232425262728
2930-----

最近のコメント 5件

  • link 19年09月01日
    すずき 「私も正直びっくりです。間違って違う製品を...」
    (更新:09/04 23:39)
  • link 19年09月01日
    hdk 「車向けの製品の中でも、車載コンピューター...」
    (更新:09/02 23:20)
  • link 19年07月18日
    hdk 「あっ、AAMはマニュアルのオペレーション...」
    (更新:07/25 00:02)
  • link 19年07月18日
    すずき 「AAM(ASCII Adjust AX ...」
    (更新:07/24 22:22)
  • link 19年07月18日
    hdk 「加算減算は符号のありなしどちらも命令が同...」
    (更新:07/24 07:25)

最近の記事 3件

link もっとみる
  • link 19年07月05日
    すずき 「[ARM と RISC-V で CoreMark 対決] 先日購入...」
    (更新:12/05 00:14)
  • link 19年11月28日
    すずき 「[RockPro64 とオーディオ DAC - その 3 - ] ...」
    (更新:11/28 02:17)
  • link 19年11月27日
    すずき 「[RockPro64 とオーディオ DAC - その 2 - ] ...」
    (更新:11/28 02:16)

こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報