2020年 8月 1日

link permalink

link 編集する

ROCKPro64 と音声ビットストリームパススルー出力

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

去年だったか、ROCKPro64 の HDMI 音声出力を有効化するパッチを linux-next に送ろうとしたことがあります。当時のレビューコメントで SPDIF と HDMI の音声ビットストリームパススルー出力(※1)は動くか?と聞かれたものの、テスト環境がなかったため、わからないまま挫折してしまいました。

今回、再チャレンジにあたり、テスト用に SPDIF と HDMI の音声ビットストリームをデコードできる機械を探しました。これがどうして、お手頃価格の良い商品が見当たらないです。

Amazon では SPDIF のみ対応の商品がありました。メーカーが怪しい、色んなバージョンが色んな店から売られている、そもそも動くの??など不安は募りますが、ダメ元で購入しました。

大手メーカー製を探すと、ホームシアター用ヘッドホンシステム 3〜4万円、もしくは AV プリアンプ 10万円 over!のような大げさな商品しかありません。

音声ビットストリームパススルー出力が、いかに高コスト&需要がないか良くわかりました。普通の人は音声信号が LPCM かパススルーかなど細かいことは気にしませんから、当然の成り行きでしょうね。

(※1)音声信号として LPCM ではなく、Dolby Digital(AC-3)や DTS をデコードせず圧縮音声のまま SPDIF や HDMI に出力する方式のことです。デコードは受信機器側で行います。

SPDIF 用のテスト機材

SPDIF パススルーのテスト用に、中国製と思われる謎の機械(型番なし、筐体には HD AUDIO RUSH と書いてある)を購入しました。Amazon で 4,000円くらいです。安い!事前の不安をよそに音は正常に鳴っています。素晴らしいです。

しかし本体にコーデックのインジケータがなく、LPCM か音声ビットストリームか全く判別がつきません。テスト用の機材としてはイマイチでした。10分に 1回くらい SPDIF 信号の PLL ロックが外れた(?)と思われる、数秒レベルの音切れが発生します。ROCKPro64 の出す信号が悪いのか、HD AUDIO RUSH が悪いのか、切り分けできず真因は不明です。

SPDIF だけだと LPCM 96kHz 16bit 2ch(3.072Mbps)のような、SPDIF(Max 1.5Mbps)の帯域を超える音声信号はテストできません。無理やり流すと酔っ払いが演奏してるみたいな変な音になります。HD AUDIO RUSH くん以外に HDMI 用のテスト機材が必要です。

HDMI 用のテスト機材

HDMI のテストならテレビ(Panasonic TH-L37DT3)で確認できるだろ、と思っていたら、HDMI 音声入力は LPCM 2ch のみの対応でした。LPCM は 2ch 以外にも 5.1ch 出力(※2)がありますがテストできません。ダメだこれ。

覚悟を決めてサラウンドヘッドフォンシステム SONY MDR-HW700DS を注文しました。37,000円くらいします、高い!まだ家に届いていませんが、来週辺りかな、人生初の SPDIF/HDMI 音声ビットストリームパススルー対応機器が手に入ります。

(※2)身近な例でいうと Nintendo Switch のサラウンドモードが、LPCM 5.1ch 出力を使います。試しに Switch をサラウンドモードにすると、テレビから全く音が出ませんでした。がっかり。

[編集者: すずき]
[更新: 2020年 10月 30日 01:05]

コメント一覧

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



2020年 8月 2日

link permalink

link 編集する

ROCKPro64 の HDMI から音を出す Kconfig 設定

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

今更ですが、メモしていなかった気がするので、ROCKPro64(Rockchip RK3399 搭載)で HDMI Audio を有効にする方法です。

方法は簡単で Linux の CONFIG_DRM_DW_HDMI_I2S_AUDIO と、CONFIG_GPIO_SYSCON を有効にすれば良いです。8/7 時点の linux-next のツリーでは、make defconfig すると、GPIO_SYSCON は n で、ビルド対象外になっています。手動で下記の設定を有効にする必要があります。

linux-next で有効にするコンフィグ(元から有効になっているものも含む)
  Device Drivers  --->
    -*- GPIO Support  --->
      Memory mapped GPIO drivers  --->
        [*] GPIO based on SYSCON
    Graphics support  --->
      Display Interface Bridges  --->
        [*] Synopsys Designware I2S Audio interface
    [*] Sound card support  --->
      [*]   Advanced Linux Sound Architecture  --->
        [*]   ALSA for SoC audio support  --->
          CODEC drivers  --->
            [*] Everest Semi ES8316 CODEC

CONFIG_SND_SOC_ES8316 はアナログオーディオを使いたい場合に有効にしてください。

[編集者: すずき]
[更新: 2020年 10月 30日 01:05]

コメント一覧

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



2020年 8月 3日

link permalink

link 編集する

ROCKPro64 と SPDIF/HDMI ビットストリームパススルー

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

以前(2020年 8月 1日の日記参照)購入した SONY MDR-HW700DS が届きました。早速 ROCKPro64 で HDMI のビットストリームパススルーをテストしたいと思います。

おさらい

ビットストリームパススルーは、SPDIF や HDMI に対して、圧縮音声データ(Dolby AC-3, DTS, MPEG2 AAC など)をデコードせず、そのまま送信する方式です。この方式の最大の利点としては、サラウンド音声が楽しめる点が挙げられます。

SPDIF は帯域が狭く、デコード後のサラウンド音声(LPCM 5.1ch)を送れません。しかし SPDIF 上を圧縮音声のまま送信し、受信機であるホームシアターシステム側で音声をデコードすることで、SPDIF でもサラウンド音声が楽しめます

HDMI の場合は利点がないかと言うとそうでもありません。LPCM 5.1ch を送出できない機器もありますし、ホームシアターシステムに適したデコードやミキシングができる可能性もあります。

パススルーのやり方

SPDIF/HDMI パススルーに対応したプレイヤーはいくつかあるようですが、今回は mpv を使用します。

