コグノスケ

GCCを調べる - その17 - ベクトル四則演算、論理演算の定義

目次: GCC

ベクトルのロード、ストアだけでは自動ベクトル化できるコードが少なすぎるので、他の演算も定義したいと思います。

;; gcc/config/riscv/riscv.md

(define_attr "vecmode" "unknown,V32SI,V64SI"
  (const_string "unknown"))

...

;; Iterator for hardware supported vector modes.
(define_mode_iterator ANYV [(V32SI "TARGET_VECTOR")
			    (V64SI "TARGET_VECTOR")])

...


;;★★加算

(define_insn "add<mode>3"
  [(set (match_operand:ANYV	       0 "register_operand" "=v")
	(plus:ANYV (match_operand:ANYV 1 "register_operand" " v")
		   (match_operand:ANYV 2 "arith_operand"    " v")))]
  "TARGET_VECTOR"
  "vadd.vvt%0,%1,%2"
  [(set_attr "type" "arith")
   (set_attr "vecmode" "<MODE>")])


;;★★減算

(define_insn "sub<mode>3"
  [(set (match_operand:ANYV		0 "register_operand" "=v")
	(minus:ANYV (match_operand:ANYV 1 "register_operand" " v")
		    (match_operand:ANYV 2 "arith_operand"    " v")))]
  "TARGET_VECTOR"
  "vsub.vvt%0,%1,%2"
  [(set_attr "type" "arith")
   (set_attr "vecmode" "<MODE>")])


;;★★乗算

(define_insn "mul<mode>3"
  [(set (match_operand:ANYV	       0 "register_operand" "=v")
	(mult:ANYV (match_operand:ANYV 1 "register_operand" " v")
		   (match_operand:ANYV 2 "arith_operand"    " v")))]
  "TARGET_VECTOR"
  "vmul.vvt%0,%1,%2"
  [(set_attr "type" "arith")
   (set_attr "vecmode" "<MODE>")])


;;★★除算

;; This code iterator allows unsigned and signed division to be generated
;; from the same template.
(define_code_iterator any_div [div udiv mod umod])

(define_insn "<optab><mode>3"
  [(set (match_operand:ANYV		  0 "register_operand" "=v")
	(any_div:ANYV (match_operand:ANYV 1 "register_operand" " v")
		      (match_operand:ANYV 2 "arith_operand"    " v")))]
  "TARGET_VECTOR"
  "v<insn>.vvt%0,%1,%2"
  [(set_attr "type" "arith")
   (set_attr "vecmode" "<MODE>")])


;;★★論理演算

;; This code iterator allows the three bitwise instructions to be generated
;; from the same template.
(define_code_iterator any_bitwise [and ior xor])

...

(define_insn "<optab><mode>3"
  [(set (match_operand:ANYV		      0 "register_operand" "=v")
	(any_bitwise:ANYV (match_operand:ANYV 1 "register_operand" "%v")
			  (match_operand:ANYV 2 "arith_operand"    " v")))]
  "TAREGET_VECTOR"
  "v<insn>.vvt%0,%1,%2"
  [(set_attr "type" "logical")
   (set_attr "vecmode" "<MODE>")])

四則演算、論理演算を使う下記のプログラムを書きます。自動ベクトル化で四則演算のループをベクトル化しても良いですが、ベクトル拡張記法（Vector Extensions (Using the GNU Compiler Collection (GCC))）を使ったほうが狙った演算が出しやすく、テストするときに楽です。

typedef int __v64si __attribute__((__vector_size__(256)));

void test()
{
	__v64si v10, v11, v12, v13;0;

	__asm__ volatile ("vlw.v %0, %1\n" : "=&v"(v10) : "A"(b[10]));
	__asm__ volatile ("vlw.v %0, %1\n" : "=&v"(v11) : "A"(b[20]));
	__asm__ volatile ("vlw.v %0, %1\n" : "=&v"(v12) : "A"(b[30]));
	__asm__ volatile ("vlw.v %0, %1\n" : "=&v"(v13) : "A"(b[40]));

	v10 = v11 + v12;
	v11 &= v12 - v13;
	v12 |= v13 * v10;
	v13 ^= v10 / v11;

	__asm__ volatile ("vsw.v %1, %0\n" : "=A"(b[40]) : "v"(v10));
	__asm__ volatile ("vsw.v %1, %0\n" : "=A"(b[50]) : "v"(v11));
	__asm__ volatile ("vsw.v %1, %0\n" : "=A"(b[60]) : "v"(v12));
	__asm__ volatile ("vsw.v %1, %0\n" : "=A"(b[70]) : "v"(v13));
}

