Main Menu
いらっしゃいませ入口 (Home) 出口 (リンク集) われも工房（同）サイト内全文検索サイト・プロフィール New! RSS 購読 Twilog
オタク系オヤジへの道オタク日記 New! 倉庫 19(Q1, Q2, Q3), 24Q2 倉庫 18(Q1, Q2, Q3, Q4) 倉庫 17(Q1, Q2, Q3, Q4) 倉庫 16(Q1, Q2, Q3, Q4) Mac でハック (1), (2) 自宅サーバを立てる Python Corner
つれづれなるままにわれもかう通信倉庫 13(Q2 Q3) 14Q1 San Diego 通信極私的批評空間倉庫 2002-2010 Lund 通信（遠島日記）
Site Management Access Count Server Status

オタク日記
(Mac と Linux, 2019Q2)

2019-06-29 (Sat): Raspi 3 B+ (4: Backup)
2019-06-26 (Wed): Raspi 3 B+ (3: PyVenv, LibROSA)
2019-06-22 (Sat): 保守速報 (2: Ubuntu-18.04 の Xorg)
2019-06-08 (Sat): Raspi 3 B+ (2: WiFi)
2019-06-05 (Wed): Raspi 3 B+ (1: 基本・共通設定)
2019-05-18 (Sat): 保守速報 (1: Let's Encrypt Certificates)
2019-05-01 (Wed): macOS を Mojave に (3: Audio, Siri)
2019-04-24 (Wed): macOS を Mojave に (2: Audio/Sound)
2019-04-17 (Wed): macOS を Mojave にアップグレード (1)

古い日記:
2019Q1
2018Q4   2018Q3   2018Q2   2018Q1
2017Q4   2017Q3   2017Q2   2017Q1
2016Q4   2016Q3   2016Q2   2016Q1
2015Q4   2015Q3   2015Q2   2015Q1
2014Q4   2014Q3   2014Q2   2014Q1

2019-06-29 (Sat): RasPi 3 B+ (3: Backup)

バックアップが大事なのは解っている！

ソフトウェアの開発 (らしき事) をやるなら、git-hub 他でバージョン管理をやり、同時に全環境のバックアップをマメに取るのは常識の範囲……。とりわけ Raspberry Pi の場合は、メインのストレージである SD card の信頼性が「今一」なので、バックアップには余程気をつけていないといけないのだが、そこはそれ、ヒートアップしてくると、つい疎かになる。

SD がらみのトラブルで「最初で最悪の奴」は、「一見普通に使えているのに、一旦電源を切ると、ある時点より新しい変更が無かった事になってしまう」というもの。この「ある時点」は、問題の原因だと思われる「RasPi を強制リブート」の 1 週間程前だった (リブートの度にファイルの modify date がその日時より前になっている事で分かった)。そのせいもあり、この問題になかなか気が付かず、壊れた SD で作業を続け、不可思議な誤動作に頭を捻っている間に納期が迫っていた、という悲惨な結果に……

その後も、故障モードは違うが、二度程 SD が壊れた。 (そもそもブートしなくなった。ヒートラン中にいつの間に止まっていたので原因ははっきりしない。)

なので、それが必要なのは身に沁みて解っているのだけど、実際にちゃんと全体のバックアップを取るのは、出荷の時くらい。後は、開発中のスクリプトやデータを含んでいるディレクトリを、rsync で、サーバに同期するくらいしかやっていない。

どうしてもやるんだっ、という事ならば、Boot SD Disk を取り外して、 Mac に挿し、dd command で、そのイメージをコピーという事になるが、これはとてもじゃないが、やってられない。

バックアップの度に RasPi の電源を落す必要がある。
16GB や 32GB の SD カードの場合、あっという間に、ストレージ内で膨大な容量を占めるようになる。 (それで、今のところ、8GB のを使っているが、それでも……)
dd comman での転送は結構時間がかかる。(Raspbian の配布 image を SD カードに転送する場合と違って、容量が大きいから。)

容量と転送時間の問題に対処するには、SD card の容量を縮小するのが良いが、極めて面倒だし、何より、実際に使っている boot (system) disk のパーティションを弄るのは危険が大きするぎる。

という事で、USB Card Reader/Writer を使う方向に方針変更する。これで、上記の問題の 1. はほぼ自動的に解決できる。使っている最中に Backup を取れれば、あとはそれを時間をかけて、Mac のストレージに転送すれば良いから 3. の問題も然程大問題ではなくなるだろう。

RasPi3B+ と USB Card Reader

Full Backup

等と構想を温めていたのだが、今一踏み出せないでいた。そんな時に半ば偶然に、 rpi-clone というアプリ (実体は bash script) を見付けた。このスクリプトの凄いところは、元の microSD card (Boot System) のクローンを USB card reader の microSD に作るのだが、それが bootable である事。

あんまり感動したので、思い腰を上げて、早速使ってみた。仮に、という事で、展開した場所で使ってみる:

fukuda@raspi23b:~% git clone https://github.com/billw2/rpi-clone.git
fukuda@raspi23b:~% cd rpi-clone 
fukuda@raspi23b:~/rpi-clone% ls
LICENSE  README.md  rpi-clone*  rpi-clone-setup*

USB card reader を挿して、8 GB の microSD を挿すところから:

fukuda@raspi23b:~% lsusb
Bus 001 Device 007: ID 0bda:0109 Realtek Semiconductor Corp. 
Bus 001 Device 005: ID 046d:0a3a Logitech, Inc. 
Bus 001 Device 006: ID 0424:7800 Standard Microsystems Corp. 
Bus 001 Device 004: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
fukuda@raspi23b:~% sudo fdisk -l
.....
Disk /dev/mmcblk0: 7.3 GiB, 7864320000 bytes, 15360000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1aaa0030

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk0p1       8192    96042    87851 42.9M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      98304 15359999 15261696  7.3G 83 Linux

Disk /dev/sda: 7.3 GiB, 7864320000 bytes, 15360000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start      End  Sectors  Size Id Type
/dev/sda1        8192 15359999 15351808  7.3G  b W95 FAT32

ここに、/dev/mmcblk0 が boot disk、/dev/sda が USB card reader に挿した新しい disk (パーティションをまだ切っていない)。この 'sda' という情報を使って、

fukuda@raspi23b:~/rpi-clone% sudo ./rpi-clone sda -f

Booted disk: mmcblk0 7.9GB                 Destination disk: sda 7.9GB
---------------------------------------------------------------------------
Part      Size    FS     Label           Part   Size    FS     Label
1 /boot   44.5MB  fat32  --              1      44.5MB  fat32  --
2 root     7.8GB  ext4   rootfs          2       7.8GB  ext4   rootfs
---------------------------------------------------------------------------
== Initialize: IMAGE mmcblk0 partition table to sda - forced by option ==
1 /boot               (23.0MB used)  : IMAGE     to sda1  FSCK
2 root                (4.3GB used)   : RESIZE(7.8GB) MKFS SYNC to sda2
---------------------------------------------------------------------------
.....
Initialize and clone to the destination disk sda?  (yes/no): yes #1)
Optional destination  ext type file system label (16 chars max): #2)

Initializing
  Imaging past the start of /boot partition 2.
  => dd if=/dev/mmcblk0 of=/dev/sda bs=1M count=52 ...
  Resizing last partition to end of disk ...
    Resize success.
  Changing destination Disk ID ...
  Delaying so partprobe can update /dev entries ...
  => fsck -p /dev/sda1 ...
  => mkfs -t ext4  /dev/sda2 ...

Syncing file systems (can take a long time)
Syncing mounted partitions:
  Mounting /dev/sda2 on /mnt/clone
  => rsync // /mnt/clone with-root-excludes ...
  Mounting /dev/sda1 on /mnt/clone/boot
  => rsync /boot/ /mnt/clone/boot  ...

Editing /mnt/clone/boot/cmdline.txt PARTUUID to use 181c0f6b
Editing /mnt/clone/etc/fstab PARTUUID to use 181c0f6b
===============================
Done with clone to /dev/sda
   Start - 16:22:51    End - 16:27:48    Elapsed Time - 4:57

Cloned partitions are mounted on /mnt/clone for inspection or customizing. 

Hit Enter when ready to unmount the /dev/sda partitions ...  #3)
  unmounting /mnt/clone/boot
  unmounting /mnt/clone
===============================

fukuda@raspi23b:~/rpi-clone%

ここに、

#1) ここは、yes
#2) 何もかかずに Return。(fdisk の option なので、変な事を書くと大変な事に)
#3) Return (Enter) で unmount までやってしまう。その前に、Ctrl-Z でエスケープすれば、mount された状態で、/mnt/clone/ 以下のファイルにアクセスできる。終われば '%' で戻り、Return を入力する。か？

何年も mount, umount, はたまた fdisk などと言う command を使ってないので、一部理解できない箇所もあるが、ともあれ、こうする事で、パーティションの resize と、boot system のファイルシステム (FAT の /boot, とそれ以外の ext4 からなる) をうまくコピーしてくれる……。

もう一度 mount して、hostname を変更する。つまり、 /etc/hostname と /etc/hosts の raspi23b のところを、raspi23c に置き換える。

fukuda@raspi23b:~% sudo mount /dev/sda2 /media
fukuda@raspi23b:~% sudo emacs /media/etc/hostname  
fukuda@raspi23b:~% sudo emacs /media/etc/hosts      
fukuda@raspi23b:~% sudo umount /media

ここで、上記の #3) に書いたように、rpi-clone の最後のところで、 Ctrl-Z のエスケープを使えば、mount/umount のステップ無しに、 /etc/{hostname,hosts} にアクセスできる。但し、/media の代りに /mnt/clone を使う必要がある。

こうしておいて、backup disk を現行の RasPi から引き抜き、別の RasPi (の SD card slot) に挿して、ブート。Mac からのログインを試みて、ちゃんと動いている事を確認する。

fukuda@falcon:~% ssh raspi23c
Warning: Permanently added the ECDSA host key for IP address '192.168.0.128' to the list of known hosts.
fukuda@raspi23c's password: 
Linux raspi23c 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l
fukuda@raspi23c:~% .....
fukuda@raspi23c:~% shutdown -h now

どうやら、hostname を除いて、完璧な backup になっているようだ。ここで hostname を変えたのは、raspi23b と raspi23c を並べて動かして、動作を確認したかったから。なので実際の backup には必要ないとも言えるが、ブートディスクとして運用する際には、こうした方が混乱が少ないような気がする。 (hostname をカードの ID とする訣。)

Desktop の HDD にセーブする

以上までで、完璧な (かつ bootable な) backup が作れた訣で、これを保存しておけば、とりあえずの目的は果せるだろう。ここではさらに Desktop に Image を作って保存する事を試みる。

まず、上の backup card (raspi23c) を Mac のスロットに挿し:

fukuda@falcon:~% sudo diskutil unmountDisk /dev/disk5     
Unmount of all volumes on disk5 was successful
fukuda@falcon:~% sudo dd bs=1M if=/dev/rdisk5 of=raspi23c.img
7500+0 records in
7500+0 records out
7864320000 bytes (7.9 GB, 7.3 GiB) copied, 92.0571 s, 85.4 MB/s
fukuda@falcon:~% ls -l raspi23c.img 
-rw-r--r-- 1 root staff 7864320000 Jun 28 19:25 raspi23c.img
fukuda@falcon:~% ls raspi23c* -l
-rw-r--r-- 1 fukuda staff 1607122692 Jun 28 19:25 raspi23c.img.gz
fukuda@falcon:~% cp raspi23c.img.gz Images/2019-06-26_raspi23c.img.gz

ここまでで、raspi23b の 2019-06-26 の backup をセーブできた。以上から、読み出しには 1 分半程しか掛からず、また、gzip による圧縮後は 1.6 GB 程度のサイズに押えられているので、パーティションの圧縮を端折った事のデメリットは然程大きくは無いと言って良い。

今度は、この逆のプロセスを試してみる。

fukuda@falcon:~% gunzip raspi23c.img.gz 
fukuda@falcon:~% ls -l raspi*
-rw-r--r-- 1 fukuda staff 7864320000 Jun 28 19:25 raspi23c.img
fukuda@falcon:~% ls /Volumes 
'Falcon BackUp'/   Linphone-4.1.1-mac/  'Macintosh HD'@
fukuda@falcon:~% sudo dd bs=1M of=/dev/rdisk5 if=raspi23c.img
Password:
7500+0 records in
7500+0 records out
7864320000 bytes (7.9 GB, 7.3 GiB) copied, 287.635 s, 27.3 MB/s
fukuda@falcon:~% sudo diskutil unmountDisk /dev/disk5
Password:
Unmount of all volumes on disk5 was successful
fukuda@falcon:~% sudo diskutil eject /dev/disk5
Disk /dev/disk5 ejected
fukuda@falcon:~%

ここに、書き込みには約 5 分かかっており、その後はマウントされたままになっている事に注意。

ここで、microSD を引き抜き、Raspi 3 B に挿して起動、それへのログインを試みる。

fukuda@falcon:~% ssh raspi23c                  
Warning: the ECDSA host key for 'raspi23c' differs from the key for the IP address '192.168.0.128'
.....
Are you sure you want to continue connecting (yes/no)? yes
Linux raspi23c 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l
.....
Last login: Fri Jun 28 17:36:33 2019 from 192.168.0.129
fukuda@raspi23c:~% ....

無事に boot し、23b とほぼ同じ振舞をしているように見える。

まとめ

以上、動作確認も含め長々と書いてきたが、要は

USB cardreader に挿した microSD カードにクローンを作る。
そのために、rpi-clone を使う。
- microSD を初期化して clone を作る:
```
% sudo rpi-clone sda -f
```
- 既存の clone に追加的に「増分バックアップ」を取る:
```
% sudo rpi-clone sda
```
partition/file_system の圧縮はやらない。
適宜、desktop のストレージに image を保存する。

に尽きる。

2019-06-26 (Wed): RasPi 3 B+ (3: PyVenv, LibROSA)

今回の RasPi の構築は、主に音声処理を狙ってのもの。予め、PyVenv on Python-3.7.3 on macOS での検討の結果、(偶々？) 新し目のモジュール LibROSA で旨く行ったので、その環境を Raspbian-2019-04-20 (Stretch) on RasPi 3 B+ に移す事を考える。

Python-3.7 + PyVenv

Stretch のデフォルトの Python3 は、3.5.2 で、これだと pip-compile/sync に問題が出る事が解ったので、3.6 以降にしないといけない。が、かつての (-l8.04 より前の) Ubuntu のように、PPA (Personal Package Archve) を加えて、とはいかず、どうも Python そのものをコンパイルしないといけないようだ。どうせ、コンパイルするなら、いっその事最新版に…… という事で、3.7.3 をコンパイル・インストールしてみた。

fukuda@raspi23b:~% sudo apt install -y libffi-dev libbz2-dev liblzma-dev \
libsqlite3-dev libncurses5-dev libgdbm-dev zlib1g-dev libreadline-dev \
libssl-dev tk-dev build-essential libncursesw5-dev libc6-dev openssl git
fukuda@raspi23b:~% wget https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tar.xz
fukuda@raspi23b:~% tar -xf Python-3.7.3.tar.xz
fukuda@raspi23b:~/Python-3.7.3% cd Python-3.7.3
fukuda@raspi23b:~/Python-3.7.3% ./configure
fukuda@raspi23b:~/Python-3.7.3% make
fukuda@raspi23b:~/Python-3.7.3% sudo make altinstall
fukuda@raspi23b:~/Python-3.7.3% /usr/local/bin/python3.7
Python 3.7.3 (default, Jun  1 2019, 16:32:57) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

案ずるより産むが易し、なんと一発で /usr/local/bin 以下にインストールできてしまった。勢いに乗って、PyVenv を構築:

fukuda@raspi23b:~% mkdir pve37
fukuda@raspi23b:~% python3.7 -m venv pve37
fukuda@raspi23b:~% ls pve37
bin/  include/  lib/  pyvenv.cfg
fukuda@raspi23b:~% cd pve37
fukuda@raspi23b:~/pve37% . bin/activate
(pve37) fukuda@raspi23b:~/pve37% pip install --upgrade pip pip-tools
(pve37) fukuda@raspi23b:~/pve37%

何なく、起動でき、pip と pip-tools (pip-compile/pip-sync) もインストールできた。

以降は、いきなり requirements.in を取ってきて、必要なモジュールを一遍に…… とやりたいところだが、どうもそれではうまく行かない (そもそも肝心の NumPy が pip install できない) ので、一つ一つ入れて行く:

(pve37) fukuda@raspi23b:~/pve37% sudo apt install libblas3
(pve37) fukuda@raspi23b:~/pve37% pip install numpy         
(pve37) fukuda@raspi23b:~/pve37% pip install ipython
(pve37) fukuda@raspi23b:~/pve37% ipython
Python 3.7.3 (default, Jun  1 2019, 16:32:57) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.5.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import numpy as np

In [2]: A = np.random.rand(1024, 1024)                                                

In [3]: %timeit B = np.linalg.inv(A)                                                  
12.9 s ± 291 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [4]: %timeit C = np.fft.fft2(A)                                                    
548 ms ± 203 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)