GitHub にある ALSA のコンフィグファイル(GitHub へのリンク)を ~/.asoundrc などに追記します。再生時に audio-spdif オプションで出力フォーマットを指定します。再生するファイルの音声フォーマットと合っていれば、パススルーで出力されます。

パススルーあり
$ mpv --no-video a.ac3 --audio-spdif=ac3 --audio-device="alsa/HDMI.pcm.hdmi.0:0"

Playing: a.ac3
[ffmpeg/demuxer] ac3: Estimating duration from bitrate, this may be inaccurate
 (+) Audio --aid=1 (ac3 6ch 48000Hz)
AO: [alsa] 48000Hz stereo 2ch spdif-ac3    ★AC3 になっている
A: 00:00:02 / 00:05:36 (0%)


HDMI に Dolby AC-3 をパススルーで出力

SONY MDR-HW700DS のステータス画面は本体のインジケーターではなく HDMI の画像データにオーバーレイするタイプなので、HDMI ディスプレイの写真を取りました。狙い通りに AC-3 が再生されている様子がわかります。

オプションを間違えたり、オーディオデバイス番号を間違えてもエラーにはならず、再生が開始されますが、パススルーではなくデコードされ LPCM で再生が開始されます。

パススルーなし(オーディオデバイスを指定し間違えた例)
$ mpv --no-video a.ac3 --audio-spdif=ac3 --audio-device="alsa/hw:0"    ★間違えて hw:0 にした

Playing: a.ac3
[ffmpeg/demuxer] ac3: Estimating duration from bitrate, this may be inaccurate
 (+) Audio --aid=1 (ac3 6ch 48000Hz)
ALSA lib conf.c:4898:(parse_args) Unknown parameter AES0
ALSA lib conf.c:5031:(snd_config_expand) Parse arguments error: No such file or directory
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM hw:0,AES0=6,AES1=130,AES2=0,AES3=2
[ao/alsa] Playback open error: No such file or directory
[ao] Failed to initialize audio driver 'alsa'
[ao] This audio driver/device was forced with the --audio-device option.
[ao] Try unsetting it.
AO: [alsa] 48000Hz stereo 2ch s32    ★LPCM になっている
A: 00:00:02 / 00:05:36 (0%)


HDMI に LPCM で出力

その他の注意点として、受信機側がパススルー出力で送った圧縮音声に対応していない場合、LPCM だと思って再生してしまい、バリバリバリ!!という凄まじい音量のノイズが再生されることがあります。お試しの際は、音量を小さくしてからテストしてください。

[編集者: すずき]
[更新: 2020年 10月 30日 01:11]

コメント一覧

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



2020年 8月 6日

link permalink

link 編集する

エアコンが落ちそうで怖い

Twitter で「これ便利」と紹介されているのを見て知りました(製品紹介へのリンク)。エアコンハンガーというそうです。見た瞬間から「うわー!やめてくれー…エアコンは物干しじゃない」という感想しか浮かびません。

エアコン据付板の耐荷重はマチマチで、耐荷重ギリギリの可能性もあります。ハンガーの耐荷重(5kg)を追加で吊って、エアコン室内機が頭の上に落ちてきたら大ケガします(室内機の重さは 10〜15kg)。

パナソニックのエアコン説明書にある山盛りの注意書きを見ましたが「エアコンにモノを吊り下げると、落下しケガする」とは書いていませんでした。家電のユーザーはメーカー想定を超える壊し方をすることは、一応知ってましたが、実例を目の当たりにしたのは初めてです。全く嬉しくないですね。

エアコンハンガーの利用で、事故やケガにあっている人がいないことを祈ります……。 ちなみに、エアコンハンガーのメーカー注意書きに、

「下地がしっかりしていない壁に取り付けられているエアコンには使用しないでください。エアコンが落下する恐れがあります。(例: 下地にベニア板の無い石膏ボードなど)」

と言い訳が書いてありますが、一般人が壁の素材と下地を知るわけないでしょう?本気で言ってるのか??

メモ: 技術系?の話は Facebook から転記しておくことにした。

[編集者: すずき]
[更新: 2020年 8月 8日 14:24]

コメント一覧

  • hdk 
    言い訳がいいですね。実際にもし石膏ボードをボリボリと壊して落下したとして、室外機との接続があるから床までは落ちないんですかね。傾くくらいで済むのかな。 
    (2020年08月08日 14:57:39)
  • すずき 
    室内の銅配管は段々硬くなるので、床に落ちることはないと思います。
    とはいえ、うちのように結構室内の配管が長いと、頭には当たるかもしれないですね。 
    (2020年08月10日 17:53:18)
open/close この記事にコメントする



2020年 8月 7日

link permalink

link 編集する

Wikipedia

Wikipedia に寄付しました。といっても 5,000円ですけども。

Wikipedia の運営元(Wikimedia Foundation, Inc.)は広告なしで Wikipedia のような巨大システムを維持していて、さすがだと思いますけど、寄付催促メールのしつこさはちょっと嫌ですね……。

メモ: 技術系?の話は Facebook から転記しておくことにした。

[編集者: すずき]
[更新: 2020年 8月 8日 14:24]

コメント一覧

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



2020年 8月 8日

link permalink

link 編集する

車検

車検証と検査証票(フロントガラスに貼るステッカー)が届きました。

いつもならディーラーさんに 1週間くらい預けるので、車検証もそのときに付いてきます。今回は奥さんの通院の送り迎えに車が必要で、スバルのディーラーさんに無理を言って土日月の 3日で車検を終わらせてもらいました。

車検の検査自体は終わっても、車検証の発行が間に合わなかったので、後から郵送されてきた、ってことです。

検査内容

リアのロアアームブッシュが破損していたので、交換になった程度で、他は特に何もありませんでした。部品の在庫があって良かったです。

[編集者: すずき]
[更新: 2020年 8月 8日 14:35]

コメント一覧

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