ビルド方法は何でも良いですが、最適化レベルをOgにするとアセンブラが見やすいと思います。

$ riscv32-unknown-elf-gcc b.c -nostdlib -g -Og -march=rv32gcv -mabi=ilp32f

$ riscv32-unknown-elf-objdump -dS a.out

...

        __asm__ volatile ("vlw.v %0, %1\n" : "=&v"(v13) : "A"(b[40]));
   10092:       0a028793                addi    a5,t0,160
   10096:       1207e207                vlw.v   v4,(a5)

        v10 = v11 + v12;
   1009a:       022081d7                vadd.vv v3,v2,v1
        v11 &= v12 - v13;
   1009e:       0a120057                vsub.vv v0,v1,v4
   100a2:       26010057                vand.vv v0,v0,v2
        v12 |= v13 * v10;
   100a6:       9641a157                vmul.vv v2,v4,v3
   100aa:       2a208157                vor.vv  v2,v2,v1
        v13 ^= v10 / v11;
   100ae:       863020d7                vdiv.vv v1,v3,v0
   100b2:       2e1200d7                vxor.vv v1,v1,v4

        __asm__ volatile ("vsw.v %1, %0\n" : "=A"(b[40]) : "v"(v10));
   100b6:       0207e1a7                vsw.v   v3,(a5)

...

うまくいっているようです。良かった良かった。

GCCを調べる - その18 - ベクトルNot演算の定義

目次: GCC

前回（2020年7月19日の日記参照）は四則演算と論理演算（and, or, xor）を定義しました。今回はNot演算を定義します。他の論理演算と異なり、Not演算は2オペランドしか取りませんから、define_insnを別に書く必要があります。

;; gcc/config/riscv/riscv.md

(define_insn "one_cmpl<mode>2"
  [(set (match_operand:ANYV           0 "register_operand" "=v")
	(not:ANYV (match_operand:ANYV 1 "register_operand" "%v")))]
  "TARGET_VECTOR"
  "vnot.vt%0,%1"
  [(set_attr "type" "logical")
   (set_attr "vecmode" "<MODE>")])

前回同様に、ベクトル拡張記法（Vector Extensions (Using the GNU Compiler Collection (GCC))）を使ってビット毎Notを使うプログラムを書きます。

typedef int __v64si __attribute__((__vector_size__(256)));

void test()
{
	__v64si v10, v11;
	static int b[1024 * 1024] = {0};

	__asm__ volatile ("vlw.v %0, %1\n" : "=&v"(v10) : "A"(b[10]));
	__asm__ volatile ("vlw.v %0, %1\n" : "=&v"(v11) : "A"(b[20]));

	v10 = ~v11;

	__asm__ volatile ("vsw.v %1, %0\n" : "=A"(b[40]) : "v"(v10));
}

コンパイルするとエラーが発生します。何かお気に召さないようです。

$ riscv32-unknown-elf-gcc b.c -nostdlib -Og -march=rv32gcv -mabi=ilp32f

during RTL pass: reload
dump file: b.c.282r.reload
b.c: In function 'test':
b.c:14:1: internal compiler error: in setup_operand_alternative, at lra.c:814
   14 | }
      | ^
0xea5c36 setup_operand_alternative
        gcc/gcc/lra.c:814
0xea70c2 lra_set_insn_recog_data(rtx_insn*)
        gcc/gcc/lra.c:1073
0xea30f9 lra_get_insn_recog_data
        gcc/gcc/lra-int.h:488
0xeab0b9 remove_scratches_1
        gcc/gcc/lra.c:2058
0xeab4c4 remove_scratches
        gcc/gcc/lra.c:2094
0xeac629 lra(_IO_FILE*)
        gcc/gcc/lra.c:2396
0xe1a41f do_reload
        gcc/gcc/ira.c:5523
0xe1ae5c execute
        gcc/gcc/ira.c:5709

コードを見ると最後のオペランドに % を付けるべきではないそうです。確かにdefine_insnを見ると % が要らないのに付いています。

// gcc/lra.c