[3] [4] はいつものスピードチェックだが、linalg (行列の計算) が明らかにおかしい。 np.show_config() によれば、blas_{info,opt_info} は正しくインストールしたライブラリを指しているものの、 openblas_{info,lapack_info} が、いずれもNOT_AVAILABLE となっている。

OpenBLAS でなくても、fft.fft2() と桁が違う、という事はこれまでの経験では無かったが、ともあれ、 OpenBLAS をリンクする事を目指す。

とは言え、具体的にどうすれば良いか見当もつかなかったが、右往左往の結果、

(pve37) fukuda@raspi23b:~/pve37% sudo apt install libopenblas-dev libopenblas-base
(pve37) fukuda@raspi23b:~/pve37% pip install numpy  
.....
The following NEW packages will be installed:
  libblas-dev libblas3 libopenblas-base libopenblas-dev
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
(pve37) fukuda@raspi23b:~/pve37% ipython
Python 3.7.3 (default, Jun  1 2019, 16:32:57) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.5.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import numpy as np                                                            

In [2]: A = np.random.rand(1024, 1024)                                                

In [3]: %timeit B = np.linalg.inv(A)                                                  
1.16 s ± 6.78 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
    
In [4]: np.show_config()                                                              
blas_mkl_info:
  NOT AVAILABLE