2020年 8月 11日

link permalink

link 編集する

エナジードリンクとお国柄

マクドナルドが各国で味付けが違うのは有名ですが、エナジードリンクにもお国柄があって USA 版の Monster Energy はタウリンあり、日本版はタウリンなしの製品が販売されています。これは Red Bull も同様です。ただしエナジードリンクの場合、味付けの問題ではなく法律の問題です。

日本では、タウリンを入れると医薬部外品になり、製造業者+販売業者の厚労省の許可、商品ごとに承認が必要になります。Monster Energy 製造、販売元のアサヒ飲料は清涼飲料水製造メーカーなので、医薬部外品製造の設備は持っていないでしょう。たぶん。

実はヒトはタウリンを外部から摂取しなくても、体内で生合成できますから、生合成の原料となる物質を入れれば良いじゃない?と思うかもしれませんが、そんな甘くありません。厚生労働省の告示(リンク)(※)を見るとわかる通り、タウリンの主要な合成経路「L-メチオニン → L-システイン → タウリン」のいずれも医薬部外品扱いで清涼飲料水には添加できません。

L-メチオニンは必須アミノ酸なので生合成不可能、すなわち他の成分をいくら入れても代用になりません。必須アミノ酸は全て医薬部外品として指定されている辺り、良くできた法律です。

薬事法の目的「保健衛生の向上」を見る限り、必須アミノ酸を規制する意味ある……?という気になりますけど、一方で「医薬品、医療機器及び再生医療等製品の研究開発の促進」という目的もあります。苦労して薬効成分を見つけた製薬会社、高価な製造設備を入れているメーカーの権益を保護してあげるから、これからも医療品の研究開発を頑張ってくれたまえ〜!という法律なんですね。なるほどねえ。

(※)厚生省告示第百九十四号 - 都道府県知事の承認に係る医薬部外品という文書名です。

[編集者: すずき]
[更新: 2020年 8月 15日 18:10]

コメント一覧

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



2020年 8月 13日

link permalink

link 編集する

CPAP の効果

SpO2(血中酸素飽和度)を測りながら CPAP を付けて寝たところ、途中で寝苦しくて起きてしまい、CPAP を外して二度寝しました。このときの SpO2 の変化がなかなか面白いです。


CPAP あり〜外すまでの 1時間


CPAP なしの最初の 1時間


そのあとの 1時間

CPAP 外すと SpO2 は明らかに悪化(2枚目)するかと思えば、CPAP ない方がマシ(3枚目)な時間もあります。CPAP なしで寝た場合も何度か測っていますが、寝た直後は SpO2 が悪化しますが、しばらく経つと悪化しなくなることが多いです。

睡眠のサイクルとか、寝ている姿勢とか、何かしら呼吸が止まる原因があるはずなんですが、寝ている自分には全くわからないし、突き止めるのが難しいですね……。

メモ: 技術系?の話は Facebook から転記しておくことにした。

[編集者: すずき]
[更新: 2020年 8月 15日 16:55]

コメント一覧

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



2020年 8月 15日

link permalink

link 編集する

サラウンドヘッドフォンシステム

先日(2020年 8月 3日の日記参照)購入したサラウンドヘッドフォンシステム SONY MDR-HW700DS ですが、このような仕様みたいです。

  • スタンバイ(電源LEDがオレンジ):入力側の HDMI をパススルー
  • 電源OFF(電源LEDが消灯):入力側の HDMI をカット

今日の朝、何かの拍子に電源 OFF になったらしく、ディスプレイ側に何も映らず真っ黒になりました。最初見たとき、えええ!?もう壊れた?早すぎない??と勘違いして、かなり焦りました。

ワイヤレスヘッドフォンゆえの不都合

ダイニングテーブル(普段の作業机がこれしかない)にあまり機械類を置けないので、SONY MDR-HW700DS 本体の上に、USB-DAC の ONKYO SE-U33GXVII を乗せて使っています。すると 5秒に 1回くらい、USB-DAC の出力にジー…ビー…というノイズが乗ります。ワイヤレスヘッドフォンを探す電波を拾うのでしょうか?

USB-DAC のボリュームをいじってもノイズの大きさが変わらないので、アナログ回路で電波拾ってるんですかね?オシロスコープでノイズを測ろうと思いましたが、オシロの測定限界以下らしく測れませんでした。無音でも何も見えません。

オシロで見えない程度のノイズゆえ、音量は極めて小さいです。しかし、私には聞こえる程度の音量はあるので、気が散って仕方ありません。機器を離して置こうにも、場所がないです。困りました。

周波数依存?

実は SONY MDR-HW700DS はワイヤレスヘッドフォンとの通信に使う帯域を 2.4GHz 帯と 5GHz 帯から選択可能です。ダメ元で切り替えてみたところ、2.4GHz 帯にするとビー…というノイズが乗り、5GHz 帯だとノイズが乗りませんでした。うおー!やった!これで回避できます。

2.4GHz, 5GHz 自動選択機能を付けてくれた SONY の開発者には申し訳ないですが、5GHz 固定で使うことにします……。

[編集者: すずき]
[更新: 2020年 8月 15日 19:25]

コメント一覧

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



2020年 8月 16日

link permalink

link 編集する

The Hunter: Call of the Wild

お盆休みの間、行くところも特にないので The Hunter: Call of the Wild ばかりやっていました。気づいたらプレイ時間が 100時間を超えていたので、そろそろ感想くらい書いても良かろうってことで書いてみます。

The Hunter はゲームというより「リアル指向」のスポーツハンティングシミュレータです。とても良くできていると思います。ただですね、最初に言っておきますが、私は「リアル指向」が強すぎるゲームは嫌いです。ゲームとして全く面白くないです……。