/* Setup info about operands in alternatives of LRA DATA of insn.  */
static void
setup_operand_alternative (lra_insn_recog_data_t data,
			   const operand_alternative *op_alt)
{
  int i, j, nop, nalt;
  int icode = data->icode;
  struct lra_static_insn_data *static_data = data->insn_static_data;

  static_data->commutative = -1;
  nop = static_data->n_operands;
  nalt = static_data->n_alternatives;
  static_data->operand_alternative = op_alt;
  for (i = 0; i < nop; i++)
    {
      static_data->operand[i].early_clobber_alts = 0;
      static_data->operand[i].is_address = false;
      if (static_data->operand[i].constraint[0] == '%')    //★★% が付いていればcommutative
	{
	  /* We currently only support one commutative pair of operands.  */
	  if (static_data->commutative < 0)
	    static_data->commutative = i;
	  else
	    lra_assert (icode < 0); /* Asm  */
	  /* The last operand should not be marked commutative.  */
	  lra_assert (i != nop - 1);    //★★このアサートに引っかかる
	}
    }

...

素直に応じるとエラーは消えます。

(define_insn "one_cmpl<mode>2"
  [(set (match_operand:ANYV           0 "register_operand" "=v")
	(not:ANYV (match_operand:ANYV 1 "register_operand" " v")))]    ★★% を消す
  "TARGET_VECTOR"
  "vnot.vt%0,%1"
  [(set_attr "type" "logical")
   (set_attr "vecmode" "<MODE>")])

四則演算、論理演算（3オペランド系）と、Not演算（2オペランド系）が揃いました。残りの頻出する演算はビットシフト系かな？

最後のオペランドをcommutativeにできない理由

最後のオペランドをcommutativeにしてはいけない理由は、GCCのConstraintsの説明を見るとわかります。

`%' Declares the instruction to be commutative for this operand and the following operand. This means that the compiler may interchange the two operands if that is the cheapest way to make all operands fit the constraints. GCC can only handle one commutative pair in an asm; if you use more, the compiler may fail. Note that you need not use the modifier if the two alternatives are strictly identical; this would only waste time in the reload pass. The modifier is not operational after register allocation, so the result of define_peephole2 and define_splits performed after reload cannot rely on `%' to make the intended insn match.

難しいことを言っていますが、commutativeは % を付けたオペランドと「次」のオペランドが可換だと宣言することだそうです。最後のオペランドには「次」のオペランドがありませんから、% を付けてはいけません。なるほど。

RISC-Vの場合は論理演算のdefine_insnの2番目のオペランドに % が使われています。

;; gcc/config/riscv/riscv.md

;; This code iterator allows the three bitwise instructions to be generated
;; from the same template.
(define_code_iterator any_bitwise [and ior xor])

...

(define_insn "<optab><mode>3"
  [(set (match_operand:X                0 "register_operand" "=r,r")
	(any_bitwise:X (match_operand:X 1 "register_operand" "%r,r")
		       (match_operand:X 2 "arith_operand"    " r,I")))]
  ""
  "<insn>%i2t%0,%1,%2"
  [(set_attr "type" "logical")
   (set_attr "mode" "<MODE>")])

例えばand r1, r2, r3とand r1, r3, r2は結果が同じですから、2番目と3番目のオペランドは入れ替え可能です。3つの論理演算（any_bitwiseはand, or, xorのこと）はいずれも同様に入れ替え可能ですので、このような定義になっています。

ARM SBCリスト2

目次: ROCK64/ROCKPro64

最近はたくさんのARMのシングルボードコンピュータ（SBC）が市販されています。2019年以降のボードも追加してみました。値段は変動するので参考です。

Amlogic S905X3

ボードHardkernel ODROID-C4, A55/2.0GHz x 4, 4GB DDR4-2666, 12nm, $50, 2020/04

Amlogic A311D (S922X + NPU)

ボードKhadas KVIM3-P-002, A73/2.2GHz x 4, A53/1.8GHz x 2, 4GB LPDDR4-????, 12nm, $160, 2019/06

Amlogic S912

ボードKhadas KVIM2-M-002, A53/1.5GHz x 8, 3GB DDR4-????, 28nm, $170, 2017/08

Broadcom BCM2711

ボードRaspberry Pi 4 Model B, A72/1.5GHz x 4, 8GB LPDDR4, 28nm, $75, 2019/11

HiSilicon Kirin 970

ボード96boards HiKey 970, A73/2.36GHz x 4, A53/1.8GHz x 4, 6GB LPDDR4-1866, 10nm, $299, 2018/??

MediaTek Helio X20

ボード96boards MediaTek X20, A72/2.1GHz x 2, A53/1.85GHz x 4, A53/1.4GHz x 4, 2GB LPDDR3-????, 20nm, $199, 2017/??

NVIDIA Xavier AGX

ボードNVIDIA Jetson Xavier AGX, Carmel/2.26GHz x 8, 8MB L2, 4MB L3, 32GB LPDDR4-2133, 12nm, $700, 2020/??

NVIDIA Xavier NX

ボードNVIDIA Jetson Xavier NX, Carmel/1.4GHz x 6, 6MB L2, 4MB L3, 8GB LPDDR4-1600, 12nm, $400, 2020/??

Rockchip RK3399

ボードFriendlyARM NanoPC-T4, A72/2GHz x 2, A53/1.5GHz x 4, 4GB LPDDR3-1866, 28nm, $109, 2018/??

Samsung S5P6818

ボードFriendlyARM NanoPC-T3 Plus, A53/1.4GHz x 8, 2GB DDR3, $75, 2018/??

古い世代のSoCを採用したボード達です。

AllWinner H6

ボードPINE64 PINE H64, A53 x 4, 2GB LPDDR3-1600, 28nm, $36

AllWinner H5

ボードFriendlyARM NanoPi NEO2, A53/1.5GHz x 4, 1GB DDR3, 40nm, $20

Amlogic S905

ボードHardkernel ODROID-C2, A53/1.5GHz x 4, 2GB DDR3-1866? (912MHz), 28nm, $39

Broadcom BCM2837B

ボードRaspberry Pi 3 Model B, A53/1.2GHz x 4, 1GB LPDDR2, 28nm, $35

HiSilicon Kirin 960

ボードHiKey 960, A72 x 4, A53 x 4, 3GB LPDDR4, 16nm FinFET, $239

NVIDIA Tegra X2 (Parker)

ボードJetson TX2, Denver/2GHz x 2, A57/2GHz x 4, 8GB LPDDR4, 16nm, $600

NVIDIA Tegra X1

ボードJetson TX1, A57/1.9GHz x 4, 4GB LPDDR4, 20nm, $500

Rockchip RK3328

ボードPINE64 ROCK64, A53/1.4GHz x 4, 4GB LPDDR3-1866, 28nm, $24.95 (1GB) $34.95 (2GB) $44.95 (4GB)

以前（2019年5月15日の日記参照）載せた情報も含んでいます。

またバッテリー死す

目次: 車

コロナ騒ぎが始まって、遠出することもなくなり、かれこれ4か月以上？車に乗らず放置していました。

骨折した奥さんを整形外科におくるため、JAFさんに車のバッテリー上がりを直してもらったんですけど、バッテリー電圧がなんと1Vしかありません。えー？？

車のバッテリー（鉛蓄電池）の端子電圧は12V程度が正常ですから、10Vの見間違い？と思いましたけど、何回見ても1.0Vでした。乾電池だってもうちょっと電圧あるでしょう。

今まで何度となくバッテリー上がりさせ、バッテリー破壊もこれで4度目（2007年、2013年、2016年、2020年）ですけど、1Vまで下がったのは初めてです。

割とお高いGS YUASA 80D23L大容量バッテリーを使っていたのですが、いかなるバッテリーであろうと、このレベルの過放電には無力ですね。エンジン掛かった後も全く充電される気配がありませんでした。

近所のイエローハットまでバッテリー交換しに行く道中が一番嫌でした。

• 4か月ぶりの運転
• バッテリー電圧が12V〜11Vくらいでグラグラ
• アイドリングが不調で止まりそう（バッテリー上がりでエンジンの調整データが消えた？）
• エンストしたら二度と掛からない

こんな状態で、産業道路〜環七〜第二京浜と走るのはかなり怖いです。無事に辿り着けて良かったけども。

また懲りずにPanasonic 85D23Lの大容量バッテリーに交換しておきました。3万円くらいしました。たっけぇ……。今年は車検もあるし、全然乗ってない割に金ばっかり掛かってます。不思議ですね。

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

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をサラウンドモードにすると、テレビから全く音が出ませんでした。がっかり。

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で、ビルド対象外になっています。手動で下記の設定を有効にする必要があります。

  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はアナログオーディオを使いたい場合に有効にしてください。

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だと思って再生してしまい、バリバリバリ！！という凄まじい音量のノイズが再生されることがあります。お試しの際は、音量を小さくしてからテストしてください。

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

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

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

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

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

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

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

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

Wikipedia

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

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

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

レガシィ5回目の車検

目次: 車

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

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

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

検査内容

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

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

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

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

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

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

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

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

CPAPの効果

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

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

CPAPなしの最初の1時間

そのあとの1時間

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

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

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

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

先日（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固定で使うことにします……。

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点だろうが、どうでも良いです。それよりもハントしたいだろ？なあ？

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