blis_info:
  NOT AVAILABLE
openblas_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
blas_opt_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
lapack_mkl_info:
  NOT AVAILABLE
openblas_lapack_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
lapack_opt_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
    
In [5]: %timeit C = np.fft.fft2(A)                                                    
537 ms ± 190 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)

OpenBLAS をインストールして、それから numpy をコンパイル・インストールする事で、うまく、OpenBLAS とリンクできて、そのお陰で、linalg.inv() の実行速度が 10 倍になった……

LibROSA

LibROSA は音声処理のための Python パッケージで、既に macOS の上の Python-3.7.3 の PyVenv では、pip install librosa でインストールでき、しかも使用実績がある。が、Python-3.7.3 PyVenv on Raspbian では、そう簡単には行かなかった。あまりに右往左往したせいで、必要十分な手順になっているかちょっと自信が無いが、大体次のようにやった:

cython は予め手でインストールしておく
必要な llvm は、(エラーメッセージが示唆するバージョン他は全部無視して) clang+llvm-8.0.0 のバイナリ全体をダウンロードして使う。 clang+llvm-8.0.0-armv7a-linux-gnueabihf
llvmlite をインストールする前に、LLVM_CONFIG を定義しておく

上記の 2., 3. は、pip install librosa とやって得られる error message からはまず推測できない……

ともあれ、具体的には

(pve37) fukuda@raspi23b:~% wget http://releases.llvm.org/8.0.0/clang+llvm-8.0.0-armv7a-linux-gnueabihf.tar.xz
(pve37) fukuda@raspi23b:~% tar -xf clang+llvm-8.0.0-armv7a-linux-gnueabihf.tar.xz
(pve37) fukuda@raspi23b:~% mv clang+llvm-8.0.0-armv7a-linux-gnueabihf clang_8.0.0
(pve37) fukuda@raspi23b:~% sudo mv clang_8.0.0 /usr/local/
(pve37) fukuda@raspi23b:~% export PATH=/usr/local/clang_8.0.0/bin
(pve37) fukuda@raspi23b:~% clang --version
clang version 8.0.0 (tags/RELEASE_800/final)
Target: armv7l-unknown-linux-gnueabihf
Thread model: posix
InstalledDir: /usr/local/clang_8.0.0/bin
(pve37) fukuda@raspi23b:~/pve37% export LLVM_CONFIG=/usr/local/clang_8.0.0/bin/llvm-config
(pve37) fukuda@raspi23b:~/pve37% pip install llvmlite
(pve37) fukuda@raspi23b:~/pve37% pip install librosa

四苦八苦、右往左往を除いても、librosa とその依存パッケージをインストールするのに 1 時間以上かかった……。で取り敢えず必要としている処理の所用時間を測定してみた。

(pve37) fukuda@raspi23b:~/pve37% ipython
Python 3.7.3 (default, Jun  1 2019, 16:32:57) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.5.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import librosa                                                                

In [2]: audio_path = "/home/fukuda/Work-current/SampleVoices/katou.wav"               

In [3]: y, sr = librosa.load(audio_path)                                              

In [4]: %timeit y_shift  = librosa.effects.pitch_shift(y, sr, n_steps=-6)             
22.8 s ± 7.19 s per loop (mean ± std. dev. of 7 runs, 1 loop each)

In [5]: %timeit y_shift  = librosa.effects.pitch_shift(y, sr, n_steps=-6)             
14.3 s ± 166 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

という事で、CPU に他の負荷が無い場合は 14 sec, 他にコンパイルなどしていると、時に 40 sec を超える、という結果になった。ちなみに、この音声データの長さは約 38 秒なので、リアルタイム処理の破綻があり得るという事になる。

ちなみに、macOS (Mac-mini) では、約 1 秒で処理できた。

まとめ

Python-3.7 のポータビリティは素晴らしく、Raspbian (Stretch) でも、そのソースからの「コンパイル・インストール」に何の問題も無かった。
PyVenv の構築も、従来のモジュール、パッケージに関しては、殆んどの場合問題なく完了して、きちんと動作する。 (コンパイルを要するものは、インストールに時間がかかるが。)
但し、LibROSA はパッケージング、特に、ライブラリ群への依存性の記述に問題があるのか、単に % pip install librosa としたのでは全々ダメ。
また、scikit-learn, Cython, llvmlite 等、必要性に疑問があり、かつ、コンパイル・インストールが非常に困難で、かつ長くかかるパッケージへ依存している点は開発陣に再考を促したい。 (llvmlite は、全体で 1.5GBytes にもなる clang+llvm-8.0.0 に依存している。必然性は有る？)

2019-06-22 (Sat): 保守速報 (2: Ubuntu-18.04 の Xorg)

普段使っている Ubuntu-18.04 は宅外サーバ 2 基の上と、VMware Fusion の上のものだけだが、これらはとても安定していて、週一くらいのペースでやるアップグレードでも、問題が出る事は殆ど無かった。

ただ、前の二つには、そもそも X server は載ってないし、後のも ssh でログインする事が殆んどなので、要は X server はほんの偶にしか使わない。それが、今週に入って、たまたまさるアプリ (Linphone) を GUI で使う必要が出てきたので、何週間ぶりかで GUI からログインしようとしたが、ウンともスンとも言ってくれない (そもそも、Login prompt が出て来ない)。

Ubuntu-18.04 の Xserver が Login Prompt を出さなくなった！

焦りまくって、右往左往した経緯は取り敢えず後回しにして、結論から書くと、

Ubuntu を起動した後、Xserver もちゃんと起動している
但し、Login Prompt が出ない。(多分、過去何回かのアップグレードで、こうなったに違いない。)
対策は、ssh ログインして、 /etc/gdm2/custom.conf で、次の WaylandEnable ... を uncomment するだけ
```
[daemon]
# Uncoment the line below to force the login screen to use Xorg
#WaylandEnable=false
```