気に入ったところ

  • 画がめちゃくちゃ綺麗(貧弱な GPU(※)ではプレイできない)
  • マップが多彩、山あり、川あり、湖あり、ツンドラにもサバンナにも行ける
  • 鳥、うさぎ、シカ、クマなどなど獲物が多彩
  • ライフルや他の武器の再現度が高い(実物がモデルになっているようだ)
  • 鳴き声や足跡から獲物を追う、わくわく感

気に入らないところ

  • GPU の力が足りないときフレームスキップせず、スローモーションになりイライラ度が MAX
  • マップが広い割に移動が遅くてイライラする
  • 動物が少ない、特に初期 3マップ(レイトン湖水地方、ヒルシュフェルデン保護区、メドヴェド=タイガ国立公園)は過疎地すぎる
  • リアルに寄せすぎてゲーム的な面白さがない
  • ごちゃごちゃうるさい(撃てば OK じゃなくて、狩猟基準のシステムがややこしい)
  • 「狩猟圧」というファンタジーシステムの存在

上に挙げた、良い点も悪い点も全て「リアル指向」であることに端を発しています。リアル指向である点が気に入らなければ、ほぼ全てが気に入らないと思います。逆に「リアル指向」が好きな人には最高の作品だと思います。

(※)私のノート PC に搭載されている、Radeon RX 550 では歯が立たないです。画質設定を全て最低に落としたうえで、ウインドウモードにして、FullHD の 1/4 くらいのサイズにしないとまともに動きません。

The Hunter 細かすぎて伝わらないルール: 狩猟基準

The Hunter: COTW では、獲物を仕留め回収する際に点数が付きます。今は Animal Scoring 2.0 という基準だそうです。大まかには、下記を守ると点が高くなります。

  • 適切な弾丸を使用したか?
  • 2発以内に仕留めたか?
  • 致命傷を与えたか(心臓、肺など)?
  • トロフィー部位(たいていは頭蓋骨)は無事か?

最初の「適切な弾丸か?」について捕捉すると、鳥やウサギ、キツネのような小物を、ヘラジカ用の大口径ライフルの弾丸でぶっ飛ばすと点が下がります。獲物と弾丸にはクラス分けがされているので、一致させれば OK です。

真ん中の 2つについては、致命傷を与えなければ何度も撃つ羽目になるので、たいていは一緒に達成するはずです。

最後の「トロフィー部位は無事か?」については、獲物をはく製にして飾ることが狩りの 1つの目的なので、はく製にする部分に穴が開くような撃ち方(=ヘッドショットする)をすると点が下がります。

The Hunter 細かすぎて伝わらないルール: 狩猟圧

リアル指向の The Hunter において、極めて不自然なファンタジーシステムです。

獲物を仕留めた場所に、マップ上で見ると紫色の血飛沫のようなマークがつき、その付近には再び動物が寄りつきにくくなります。時間経過では消えず、他の場所で獲物を仕留めると段々古い狩猟圧から消えるようです。

同じニードゾーンでずっと待ち伏せ狩りすることを阻止したかったのだと思いますが、かなり変なシステムです。全然リアルじゃないでしょう。私の中ではこのシステムがつまんなさに拍車をかけています……。

邪道ハンターのススメ

The Hunter はスコアシステムを考慮して、急所を狙いやすく、弱い弾丸でも威力が保てる至近距離に近づくべきです。が、50m くらいまで近寄ろうとすると、何かと最悪なことが多くて、本当にイライラします。

気づかれないように近づく移動方法として匍匐前進があります。しかし匍匐前進は、速度が遅く時間ばかり掛かってイライラします。いかに慎重に近づいても獲物に逃げられることがあってこれまたイライラします。匍匐前進だと藪で獲物が見えず近づいても撃てないことが多くて、さらにイライラ度が高まります。

真面目に接近しようとするほど、イライラして正直やってられませんので、邪道ハンターのススメ「走り回って、気づかれないほど遠くから、大口径ライフルでズドン」を紹介します。

  • 動物の密度が高い DLC マップを選ぶ(初期 3マップ以外なら多分 OK)
  • 鳴き声を聴くまで適当に走り回る(呼び笛に反応しない動物は無視)
  • 三脚を建てて登る
  • 呼び笛を鳴らしまくる(何も来なかったら三脚を畳み、また走り回る)
  • 近づいてくる獲物を双眼鏡で見つける
  • ライフルに持ち替えて、動物が立ち止まるまで待つ
  • 使用可能な最強の大口径ライフルで一撃必殺する(獲物のクラスは無視)

もしニードゾーンが使えそうなら、

  • 動物の密度が高い DLC マップを選ぶ(初期 3マップ以外なら多分 OK)
  • 時間に合ったニードゾーン(※2)に行く
  • 獲物を双眼鏡で見つける(見つからなかったら、気にせず他の場所を探す)
  • ウェイポイントを獲物を見つけた地点に置く
  • ウェイポイントの 100m〜150m くらいまで近寄る(匍匐は不要、中腰で OK)
  • ライフルに持ち替える
  • 使用可能な最強の大口径ライフルで一撃必殺する(獲物のクラスは無視)

最重要ポイントは、動物への接近に時間を掛けないことです。手早く次にチャレンジできてダルさが激減しますし、動物に逃げられても惜しくありません。The Hunter は動物との遭遇率がかなり低いので、時間をかけて逃げられたときのガッカリ感が半端じゃないです。

次に重要なのは距離を開けることと、高威力のライフルです。距離を 100m くらい空ければ、風向きを無視しても、動物が逃げる確率は低いです。大口径ライフルならば急所を外しても即死する確率が高まります。これらの合わせ技により、ハント成功率がかなり上がりました。

とにかく「走り回って、気づかれないほど遠くから、大口径ライフルでズドン」で、お気軽な快適ハンティングを楽しみましょう。

(※2)ニードゾーン=動物の食事、給水、休憩場所のことです。このゲームでは特定の時間帯に、特定の動物がニードゾーンに集まってくるようにできています。かなり強い引き寄せ力をもっているため、待ち伏せ狩りの場所として最適です。

細かいことは気にしない

狩猟基準は無視を推奨します。点を上げるには弱い弾 1発で仕留める必要があり、そのためには近づく必要があります。近づけば逃げられる可能性が高まります。時間かかってイライラするだけです。健康に良くありません。別に 0点だろうが 10点だろうが、どうでも良いです。それよりもハントしたいだろ?なあ?

シナリオも無視を推奨します。真面目に追いかけると、シナリオの攻略対象の動物が見つからずイライラするだけで、全く面白くないです。それよりもあらゆる場所で目に付いた動物を乱獲すれば、いくつかは勝手に終わります。暇で仕方なくて、シナリオが気になる!くらいまで、無視して良いと思います。

[編集者: すずき]
[更新: 2020年 8月 16日 18:05]

コメント一覧

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



2020年 8月 19日

link permalink

link 編集する

メモリの使い方は三者三様 - その 5

その 1その 2その 3その 4その 5

久しぶりに Android が動作するボードを購入したので、メモリの使い方を見てみました。開発用ボードは su が使えるので、情報が何でも取れて楽で良いですね。

最初は Khadas VIM2 Basic というボードです(Linux 3.14.29 aarch64, Android 7.1.2 ベース)。Amlogic S912 という SoC です。RAM は 2GB です。RAM が 3GB の Pro というボードもあります。

Khadas VIM2 Basic の /proc/meminfo
MemTotal:        1746388 kB
MemFree:          457292 kB
MemAvailable:    1170284 kB
Buffers:            7384 kB
Cached:           676612 kB
SwapCached:            0 kB
Active:           380856 kB
Inactive:         585248 kB
Active(anon):     282472 kB
Inactive(anon):      612 kB
Active(file):      98384 kB
Inactive(file):   584636 kB
Unevictable:         252 kB
Mlocked:             252 kB
SwapTotal:        511996 kB
SwapFree:         511996 kB
Dirty:                76 kB
Writeback:             0 kB
AnonPages:        282492 kB
Mapped:           264172 kB
Shmem:               976 kB
Slab:             150844 kB
SReclaimable:     115568 kB
SUnreclaim:        35276 kB
KernelStack:       15184 kB
PageTables:        20864 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     1385188 kB
Committed_AS:   45821668 kB
VmallocTotal:    2097088 kB
VmallocUsed:      106876 kB
VmallocChunk:    1805380 kB
TotalCMA:         221184 kB
UsedCMA:            4172 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Khadas VIM2 Basic の /proc/pagetypeinfo
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10   total
Node    0, zone   Normal, type    Unmovable    103     43     23      8      1      0      0      0      1      0      0     617
Node    0, zone   Normal, type  Reclaimable      0      1      1      0      1      2      0      0      1      0      0     342
Node    0, zone   Normal, type      Movable      0      0     95     52     12      5      1      0      1      0    109  113084
Node    0, zone   Normal, type      Reserve      0      0      0      0      0      0      0      0      0      0      0       0
Node    0, zone   Normal, type          CMA      0      0      0      0      0      0      0      0      0      0      0       0
Node    0, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0       0


Number of blocks type     Unmovable  Reclaimable      Movable      Reserve          CMA      Isolate
Node 0, zone   Normal          144           14          690            2          108            0
Khadas VIM2 Basic の /proc/iomem
00000000-04ffffff : System RAM
  01080000-01f5b813 : Kernel code
  020ac000-025a0fff : Kernel data
05300000-072fffff : System RAM
07300000-07307fff : persistent_ram
07308000-0730ffff : persistent_ram
07310000-07317fff : persistent_ram
07318000-0731ffff : persistent_ram
07320000-07327fff : persistent_ram
07328000-0732ffff : persistent_ram
07330000-07337fff : persistent_ram
07338000-0733ffff : persistent_ram
07340000-07347fff : persistent_ram
07348000-0734ffff : persistent_ram
07350000-07357fff : persistent_ram
07358000-0735ffff : persistent_ram
07360000-07367fff : persistent_ram
07368000-0736ffff : persistent_ram
07370000-07377fff : persistent_ram
07378000-0737ffff : persistent_ram
07380000-07387fff : persistent_ram
07388000-0738ffff : persistent_ram
07390000-07397fff : persistent_ram
07398000-0739ffff : persistent_ram
073a0000-073a7fff : persistent_ram
073a8000-073affff : persistent_ram
073b0000-073b7fff : persistent_ram
073b8000-073bffff : persistent_ram
073c0000-073c7fff : persistent_ram
073c8000-073cffff : persistent_ram
073d0000-073d7fff : persistent_ram
073d8000-073dffff : persistent_ram
073e0000-073e7fff : persistent_ram
073e8000-073effff : persistent_ram
073f0000-073f7fff : persistent_ram
073f8000-073fbfff : persistent_ram
073fc000-073fcfff : persistent_ram
073fd000-073fdfff : persistent_ram
07400000-77ffffff : System RAM
c11084c0-c11084d7 : c11084c0.serial
c1108500-c110851f : /i2c@c1108500
c1108680-c11086af : c1108680.saradc
c11087c0-c11087df : /i2c@c11087c0
c1109880-c110988f : /pinmux
c8013000-c80137ff : /mhu@c883c400
c8100014-c810001b : mux
c8100024-c810002b : gpio
c810002c-c810002f : pull
c8100480-c810049f : /rc@c8100580
c81004c0-c81004d7 : c81004c0.serial
c81004e0-c81004f7 : c81004e0.serial
c8100580-c81005c3 : /rc@c8100580
c8832000-c8832013 : /t9015
c8834430-c883446f : gpio
c88344b0-c88344d7 : mux
c88344e8-c88344fb : pull
c8834500-c8834503 : /defendkey
c8834520-c8834533 : pull-enable
c8834540-c8834547 : /ethernet@0xc9410000
c8834558-c8834563 : /ethernet@0xc9410000
c8838000-c88383ff : c8838000.canvas
c883c3d8-c883c3df : c1108680.saradc
c883c400-c883c44b : /mhu@c883c400
c9000000-c9007fff : /dwc3@c9000000
  c9000000-c9007fff : xhci-hcd