これだけで、reboot の後

Ubuntu-18.04 の Xserver の Login Prompt また出るようになった！

のように表示され、ここから login pane へ行ける。(たったこれだけのために、ほぼ半日棒に振ったよ。)

2019-06-08 (Sat): RasPi 3 B+ (2: WiFi)

2.4G 帯 WiFi の性能

'Wireless Headless boot' のためのかなりいい加減な wpa_supplicant.conf でも無事ブートできて、それ以降も問題なく動いている。AP 側の設定変更にも正しく適応できているようだ。

fukuda@raspi23b:~% iw dev wlan0 link
Connected to 10:6f:3f:87:19:16 (on wlan0)
	SSID: Kohei-AP
	freq: 2437
	RX: 71136 bytes (409 packets)
	TX: 32993 bytes (248 packets)
	signal: -56 dBm
	tx bitrate: 65.0 MBit/s

	bss flags:	short-preamble short-slot-time
	dtim period:	1
	beacon int:	100      
fukuda@raspi23b:~% wget http://falcon.otacky.us:8080/Python-3.6.2.tar.xz
.....
2019-06-08 06:39:47 (3.36 MB/s) - ‘Python-3.6.2.tar.xz.3’ saved [16907204/16907204]

おおまかな感想に過ぎないけど:

'tx bitrate' (= PHY rate) に関しては、従来の RasPi の WiFi モジュールと略同等の性能。(ひょっとしたら、若干改善されているかも。56 -> 65 Mbps)
但し、並べて比較した Mac-mini, MacBook Air では、全く同じ条件で、 PHY rate が 130 Mbps になる事が多かったから、それには及ばない。
どうやら MCS に制限がかけられているようなので、 wpa_supplicant.conf の設定を詳細化する事で何とかなりそうな気もするが、今のところ成功していない——そもそもあまりトライしていない。

5G 帯 WiFi 使いたい

これまで、Linux で「デュアルモードの WiFi モジュール」を使った事がないので、大いに身構えて右往左往したが、要は「wpa_supplicant.conf の network エントリを増やして、5G バンドの SSID を書き込むだけ」という事が解った。つまり

fukuda@raspi23b:~% cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=JP

network={
	ssid="Kohei5G-AP"  # for 5G-band AP
	psk="password"
	priority=1
}

network={
	ssid="Kohei-AP"  # for 2.4G-band AP
	psk="password"
	priority=0
}

とするだけ。こうやって、ずらずらと network を並べておけば、見付かった AP に自動で接続する。複数ある場合は、ビーコン強度の強い方に接続 (association) する (らしい。)

悩ましいのは、今回のように、2.4G と 5G の AP が両方存在して、 2.4G の方が若干電波が強いのに、敢えて 5G を選びたい、という時。しかしそれも、network の中に priority という項目を設けて、優先度の高い方に、「大きい」数字を振っておけば良い。

このように wpa_supplicant.conf を書換えておいて、 reboot すれば、(「唯一の接続方法」を改変しているので、ちょっと緊張したが) 何なく次のような「接続」が得られた。

fukuda@raspi23b:~% iw dev wlan0 link 
Connected to 10:6f:3f:87:19:17 (on wlan0)
	SSID: Kohei5G-AP
	freq: 5200
	RX: 16942593 bytes (100899 packets)
	TX: 3098007 bytes (30156 packets)
	signal: -68 dBm
	tx bitrate: 135.0 MBit/s

	bss flags:	short-slot-time
	dtim period:	1
	beacon int:	100

fukuda@raspi23b:~% wget http://falcon.otacky.us:8080/Python-3.6.2.tar.xz
      .....
      2019-06-07 18:58:55 (6.53 MB/s) - ‘Python-3.6.2.tar.xz’ saved [16907204/16907204]

どうやら所望の動作をしてくれているらしい。

ここにで出てないが、802.11n, Channel 40 HT40 での接続
'tx bitrate:' (= PHY rate) は MCS scheme の自動選択によって？ 81 Mbps ~ 150 Mbps の間で変動する。平均は 135 Mbps あたり。
2.4 G バンド (HT=20MHz) では、65 Mbps に張り付いていたから、平均値としてはほぼ倍の PHY rate となっている。
これは Mac-mini (81-270) よりは劣るが MacBook Air (54 - 108) とは遜色ないか、わずかに勝る性能である。
local net 内の Mac-mini (falcon) からの転送速度は 2.4 G に比較して改善はされているものの、PHY rate の増加に比例していない。多分、AP router (Buffalo WZR-HP-AG300H) の Ethernet 側の PHY rate (100 Mbps) に制限されているのだろう。

ちななみに、慣れた iwconfig を打ってみると

fukuda@raspi23b:~% iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"Kohei5G-AP"  
          Mode:Managed  Frequency:5.2 GHz  Access Point: 10:6F:3F:87:19:17   
          Bit Rate=135 Mb/s   Tx-Power=31 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=41/70  Signal level=-69 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:55  Invalid misc:0   Missed beacon:0

となる。見ての通り、iw コマンドで十分で、 iwconfig は「ついやってしまう確認衝動」——だけど、やっぱり iwconfig でも十分だよな ('Tx-Power=31 dBm' 以外は) と思ってしまう。

2019-06-05 (Wed): RasPi 3 B+ (1: 基本・共通設定)

基本構想

Raspberry Pi 3 B+ が出てもう 1 年になるのか……。Switch Science さんから買ったので、当然ながら Amazon の注文履歴になく、つい忘れていたよ。

で、またまた RasPi が必要になりそうなので、今さらながらではあるけど、とりあえず一通り使えるようにしておく。

とりあえず目指したのは

最初から Wireless Headless 構成に
WiFi は 5G band (11n) を使えるように
Python の仮想環境は venv で
Audio/Sound の入出力を使えるように

等々

Raspbian Install と基本設定

Monitor/Keyboard を使わずに、初回のブートから、(Mac の) Terminal.app から ssh でログイン…… というのは前からやっていたが、 RasPi Zero W や RasPi 3 A+ だと Ethernet が使えないので、代わりに WiFi でやらないといけない。で、やってみたらこれはスマート (便利) だわい、という事で、それ以降 RasPi は何でもこれで行く事にした

microSD カードを準備

まずは、2019-04-08-raspbian-stretch-lite.zip を torrent で取って来る。(macOS の場合は、Home に展開されて、 ~/2019-04-08-raspbian-stretch-lite.img となる。)

microSD (8GB) を Falcon (Mac-mini) のカードスロット挿して作業開始……の筈だったが、何故かこのカードが認識されない。初めてのトラブルだったので大いに焦る。かなり四苦八苦したが、 macOS を Mojave にした事による不都合らしく、SMC リセットが必要だった……(Shift + Control + Option を同時に押しながら、 Power ON して、10 秒保持する。)

fukuda@falcon:~% sudo diskutil list    #1)
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *121.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk2         121.1 GB   disk0s2
.....
/dev/disk4 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *7.9 GB     disk4
   1:                 DOS_FAT_32 NO NAME                 7.9 GB     disk4s1

fukuda@falcon:~% sudo diskutil unmountDisk /dev/disk4    #2)
Unmount of all volumes on disk4 was successful
fukuda@falcon:~% sudo dd if=2019-04-08-raspbian-stretch-lite.img \
    of=/dev/rdisk4 bs=1M    #3)
1720+0 records in
1720+0 records out
1803550720 bytes (1.8 GB, 1.7 GiB) copied, 66.4396 s, 27.1 MB/s
fukuda@falcon:~% cd /Volumes/boot
fukuda@falcon:/Volumes/boot% touch ssh    #4)
fukuda@falcon:/Volumes/boot% emacs -nw wpa_supplicant.conf 
fukuda@falcon:/Volumes/boot% cat wpa_supplicant.conf   #5)
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=JP

network={
  ssid="Kohei-AP"
  psk="password"
}
fukuda@falcon:~% sudo diskutil unmountDisk /dev/disk4
Unmount of all volumes on disk4 was successful

ここに