c900c100-c90fffff : /dwc3@c9000000
c9410000-c941ffff : /ethernet@0xc9410000
d0078000-d007807f : /usb2phy@d0078000
d0078080-d007809f : /usb3phy@d0078080
d00c0000-d01bffff : d00c0000.t82x

2つ目は Khadas VIM3 Basic というボードです(Linux 4.9.113 armv7l, Android 9 ベース)。Amlogic A311D という SoC で、S922X に NPU という AI 処理用の IP を搭載した仕様です。S922X とピンコンパチとのこと。RAM は 2GB です。RAM が 4GB の Pro というボードもあります。

Khadas VIM3 Basic の /proc/meminfo
MemTotal:        1925088 kB
MemFree:          643640 kB
MemAvailable:    1091900 kB
Buffers:            9696 kB
Cached:           563448 kB
SwapCached:            0 kB
Active:           405012 kB
Inactive:         434112 kB
Active(anon):     268152 kB
Inactive(anon):      788 kB
Active(file):     136860 kB
Inactive(file):   433324 kB
Unevictable:        2372 kB
Mlocked:            2372 kB
HighTotal:       1179648 kB
HighFree:          36428 kB
LowTotal:         745440 kB
LowFree:          607212 kB
SwapTotal:        262140 kB
SwapFree:         262140 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:        268356 kB
Mapped:           389444 kB
Shmem:              1084 kB
Slab:              58456 kB
SReclaimable:      24384 kB
SUnreclaim:        34072 kB
KernelStack:        8856 kB
PageTables:        22616 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     1224684 kB
Committed_AS:   29512728 kB
VmallocTotal:     245760 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
CmaTotal:         778240 kB
CmaFree:           10972 kB
VmapStack:          4440 kB
Khadas VIM3 Basic の /proc/pagetypeinfo
Page block order: 10
Pages per block:  1024

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    0, zone   Normal, type    Unmovable     39     46     15      4      3      1      1      0      1      1      0
Node    0, zone   Normal, type      Movable    418     81     32      8     11      8      2      1      1      1    144
Node    0, zone   Normal, type  Reclaimable      0      1      1      4      0      1      0      1      1      1      0
Node    0, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone   Normal, type          CMA      6      0      0      1      0      0      0      0      0      0      0
Node    0, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone  HighMem, type    Unmovable    150     76     76     34     17      3     40     10      0      0      0
Node    0, zone  HighMem, type      Movable     90    186     62     26     10      4      1      0      0      0      0
Node    0, zone  HighMem, type  Reclaimable      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone  HighMem, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone  HighMem, type          CMA    864    430    120     63     26      7      0      0      0      0      0
Node    0, zone  HighMem, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic          CMA      Isolate
Node 0, zone   Normal           17          167            7            0            1            0
Node 0, zone  HighMem           73           26            0            0          189            0
Khadas VIM3 Basic の /proc/iomem
00000000-77ffffff : System RAM
  00108000-015fffff : Kernel code
  01700000-0198cbc3 : Kernel data
ff100000-ff1007ff : galcore register region
ff3f0000-ff3fffff : eth_base
ff500000-ff507fff : /dwc3@ff500000
  ff500000-ff507fff : /dwc3@ff500000
ff50c100-ff5fffff : /dwc3@ff500000
ff630218-ff63021b : /rng
ff632000-ff633fff : /t9015
ff634440-ff63448b : gpio
ff6344e8-ff6344ff : pull
ff634520-ff634537 : pull-enable
ff634540-ff634547 : eth_cfg
ff6346c0-ff6346ff : mux
ff634740-ff63475b : drive-strength
ff638000-ff639fff : ff638000.canvas
ff63c400-ff63c44b : /mhu@c883c400
ff642000-ff643fff : /soc/audiobus@0xff642000
ff64c000-ff64c09f : eth_pll
ff800014-ff80001b : mux
ff80001c-ff800023 : drive-strength
ff800024-ff800037 : gpio
ff802000-ff80201f : /soc/aobus@ff800000/pwm@2000
ff803000-ff803017 : ff803000.serial
ff805000-ff80501f : /soc/aobus@ff800000/i2c@5000
ff808000-ff80801f : /rc@0xff808040
ff808040-ff808083 : /rc@0xff808040
ff809000-ff809047 : /saradc
ffd01008-ffd0100b : eth_reset
ffd19000-ffd1901f : /soc/cbus@ffd00000/pwm@19000
ffd1b000-ffd1b01f : /soc/cbus@ffd00000/pwm@1b000
ffd1c000-ffd1c01f : /soc/cbus@ffd00000/i2c@1c000
ffd22000-ffd22017 : ffd22000.serial
ffd24000-ffd24017 : ffd24000.serial
ffe03000-ffe037ff : /sdio@ffe03000
ffe05000-ffe057ff : /sd@ffe05000
ffe07000-ffe077ff : /emmc@ffe07000
ffe09000-ffe0907f : /usb2phy@ffe09000
ffe09080-ffe0909f : /usb3phy@ffe09080
ffe40000-ffe43fff : ffe40000.bifrost
fffe7000-fffe77ff : /mhu@c883c400
[編集者: すずき]
[更新: 2020年 8月 20日 23:46]

コメント一覧

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



2020年 8月 24日

link permalink

link 編集する

ALSA ループバックデバイス

デスクトップ PC にはスピーカーを繋いでいませんが、たまに音声再生を確認したいことがあります。スピーカーを繋ぎ変えても良いですが、ALSA のループバックデバイスを使うと簡単に音声を転送したり、ファイルに記録したりできます。

ループバックデバイスとは再生した音声がそのまま戻ってきて(ループバック)録音できるデバイスのことです。ヘッドフォンの出力端子を、マイクロフォンの入力端子に繋いでループさせた状態を想像してもらうとわかりやすいと思います。

ALSA のループバックデバイス(aloop)は、ALSA の標準的な機能です。普通の環境だとロードされていないはずなので、modprobe でロードします。

ループバックデバイスのインストール
# modprobe snd-aloop

$ cat /proc/asound/pcm

00-03: HDMI 0 : HDMI 0 : playback 1
00-07: HDMI 1 : HDMI 1 : playback 1
00-08: HDMI 2 : HDMI 2 : playback 1
00-09: HDMI 3 : HDMI 3 : playback 1
00-10: HDMI 4 : HDMI 4 : playback 1
01-00: ALC1220 Analog : ALC1220 Analog : playback 1 : capture 1
01-01: ALC1220 Digital : ALC1220 Digital : playback 1
01-02: ALC1220 Alt Analog : ALC1220 Alt Analog : capture 1
02-00: Loopback PCM : Loopback PCM : playback 8 : capture 8    ★このデバイス hw:2 を使用する
02-01: Loopback PCM : Loopback PCM : playback 8 : capture 8

ロードし終わると PCM デバイスが 1つ増えます。上記の場合は 02-xx(02-00 と 02-01)が増えています。

ALSA ループバックデバイスの使い方

ループバックデバイスはサブデバイス 0 が再生用、サブデバイス 1 が録音用となっています。先ほどの例でいうと、再生時は hw:2,0 を使い、録音時は hw:2,1 を使います。

音声を再生する側
$ aplay test.wav -D hw:2,0

Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
ループバック音声を録音する側
#### ファイルに記録する場合

$ arecord -D hw:2,1 -r 48000 -f S16_LE -c 2 test2.wav

Recording WAVE 'test2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo


#### ネットワーク経由で送る場合

$ arecord -D hw:2,1 -r 48000 -f S16_LE -c 2 | nc 192.168.1.10 5555

Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

私の家のスピーカーは、今のところ ROCK64 に繋がっています。ROCK64 にネットワーク経由で送って、下記のように受け取れば「ほぼ」リアルタイムでデスクトップ PC の音声が確認できます。

ネットワーク経由で別端末で受け取る場合
$ nc -l 5555 | aplay -D hw:0

Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

受け取る方は先頭の WAV ヘッダでサンプリング周波数やチャネル数を知ることができるため、-r や -c を指定する必要はありません。指定しても構いませんが無視されるはずです。

「ほぼ」リアルタイムと書いた理由は、上記の方法だと人間が余裕でわかるくらいの遅延が発生してしまうからです。ちゃんと測っていませんが、0.5秒くらい遅れてるかも?これでも簡易的な音声確認としては十分ですし、気にしなくでも良いでしょう。

[編集者: すずき]
[更新: 2020年 8月 31日 23:09]

コメント一覧

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



2020年 8月 27日

link permalink

link 編集する

サーバ向けプロセッサでは最強の Intel

Twitter で Cavium Thunder X3 はサーバ向け汎用 ARM SoC ではなくなるかもしれない、という話を見かけました。Cavium(今は Marvell に買収されました)は独自 ARM CPU コアを作って頑張ってたメーカーです。

ARM 自体はまだまだめげることなく、サーバ向けに売りたい(Arm のサーバ向け戦略十年の計は実を結ぶか、新プロセッサ「Neoverse」 - MONOist)ようですが、肝心の ARM 系 SoC メーカーやサーバベンダーが ARM 系サーバで成功している様子がないです。

以前 Qualcomm Centriq も鳴り物入りでサーバ向け ARM SoC に参入しましたが、2018年にあっさり撤退Arm SoC の開発部門を秘かに閉鎖していた Qualcomm - EE Times Japan)しています。モバイルの王者 Qualcomm をもってしても困難な道のようです。

サーバ向けプロセッサは Intel が 9割取っているらしいので、崩すのはなかなか容易ではありませんね……。

ARM メニーコア系 SoC

サーバ向けとして発表されている ARM メニーコア系 SoC を列挙してみました。年代はチップがローンチされたおおよその時期です。間違ってたらごめんなさい。

  • Ampere Altra(2020, ARM Neoverse N1, 80コア)
  • Amazon Graviton 2(2020, ARM Neoverse N1, 64コア)
  • Huawei Kunpeng 920(2019, Hisilicon TSV110, 64コア)
  • Cavium Thunder X2(2018, Broadcom Vulkan, 32コア)
  • Amazon Graviton(2018, ARM Cortex-A72, 16コア)
  • Qualcomm Centriq(2017, Qualcomm Folker, 48コア)
  • Socionext SC2A11(2017, Cortex-A53, 24コア)
  • Cavium Thunder X1(2014, Cavium 独自, 48コア)

こんな感じですかね?SC2A11 はホームページでサーバ向けと謳っていたので、リストに入れてます。でも CA53 コアなので、性能的には Thunder X2 辺りと並べるのはちょっと厳しい……かな?

[編集者: すずき]
[更新: 2020年 8月 31日 01:42]

コメント一覧

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



2020年 8月 29日

link permalink

link 編集する

ROCK64 を Raspberry Pi 3 のケースに無理やり格納

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

先日 KADHAS VIM2, VIM3 を購入したため、ARM ボードがさらに増え置き場がなくなりました。既存のボードをコンパクトに収納できないかと画策し、目を付けたのが ROCK64 です。現在 ROCK64 は純正ケースに入れて使っていますが、ギリシャの神殿を思わせる立派な柱と、無駄にでかいアクリル板のせいで、すっっごい邪魔です。


ROCK64 の純正ケース

ROCK64 は Raspberry Pi 3 とほぼ同じ大きさですから、Raspberry Pi 3 のケースを流用できるはずです。

ケース選び

改造のベースになるケースは、TinkerBoard や Raspberry Pi 3 の格納で活躍している Physical Computing Lab の 3ple Decker Raspberry Pi ケース(公式サイトへのリンク)です。