#1) microSD カードの device name /dev/disk4 を確認する。
#2) /dev/disk4を unmount する (必須)
#3) ここで、/dev/rdisk4 と bs=1M は転送 (書き込み) 速度を改善するために必須
#4) これだけで、RasPi boot 後、ssh login 可能となる
#5) さらに、このようなファイルを作る事で、上記の ssh login が、既存の AP を介して可能になる。

RasPi をブートして、raspi-config

microSD を RasPi に挿してブート。とりあえず、raspi-config で、以下の項目を設定:

1. N1 (Hostname): raspi23b
4. I1 (Change Locale): en_US.UTF-8
4. I2 (Change Timezone): Asia/Tokyo
4. I4 (Wi-fi Country): Japan
7. A1 (Expand Filesystem): Enable

fukuda@falcon:~% ssh pi@raspberrypi    #1)
pi@raspberrypi:~ $ sudo raspi-config    
pi@raspberrypi:~ $ sudo adduser fukuda    #2)
pi@raspberrypi:~ $ sudo adduser fukuda sudo    #3)
pi@raspberrypi:~ $ sudo apt update
pi@raspberrypi:~ $ sudo apt upgrade
pi@raspberrypi:~ $ sudo reboot

ここに

#1) hostname: raspberrypi, username: pi へ、password: raspberry で login
#2) 第二のユーザを作製。母艦 PC の username を合わせる事が大事
#3) 上記ユーザを sudoer 登録する

あまり本質的ではないが、この際の「表示の乱れ」が解消されていて、設定が楽になった (特にこの Locale の設定が難儀だったので有難い)。

Raspi-config は表示の乱れが改善された

2019-06-07 (Fri): 表示の乱れが直ったように見えたが、これはどうやら、raspi-config の改善によるものではなく、Mac の Terminal.app の設定によるもののようだ。つまりは、 Terminal -> Preferences -> Advanced で 'Unicode East Asian Ambiguous characters are wide' のチェックを外せば、件の表示の乱れは無くなる。

共通の環境を整備

再度 (今度は fukuda で) ログインして、いつもの (一部オタク趣味の) 環境を構築する。

ちょっとまだるっこしいかも、と思うが、長々と RasPi と付き合うなら、nano でなく Emacs ('emacs-nox'; No X なので然程大きくない)、 Bash でなく Zsh を使うとした方が結局は近道のように思う。また、Zsh の prompt を変更して、hostname だけを色分けする、というのも地味だが効率アップに貢献する。

Zsh, Emacs の RC ファイルを準備

Zsh, Emacs のインストールそのものは簡単であるが、設定ファイルを準備するのはかなり面倒。なので、専用の (簡略化した) RC ファイルを Mac (falcon) 上で作製しておいて、一気に rsync する事にした。