Rasberry Pi 3 は電源が USB micro B ですが、ROCK64 は AC アダプタなので、全く形が合いません。アクリルケースの穴を削って広げる必要があります。もう一か所、ROCK64 の個体差か(or 単に設計の問題か?)ヘッドホンジャックがケースとズレていて、プラグが刺さらないため、これも直さないといけません。


電源コネクタ周辺(削る予定の部分を黒く塗っている)


ヘッドホンジャック周辺(削る予定の部分を黒く塗っている)

削り方はリューターにプラスチック用のビットを付けてゴリゴリ削るだけです。厚さも面積も大したことないので、力業でどうにでもなると思います。アクリルを削ると変なにおいがしますね。焦げてるのかな……?


加工後のケース

ケースを削り終わりました。ROCK64 の端子がちゃんと外から見えています。

細かい不都合

元より ROCK64 用のケースではないので、様々な不都合が発生します。

  • ROCK64 の 22pin のピンヘッダ(Pi P5+ Bus)がケースで隠れて配線できない
  • ROCK64 の PWR, RESET ボタンが押せない
  • ボードの固定が甘くなる

Pi P5+ Bus が使用不能になる点は諦めました。Rasberry Pi 3 にはないピンヘッダなので致し方無しです。このピンヘッダから引き出していた S/PDIF が利用不可能になりました。さよなら S/PDIF さん。

PWR, RESET ボタンはケースを開ければ押せますが、面倒です。今後は PWR ボタンに頼らない運用を考えるべきでしょう。

ボードが固定できない問題はどうにもなりませんでした。microSD の上部を抑えるケース側のツメがうまくハマりません。


ボードを固定するケース側のツメ

もう少しきちんと調べてみると、ROCK64 は Rasberry Pi 3 より microSD スロットに厚みがあるせいで、microSD の上部を抑えるケース側のツメがうまくハマらないようです。


Raspberry Pi 3 の場合


ROCK64 の場合

スロットの厚さはどうしようもないので、泣く泣くケース側のツメを折りました。

ツメがないので、microSD カードがケースに引っ掛かってギリギリケースに固定されている状態です。ROCK64 の 40pin のピンヘッダ(Pi-2 Bus)にジャンパケーブルを抜き差しすると、microSD にかなり力が掛かります。これは良くないですね……。

Pi-2 Bus へのケーブル抜き差しは結構固いため、そのうち microSD スロットが変形するか、microSD が折れて壊れると思います。幸いなことに、今は頻繁にピンヘッダのケーブル抜き差しはしませんから、しばらくこの状態でも使えるでしょう。

[編集者: すずき]
[更新: 2020年 10月 30日 01:22]

コメント一覧

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



2020年 8月 30日

link permalink

link 編集する

駐車場での事故

先週、突然知らない番号から電話が掛かってきました。何だか焦った様子でした。要約すると「アパートの駐車場で隣に駐車している者です、駐車しようとして、あなたの車にぶつけてしまいました」とのことでした。車の様子を確認したところ、見事にバンパーの右前が取れていました。ああー……。


レガシィのバンパーが取れた

後日、保険屋さんと修理屋さん(スーパーオートバックス)から電話があり、車を引き取りに来る日時等を決めました。そして今日、レガシィさんはフロントバンパー修理のため旅立っていきました。

修理屋さん曰く「右ライトも Assy 交換で新品になるだろう」とのこと。新品交換後の右ライトに対し、古ぼけた左ライトの明るさがアンバランスになるのはうまくないので、左ライトの研磨もお願いしました。残念ながら左ライトの研磨は保険が効かず自費になりそうですが、曇っていたライトが明るくなるから良しとしましょう。

代車

代車はホンダのフィットでした。


代車のフィット、外観


代車のフィット、インパネ

総じて良い車だと思います。レガシィとの違いとしては、

  • フロントがかなり斜めってる、真上の日差しがダッシュボードを照らし前が見えない
  • アクセルがフニャフニャ、踏んでもあまり速度が変わらない(遊びが大きい??)
  • ブレーキがある点から急激に効いて怖い

昔のフィットに乗ったときは、アクセルオフ時のエンブレが急で、車酔いしたので、正直好きな車ではなかったのですが、今のフィットは素敵な車です。新しい車って確実に良くなってますね。

ADAS(前車の車間検知、車線逸脱の警告)も搭載されていて面白いです。たまに誤検知?するのか、何もないところで突然ピー!と警告音が鳴ったり、車線逸脱の警告とともにハンドルがンゴゴー!って言い出すのはご愛敬です。

[編集者: すずき]
[更新: 2020年 8月 31日 00:55]

コメント一覧

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



2020年 8月 31日

link permalink

link 編集する

Zephyr OS で遊ぼう その 10 - QEMU の変化に対応する

目次: Zephyr を調べる - まとめリンク

最近の RISC-V 向け QEMU で spike, virt を起動すると、下記のようなエラーで怒られてしまいます。

QEMU RISC-V の起動時に出るエラー
$ qemu-system-riscv32 -nographic -machine spike -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/zephyr.elf

qemu-system-riscv32: Unable to load the RISC-V firmware "opensbi-riscv32-spike-fw_jump.elf"

このエラーの原因は QEMU RISC-V 向けの仕様変更によるものです。machine が spike, virt のときに、自由に BIOS を選べるように変わりました。ですが Zephyr を起動する際には、特に BIOS は必要ないため、none を指定すれば OK です。

QEMU RISC-V を BIOS なしで起動する
$ qemu-system-riscv32 -nographic -machine spike -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/zephyr.elf -bios none

*** Booting Zephyr OS build v2.2.0-rc1-123-gcaca3f60b012  ***
Hello World! hoge

Zephyr だけでなく QEMU も日々進化しているのですね。

[編集者: すずき]
[更新: 2020年 9月 2日 19:07]

コメント一覧

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



こんてんつ

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 2020年
open/close 過去日記について

その他の情報

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