fukuda@falcon:~/raspi3_rcs% diff ~/.zshrc.orig .zshrc    #1)
3,5c3,8
< autoload -Uz promptinit
< promptinit
< prompt adam1
---
> # autoload -Uz promptinit
> # promptinit
> # prompt adam1
> autoload -U colors
> colors
> PROMPT="%n@%{${fg[green]}%}%m%{${fg[default]}%}:%~%# "  
13,14c16,17
< HISTSIZE=1000
< SAVEHIST=1000
---
> HISTSIZE=10000
> SAVEHIST=10000
37a41,43
> if [ -f ~/.zsh_alias ]; then
>     source ~/.zsh_alias
> fi
fukuda@falcon:~/raspi3_rcs% cat .zsh_alias   #2)
# Global aliases -- These do not have to be
# at the beginning of the command line.
alias -g L='|lv -Ou8'
alias -g H='|head -n 20'
alias -g T='|tail -n 20'
alias cp='nocorrect cp -i'
alias mv='nocorrect mv -i'
alias rm='rm -i'
alias ls='ls -F --color=tty' 
recent()
{ 
        /bin/ls -lt $1 | head -n 20
}
fukuda@falcon:~/raspi3_rcs% cat .emacs.d/init.el    #3)
(global-unset-key "\^h")
(global-set-key "\^h" 'delete-backward-char)
(global-unset-key "\^x\^h")
(global-set-key "\^x\^h" 'help-command)

ここに

#1) .zshrc.orig は、最初に (すなわち、~/.zshrc が無い状態で) zsh を起動した時に作られる .zshrc。変更点は最小限で:
1. a. prompt を変更
2. b. command history の記録するサイズを 10000 行に
3. c. 下記の .zsh_alias を読み込むように
しただけ。
#2) .zsh_alias も最小限で、非常によく使うもの、無いと「うっかり」でファイルを壊してしまいかねないもののみ。
#3) Emacs の設定ファイルは極端に短くなったが、 local のかな漢変換を使わず、メールの読み書きはせず、Python-mode package は使わず、と思い切れば、この程度のinit.el で OK。Built-in の python package が使えるようになっていて、Python code を読み書きするだけならこれで十分だし、ssh client (Mac 側) の Terminal.app + AquaSKK で、日本語の読み書きが可能。

共通のコマンドとその設定ファイルをインストール

fukuda@falcon:~% ssh raspi23b
fukuda@raspi23b:~ $ sudo apt install lv rsync zsh emacs-nox 
fukuda@raspi23b:~ $ rsync -Cuav falcon:raspi3_rcs/ .
fukuda@raspi23b:~ $ chsh fukuda
Password: 
Changing the login shell for fukuda
Enter the new value, or press ENTER for the default
	Login Shell [/bin/bash]: /bin/zsh
fukuda@raspi23b:~ $ zsh
fukuda@raspi23b:~%

2019-05-18 (Sat): 保守速報 (1: Let's Encrypt Certificates)

かなり右往左往したものの、とりあえず最初の自動 renewal もうまく行って、もうこれで一安心と思っていたのだが……

Mail による Warning がおかしい (digoc04)

事のおこりは、Let's Encrypt (以下 LE) から Mail で「あと 2x 日で Expire するよ」という警告が届き始めた事。自動 renewal を設定してあるので、有効期間が残り 30 日を切ると、cron で renewal script が実行され、また、90 日に戻る筈。が、日が経っても有効期限がどんどん減って行くばかり

To: <fukuda @ waremo.com>
Subject: Let's Encrypt certificate expiration notice for domain "imap.otacky.jp" (and 3 more)
From: Let's Encrypt Expiry Bot >expiry@letsencrypt.org<
Date: Wed, 15 May 2019 04:32:54 +0000
.....

Hello,

Your certificate (or certificates) for the names listed below will expire in 10 days 
(on 25 May 19 04:39 +0000). Please make sure to renew your certificate before 
then, or visitors to your website will encounter errors. 

.....
	imap.otacky.jp
	lists.otacky.jp
	smtp.otacky.jp
	www.otacky.jp
.....

一方で、certbot で確認すると、(当然ながら) 73 日残っている、と表示される。

fukuda@digoc04:~% sudo certbot certificates   
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: www.otacky.jp
    Domains: www.otacky.jp imap.otacky.jp lists.otacky.jp otacky.jp smtp.otacky.jp
    Expiry Date: 2019-07-29 02:54:40+00:00 (VALID: 73 days)   <<< (*)
    Certificate Path: /etc/letsencrypt/live/www.otacky.jp/fullchain.pem
    Private Key Path: /etc/letsenlcrypt/live/www.otacky.jp/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

ちょっと心配になってあちこち調べ回ったが、なかなか、これ、と言った情報が見付からない。でも、結局 LE のサイトでそれらしい「説明」を見つけたが、何と:

Domain name のセットに対する証明書を取得するごとに Email system はその時刻を起点として、経過時間を積算しはじめる。 (60 日を過ぎた時点で、renew を受けつけ始め、それを Email で知らせ、90 日で expire させる。)
全く同じセットを renew した場合は真正の renew と見做され、新たな経過時間の起点がセットされる。
そうでない場合は、renew と見做されず、「元のセット」の起点の更新は行なわれない (それに応じた失効時期の警告が出され続ける。) しかし、「新しいセット」の起点の設定が行われ経過時間の積算が始まる。

という事らしい。(「なんと……」なんて書いたけど、こうやって書き並べると「妥当」な有り様だとも思える。) 要するに「現在の Email による警告は無視して良い。」という事。

成程……だけど、やっぱり、古いセットと新しいのとで重複している部分 (つまり、otacky.jp 以外の全部) が expire する事はないのか、という不安は残る。5 月 25 日前後は、ちょっと注意して、www.otacky.jp を見守る事にしよう。

2019-05-26 (Mon): どうやら、{www,lists,imap,smtp}.otacky.jp 全ての certificates が無事だったようだ、 http -> https への強制変換も含めて。つまり、(http://)lists.otacky.jp へアクセスすると、https://lists.otacky.jp へ「転送」されて、緑の錠前ととも表示される。良かった！

Renew のタイミングは randomaize されている (digoc03)

上の digoc04 での「すったもんだ」のせいもあり、たまたま間近に迫っていた digoc03 上の /etc/cron.d/certbot による自動更新を注視してみる事にした。

が、いきなり慌てさせられる結果に…… % sudo certbot certificates の結果が 'VALID: 30 days' の後、'VALID: 29 days' となっていて、更新されてないように見える。

なので、まずは /etc/cron.d/certbot がちゃんと動いているを確かめようと思うのだが、これが簡単には行かない (systemctl が cron を制御するようになって、なんだか難しくなっている。) とまれ:

fukuda@digoc03:~% sudo lv /var/log/syslog 
....
May 16 12:00:01 digoc03 CRON[6135]: (root) CMD (test -x
   /usr/bin/certbot -a \! -d /run 
/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew)
....

fukuda@digoc03:~% systemctl show certbot.timer
Unit=certbot.service
NextElapseUSecRealtime=Thu 2019-05-16 23:23:08 JST
NextElapseUSecMonotonic=0
LastTriggerUSec=Thu 2019-05-16 09:39:44 JST
...

という事で、2019-05-16 12:00 にちゃんと /etc/crond.d/certbot は走っている。が、実行はそれから「11 時間 23 分後」の 2019-05-16T23:23:08 という事らしい。

「なんでや！」てなもんだが、改めて 43200 秒を計算してみると 12 時間となるので、たまたま長い方の端に近い時間を引き当てたという事だろう。

仕方がないのでそのまま寝てしまったが、翌朝確認するとちゃんと更新されていた。

fukuda@digoc03:~% sudo certbot certificates   
.....
Found the following certs:
  Certificate Name: www.waremo.com
    Domains: waremo.com dms.waremo.com www.waremo.com
    Expiry Date: 2019-08-14 13:24:04+00:00 (VALID: 89 days)
.....

ま、早い話が「早とちり」して慌てまくったが、証明書は正しく取得されていて、その renewal の設定にも問題無かった、という事か。それにしても、 Let's Encrypt のこの辺り (Email による警告や cron.d/certbot の構成) は「凝り過ぎ」でとっても解り難い。

2019-05-01 (Wed): macOS を Mojave に (3: Audio, Siri)

Audio の突然死

突然 Mac から音が出なくなるという件の問題は、その頻度が我慢できるぎりぎりの線に留まっている事もあり、なんとかイライラを押えながら使ってきた。勿論その間は何とか原因を特定しようと注意していたのであるが、結局何の手掛かりも得られなかった。解ったのは、どうやら何かのアプリを起動する事が切っ掛けになるのではなく、coreaudiod の再起動から「しばらく経つ」と出る、という事くらい。

突然死の原因究明

ただ、その後、Siri を使おうとしてみたり、また、Amazon.com の Prime Video のアカウントの復活を図ったりしている時に、上記の問題が邪魔をするという事があり、ちょっと「向き」になってきた。とは言え、Google の検索になかなかひっかからず、ようやく見付けた Apple の Communities の同様の問題にかんする Q にも、なかなか回答が付かなかった。同ページの「回答がつかない時は自分で質問してみたら？」なんていうかなりいい加減なアドバイスに従って (StackOverflow だと叱られそうな) 似たような質問を敢えてしてみたら、何と早速 reply がもらえて、それによると、S/W の衝突が原因かも知れないから EtreCheck というツールを走らせて、その full report を載せてみろ、と。

件の EtreCheck は App Store にも有って、評判が最悪 (一つ星) の上に、 1,800 円もするらしいけど、背に腹は……という事で、ダウンロードして走らせてみた。 (幸い、1,800 円は "full version" に上げるのに必要なだけらしい。) 結果は、"No Error", だが、幾つか Warning が有った。しかし、どの項目も今回の問題と関連は無さそうなものばかり。

が、その report には、"Audio Plugins" という項目があり、その中:

Audio Plug-ins:
   AirPlay: 2.0 (Apple - installed 2019-04-16)
   BridgeAudioSP: 5.39 (Apple - installed 2019-04-16)
   .....
   Apowersoft Audio Device New: 1.0.1.0 (? - installed 2019-02-25)
   .....

で Mojave インストールより古い Plugin "Apowersoft Audio..." が見付かった。これは Apowersoft Audio Recorder をインストールした時の「なごり」らしく、みるからに怪しい。

原因が解ればもう八割方解決したようなもの

まずはこれを消してしまう事を試みる……対応する directory を捜すのに手間取ったが、

fukuda@falcon:~% sudo rm -rf /Library/Audio/Plug-Ins/HAL/Apowersoft Audio Device New.driver/

で、あっさり除去できた。

coreaudiod を [Quit] -> [Force Quit] して respawn してみたら、ちゃんと音は出ている。加えて、Activity Monitor で、その前後の Statistics を比較してみると、

Apower plugin を削除前

Apower plugin を削除後

のように、はっきり違っている。特に %CPU については、audio が動いてなくても数% 以上有ったのが、 Apower plugin を削除した後は、0% になっている。(動き出しても 1% 以下。)

実際の検証はまだ 1 日程度なので「確実に直った」とは言えないが、ほぼ間違いないだろう。

まとめ

要は:

まだ High Sierra の頃に、ラジオ放送を録音しようとして入れた Apowersoft Audio Recoder に伴なって入った、'Apower Audio Device New' plugin が、同 App を削除しても残っていた。
その plugin が、Majove のインストールの際にもそのまま残っていた。
それが、coreaudiod の動作をおかしくしていた。

という事だろう。改めて Journal を読み返すと、Audio Recoder を install/uninstall して High Sierra がおかしくなったのを、Mojave に上げる事で何とかしよう、という思惑が有ったようだ。 (で、その思惑は見事に外れた……)

「相性」がこんなに問題になるとは、いやはや……(懐しいという感じもあるけど :-) ) でも、(サードパーティ製とは言え) ツールを使って見通しよく解析できて、それに基いて試した対策が一発で決まった訣で、やっぱり進歩してるなぁ macOS。

Siri は健在

現下のお題「音声変換」の直近の課題は Amazon Alexa を RasPi に組込む事なんだが、そのために Echo Dot を導入して弄っている事もあって、 Siri がどんな風に進化しているのか、つい試してみたくなったのだった。

「古い Mac では 'Hey Siri' がサポートされていない」を早とちりして、「Mojave には Siri が無い」と思い込んでいたが、勿論 😀 そんな事はない。

音声認識は素晴しい

Alexa の音声認識は、英語も日本語も素晴しいものが有るが、(Hey なしの) Siri もなかなかの物である。Mac 版の場合は、認識の途中結果が文として画面に表示されるので、特に印象的。私の酷い発音に応じて、酷い (途方もない) 単語が認識され表示されていくのに、言い終った途端に、文全体が書き直されて、大体自分の言った (つもりの) 文章になる…… 大したもんだ。

ただ、まあ、コマンドというか指示や質問をしている間は、大概「定型表現」だから、それ (文全体の確からしさから文を確定する) が効果大なのかも知れない。なので、これが dictation になったらどうなるか、が本当のテストになるのだろう。 (Sierra, High Sierra では dictation を試してみたが、あまり感心しなかった。)

Siri に dictation させるのにどうやれば良いか解らなかったので、前回同様、EmacsMac.app でやってみた。直接の比較にならないけど、なかなか良くなったと思う。驚いた事に、 'It's a holiday today, Greenery Day.' をちゃんと聞き取って、 'It's a holiday today greenery day' とタイプインしてくれた。 (私の発音から 'greenery' を聞き取るとは……。) Punctuation の補い方を勉強して、本格的に使い始めるかな？ (嘘です。自分が英語で考える、もしくは英作文するスピードなぞ、自分のタイピングで十分追い付けるし、その方がストレスが少ない :-)

やれる事も増えている

Amazon Alexa に刺激されたのか、Alexa にできる事は Siri も大抵できるようだ。'Play the podcast of NPR news.' で、Siri を起動、Podcasts の中から、'NPR News Now' を選んで再生してくれる。 (しかし、Alexa と違って、'Play the news' や 'Play NPR news' は理解しない。)

また、'Play a piano sonata by Mozart.' も (どうやってるのか解らないが :-) ) iTune のアルバムの中から、前に演奏していた Mozart を選んで再生してくれる。 (これにはちょっと感動した。)

ただ、App 間の連携は必ずしもスムースとは言えず、Security の設定と絡んで、 'Sorry, I have no ability to do it.' と言われる事がよくある。中でも「なんだかなぁ」だったのは、WiFi が off だと、Siri は私がどこに居るか解らないようだ。('Where am I?' に答えられないだけでなく、 'What's the weather?' 等、場所を特定しないといけない質問にも答えられず、 'I don't know where you are. Please turn on WiFi ....' などと言う。 (macOS の [Today/Notification] では事もなげに稲城市のお天気を表示しているので、「WiFi が on でなければ場所が解らない」は Siri のバグだろう。)

UI はちょっと……

Sierra になって、始めて Mac に Siri が載った頃、その使い勝手がどうだったか実はよく憶えていないので、それと比較して、という議論はできないが、現状の UI があまり洗練されているとは言えないのは確か。

何より、Siri の起動の key combination (short cut) が 'Hold Option Space' なのだが、これが慣れないと結構難しい。まあ、「難しい」という程でもないのだが、コマンドを発する度に押さないといけないので、時々間違えてしまう。

これも、Alexa は Hey Siri のように、音声で起動できるようになれば何て事はないだろう。むしろ、iPhone で使える Hey Siri が、何故 (古い) Mac で使えないのか (使えるようにしないのか) 不思議なくらいのもんだ。

ただまあ iPhone 附属のヘッドホンを使う場合は、Siri をヘッドホンの「スイッチの長押し」で起動できる。これは便利だ。 Cloud Player 他を Safari から起動していると、このスイッチもボリュームコントロールも、はたまた mic も (iPhone の時と同様) ちゃんと使える事もあり、ますます iPhone ヘッドホン凄い、となった。あと、音質もこのヘッドホンの方が、Echo Dot より遥かに良い。使い始めた頃は、「間に合わせ」のつもりで「そのうち Wireless のヘッドホンを」と思っていたのだが、こうなるともう暫くはこのヘッドホンで行くしかないな。

2019-04-24 (Wed): macOS を Mojave に (2: Audio/Sound)

音声の再生は専ら iPhone からだった

実は、このところ Audio/Sound の分野ではあまり Mac-mini (Falcon) の出番は無かった。 DVD や Amazon prime で映画を観る時はさすがに Falcon だが、それ以外の殆んど全て、例えば、 Podcast でニュースを聞く、らじる & らじるでラジオ放送を聞く、 Audible で「本を聞く」……いずれも、iPhone の上でやるようになってきていた。

最初は些細な差だったように思う。 iPhone の Podcast App の方が、iTunes より UI が (やや) 洗練されている、とか、 iPhone の Audible App の方が、Amazon Cloud Player よりやや使い勝手が良い——ヘッドホンの「コントローラ」が使えるとか、章毎のプログレスバーが見える、等等。そのうち、ヘッドフォンを継ぎ直す、もしくは取り換えるのが面倒という事もあり、段々 iPhone で何でも聞くようになっていたのだと思う。

おまけに、High Sierra の晩年は、音声を処理する自作プログラムを走らせたり、ラジオを録音するアプリをインストールしたりしたせいか、時々、音声が全く再生されなくなる、という問題が発生していた。一旦ダメ、となると、どのアプリからも全くウンともスンとも言わなくなり、iTunes の progress bar もちっとも進まない。何だか、ずーっと奥の深いところで、壊れている気配。「音声処理」は今後の開発委託の中心的な「お題」となりそうなので、何とかしないといけないのだが、これはちょっとてこずりそう……という事で、前述の通り、ずっとほっぽっていた「Mojave へのアップグレード」に踏み切ったのだった。

Mohave で何でも聞けるように

アップグレードの結果、「ウンともスンとも言わなくなる」という問題は解消できたように見えたので、懸案だった、「音声は全部 Mac-mini へ」を実行してみた。

Audible を Safari の上の Cloud Player で聞く: そもそも、英語の本は (Mac-mini の) Kindle で読みながら朗読を聞く事が多いので、これは嬉しい、便利だ。また、head phone からの (ON/OFF, Volume 調整) が効かないという問題も、Player を Safari から起動すれば解決する事が解った。
Podcast を iTunes で聞く: 全般的に iTunes の「分かり難さ」はコンスタントに悪化する一方だが、 Podcast の「定期的 download とその維持」などは、その際たるものだろう。でも、まあ、ニュースを二種類 (NPR と BBC) だけ、後は、Apple の Keynotes だけ、というように大幅に狩り込んで、かつ入れ子の深さを制限する事で、十分使えるものになったような気がする。 (固より head phone からのコントロールは OK.)
HyperCard の TTS を BasiliskII で聞く: これは、どうやら Mojave にしたから、ではなくて、BasiliskII をアップグレードしたおかげ、みたいだ。下に書いたように、最初は大いに感激したが、使っているとかなり不安定な事が判明。再生ボタンを押しても再生してくれない、悪くすると、BasiliskII 自体が落ちる……。
Oxford Advanced Learner's Dictionary 9 App: OALD7 は、lookup を使って、Emacs の上で、他の辞書と「串刺し」検索ができるようになっているが、OALD8 以降は専用アプリケーションを使っている。最近、OALD9 にアップデートされた。串刺し検索ができないのは残念だが、Appli だと、単語や例文を発音して (読み上げて) くれる、というメリットもある。しかも、これが (head-phone を継ぎ換える事なく) すぐ使えて嬉しい。
EmacsMac.app の TTS を聞く: 聞きたい region を選んで、⌘-T とやると、Alex がその部分を読み上げてくれる。(従来通り)

「らじる ★ らじる」も、Audible Cloud Player も、ずっと起動しっぱなし、という訣にはいかない (時間が経つと、起動ボタンが反応しなくなるので、その都度、player を再起動しないといけない) というあたりが、若干スマートではないが、それでも、一つのスクリーンで音声関連を全てコントロールできる、というのは大きな進歩だろう。

やっぱり音声が「落ちる」事がある

凄いぞ、Mojave! と言いたいところだが、音声に関してあんまりあれこれ一遍に試したせいか、 High Sierra で問題になっていた「時々ウンともスンとも言わなくなる」が再発した。

頻度はとても低い。ずっと音楽を流したり、ニュースを聞いたりしていても、一日に一回か、それ以下。
何が引き金になるか解らない。(が、Idle Sleep から戻ってくる時、はたまた、 Appli を切り換える時に「問題」が発生する確率が高いような気がする ——単なる感想ですが。
一つのアプリだけダメになる、という事はなく、一旦症状が出ると、音声の再生が一切されない。
どうやら、「問題」は macOS の daemon の一つの coreaudiod にあるようだ。再生が止まった後、coreaudiod (それでも動いている) を Acitivity Monitor のペインから強制終了させると、また自動で relaunch され、全ての問題が解決されるから——今のところ (4 日、強制再起動 4 回) 例外なく成功している。

大抵の問題は coreaudiod を殺せば解決する

という事で、少々残念な状況ではあるが、まあ、 (「iPhone をメインに」に戻らず) なんとか使い続けている。しかし、こういうトラブルは結構有るに違いないと思い、ちょっとサーチしてみると、なんと Apple Community に、 'Audio drops randomly - killing coreaudiod is the only solution' という「そのものズバリ」の質問があった……が、二ヶ月近く経った今も誰も答えていない。次の Mohave のアップデートで何とか直っていると嬉しいんだがなぁ。

2019-04-17 (Wed): macOS を Mojave にアップグレード (1)

APFS にしたい……

とずっと思っていた。HFS+ も悪くはないが、Disk Utility の診断で permission error がしつこく残るとか、はたまた、日本語ファイル名の扱いに失敗するとか (特に、Windows で製作・圧縮されたディレクトリの日本語ファイル名が酷い) 等の「偶に出るだけだけど結構うるさい」問題が解決されるのでは、との期待が有った訣。だが High Sierra で APFS が導入された時、Fusion Drive は除外されていたので、我 Mac-mini は対象外だった。(MacBook Air はすんなり APFS になっていた。)

で、いよいよ Mojave でそれが実現する見通しとなったのだが、「上書きアップグレード」で、なんでファイルシステムが変更できるのか、どうしても納得できなくて、半年あまりの間「様子見」をしていた :-)

しかし、最近、音声を弄る (処理する) プロジェクトに手を染めかけている事もあり、かつては鬼門として避けていた sound 関連のアプリを若干入れてみたりしたが、早速地雷を踏んだようで、 Safari (の上の Audible Player on Browser, YouTube) や Skype, はたまた Line で「音声が再生できない」という問題が出た。

で、この問題で四苦八苦するなら、一層の事、macOS をアップグレードしてやろう、と。

インストールはスムース

例によって、App Store でインストールボタンを押すだけ。 High Sierra の時と比較してかなり「順調」で手間要らず:

10.14 をインストールするのに、1 時間 25 分かかった。この間、終了までの時間を何度か再計算するが、大まかに言って単調減少ではあった。
10.14.4 にアップグレードするのに 36 分。
インストール前にあれこれ聞かれる項目が大幅に減っている。
インストール後、完了前に聞かれる項目は、Goolge アカウントへのログイン・クレデンシャルのみ。
いずれ必要になるので、Xcode もアップグレードしておいた。これにもやっぱり時間がかかったが、測定はしなかった。

ざっと確認したところ、動かなくなっている 3rd Party Appli は無い模様。 (High Sierra に上げた時は、「駐車禁止」マークがついた Appli がいくつか有った。)

一方で、プリインストール・アプリとしては、News, Home が新しく入っており、代りに Siri が消えた。(実は、ちょっと試した後、全く使ってなかったけど、これからスマート・スピーカーと比べようと思っていたのに……残念！)

当然の事ながら、ファイルシステムは APFS になっている。

Mojave で APFS になった

MacPorts

何はともあれ、MacPorts を更新しなければ。

ちょっと利巧になって、旧版の MacPorts パッケージは消さずにそのままにしておいた。そのため、emacs-mac, Terminal.app がそのまま使えた。

まずは command line tools のインストール

fukuda@falcon:~% xcode-select --install

'MacPorts base system' (MacPorts-2.5.4-10.14-Mojave.pkg) を <https://www.macports.org/install.php> からダウンロードしてインストール。こうしておくと

fukuda@falcon:~% sudo port selfupdate 
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.5.4 installed,
MacPorts base version 2.5.4 downloaded.
--->  Updating the ports tree
--->  MacPorts base is already the latest version

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated
fukuda@falcon:~% port outdated
The following installed ports are outdated:
apache2              2.4.39_0 < 2.4.39_0  (platform darwin 17 != darwin 18)  
apr                  1.6.5_0 < 1.6.5_0  (platform darwin 17 != darwin 18)  
apr-util             1.6.1_2 < 1.6.1_2  (platform darwin 17 != darwin 18)  
.....

のように、port コマンドが使えるようになる上に、既存の port package のバージョンが、darwin のバージョンも含めて比較されているので、ひょっとしたら、'port upgrade' でやれてしまうのではないかと思い、ダメモトでやってみた。すると……

fukuda@falcon:~% sudo port upgrade outdated
--->  Fetching archive for apr
--->  Attempting to fetch apr-1.6.5_0.darwin_18.x86_64.tbz2 \
         from http://kmq.jp.packages.macports.org/apr
--->  Attempting to fetch apr-1.6.5_0.darwin_18.x86_64.tbz2.rmd160 \
         from http://kmq.jp.packages.macports.org/apr
--->  Unable to uninstall apr @1.6.5_0, the following ports depend on it:
--->  	apr-util @1.6.1_2
--->  	serf1 @1.3.9_1
--->  	nmap @7.70_0+pcre+ssl+subversion
--->  	subversion @1.11.1_0
--->  	apache2 @2.4.38_0+preforkmpm
--->  	apache2 @2.4.39_0+preforkmpm
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating apr @1.6.5_0
--->  Cleaning apr
--->  Uninstalling apr @1.6.5_0
--->  Cleaning apr
--->  Installing apr @1.6.5_0
--->  Activating apr @1.6.5_0
--->  Cleaning apr
--->  Fetching archive for expat
--->  Attempting to fetch expat-2.2.6_1.darwin_18.x86_64.tbz2 
         from http://kmq.jp.packa
.....

のように、High Sierra 用のパッケージをアンインストールした上で、 Mojave 用のパッケージがインストールされる。凄い！ (これまでのように、手で既存のパッケージの構成を保存したり、コマンドを消去したりする必要が無い訣だ。)

HyperCard on BasiliskII

いつもなら、これのコンパチビリティを真っ先に心配するのだけど、今回は、ちょっとうっかりしていた。が、とりあえず、動いた。ただ、従来からある問題はそのまま:

長く起動したままにしておくと、たまに画面の R と G が飛んでしまい、 B だけになる。(カーソルを動かすと直る。)
(HyperCard で) 再生される音声が、1 オクターブ程高くなる。
(HyperCard が) 日本語のコピーペーストを受け付けない。
かな漢字変換として、BasiliskII 内の「ことえり」をつかうしかない。

「そのうち HyperCard は卒業するから、ま、いいか……」といつものように、達観 (諦観？) しそうになったけど、たまたま (久し振りに) Emaculation を眺めていたら BasiliskII が新しくなっている事を知って、試してみる事にした。

同サイトに示されているところから、BasiliskII_sdl2_64bit_20180711.zip をダウンロードし、
インストールは、その中身の BasiliskII.app と BasiliskIIGUI.app を /Applications/ へ、keycodes を ~/BasiliskII/ へ copy するだけ。
BasiliskIIGUI.app をダブルクリックして起動、 [Keyboard/Mouse] タブで、'Use Raw Keycodes' が新しくインストールした keycodes を指すようにする。

Raw Keycodes が、新しい keycodes (keycodes.new) 指すように設定

まだ、keycodes がどう変わったのかもよく見ていないが、数日使ってみて、かなり色々改善されている。とりわけ上記の「問題」は:

表示が Blue だけになる: まだ使い始めて三日程なので、はっきり改善したとは言えないが、とりあえずまだ発生していない。
TTS (Text to Speech) の音声がカン高くなる: きれいに治った。しかし、所詮は Victoria なので、聞き取れるようになったというだけで、macOS の Alex や Samatha の自然さには遠く及ばない。
日本語のコピーペースト: 驚いた事に、HyperCard の field のフォントが Osaka になっていれば、何の問題もなく、(例えば Emacs との間で) 日本語がコピーペーストできる。Osaka でないと、ペーストした時点では文字化けするが、後で Osaka にすれば、ちゃんと表示される。
かな漢字変換: 上記の「改善」で、AquaSKK が使えるのではないかと大いに期待したが、全くダメだった。残念！ (まったく見当違いの期待だったような気もするが。)

ということで、首尾は上々！Mac 側の OS がどんどんアップグレードされても、ちゃんと動き続けるだけでなくて、ますます改善されていく……まったく、作者の R. P. Regensburg さんには感謝の一言！ (しかし、これで、「HyperCard 卒業」はますます遠退いたような気がする :-)

360/1,781,605

Taka Fukuda

Last modified: 2021-10-09 (Sat) 06:30:41 JST

オタク日記 (Mac と Linux, 2019Q2)

目次