Codec 2 を試してみる(17-Jan-2019)の続編的な話。あれからCodec 2に700Dモードに加え、LPCNetを使用したFreeDV 2020モードが利用できるようになっています。c2enc/c2decではなくlpcnet_enc/lpcnet_decを使うところから、Codec 2とは別系統と考えるべきかもしれませんが。

このLPCNet(FreeDV 2020)、使うためにはAVX必須と言われていてSSEじゃ駄目なんですかという疑問があり、SSEによるベクトル化を試してみました。

LPCNetを使うには、Codec 2のGitHubリポジトリに書かれている手順（Codec 2→LPCNet→再度Codec 2のビルドを行う）で基本的には問題ないものの、OpenBSD上でビルドする際はcmake -DDISABLE_CPU_OPTIMIZATION=ON -DAVX=ON -DCODEC2_BUILD_DIR=/path/to/codec2/build_openbsd/ ..のように拡張命令セットの指定を自動ではなく手動で設定する必要があります。また、これはOpenBSDに限った話ではないのですが、CODEC2_BUILD_DIRのパスは相対パスではなく絶対パスで記述します。

FreeDV 2020 tests with FreeDV APIの説明には、cat ~/LPCNet/wav/wia.wav | ~/LPCNet/build_linux/src/lpcnet_enc -s | ./ofdm_mod --ts 0.0205 --nc 31 --ldpc 2 --verbose 1 -p 312 | ./ofdm_demod --ts 0.0205 --nc 31 --verbose 1 --ldpc 2 -p 312 | ~/LPCNet/build_linux/src/lpcnet_dec -s | aplay -f S16_LE -r 16000と書かれていますが、OpenBSDで動かす場合aplay〜の部分はaucat -r 16000 -e s16le -i - -h rawとでも読み替えておけば良いでしょう。

とりあえず、lpcnet_encとlpcnet_decでLPCNetへのエンコード/デコードを行うことは分かりました。この部分の処理がどの程度時間がかかるのか、こんなテストをしてみました。

cd /path/to/LPCNet
cd build_directory/src
time cat ../../wav/all.wav | ./lpcnet_enc -s > test.out
time cat test.out | ./lpcnet_dec -s > /dev/null

LPCNet/wavディレクトリにはテスト用のWAVファイルが色々ありますが、とりあえず一番大きなall.wav(49sec, 16000Hz, 1ch, s16le)を使用します。framboise(A10-7860K)で試した場合、timeコマンドから得られたrealの値はエンコード時が2.567s、デコード時が21.907sとなっていましたのでエンコードよりもデコード処理がかなり重いと言えるでしょう。

これはAVXでの状況です。FreeDV 2020用LPCNetはオリジナルのLPCNetと同様にSSE用のコードは全く入っていないため、Arm NEON用のコードを参考にSSE命令を使った処理(vec_sse.h)を追加して動作を試してみました。

SSEによるベクトル化がきちんとできているかどうかの確認については、test_vecの結果がpassかfailかで判断できます。問題ないことを確認した後に動作速度の測定を行いましたが、どうもSSE 4.1指定の有無でデコード速度が大きく変わるようです。

なお、ベクトル化無しでの速度も測ってみましたが、エンコード2.552s、デコード1m42.005sとなったためベクトル化の効果はあるようです。

SSEが高速ではないAMD Bulldozer系の石でぎりぎりの性能は出ているようなので、Intel系の石ならSSEによるベクトル化でも実用になるのかもしれません。ちょっとissueを投げて様子をみてみます。58.60kg(14:25)

Podcast風(?)の実験としてMP3ファイルを作ってみました。自分の声、軽いのであんまり聞きたくないんですけど他の人からすれば実際にこう聞こえてしまうのだから仕方が無いですね…

今回はこんな感じで作業。

• Android端末にPCM録音をインストール
• PCM録音の設定はサンプルレート44100Hz、マイク感度の調整ON、マイク感度は真ん中
• 得られたWAVファイルをGoldWaveで編集、余計な部分や噛んだ箇所は削除（それでもバレる）、音量調整は+20dbする必要があった
• LoFi化を狙って16000Hzにリサンプリング
• lame -m m -b 96として96kbpsモノラルなMP3を作成

各種設定は今後見直す予定です。MP3のビットレートは喋り主体ならもう少し下げても大丈夫そうですが、少し余裕を持って96kbpsにしておきます。

録音は（MP3ファイル中でも喋っていますが）車の中で録るには録れるものの、編集は裏でガキどもがぎゃーぎゃーやっている環境下では無理です。イヤホンしていてもガキの声が突き抜けてくるのでどこを編集しているかが全然分からない…勘弁して…助けて…

とりあえず喋り/音ネタを解禁したので（って別に今まで禁止していた覚えもないんですが）、以前から試してみたかったものをそのうちやってみる予定です。58.75kg(20:20)

これに加えて普及したwebcamとマイクで動画やpodcast作りが今よりも流行るのかなとか思っておりまして。今でも十分流行ってますけど。

Instagramで映える写真、機材だけでなく構図やライティングは確かに大事ですがカメラの撮って出しではなくRAW現像などの事後処理の比重が高いように見えます。動画やpodcastもまた然りで、編集技術が無いと見て/聴いてもらえないのも事実。

という訳で、編集技術なんてものは持っていないしそもそも編集すること自体面倒なのでマルチメディア系（今となっては死語ですが他にうまく表現できる言葉も見つからない）には手を出さないようにしていたのですが、こういう状況だと避けてもいられないなと考えています。

動画編集なんてやること多すぎてツラそうな（最近は説明用にこんな動画を作ってみたのですがWindowsのビデオエディターで切った貼ったしているだけなので編集とは言えない）ので、音モノならもう少し編集のハードル低いかなと思いつつ、これはこれで大変そうです。オーディオ沼見れば分かりますが…音質へのこだわりとかその領域に手を出しちゃうと。

とりあえず何かやってみないことには技術習得も何もないので、結果がどうあれここで愚痴ってる暇があるなら手を動かせ、なんですけどね。58.85kg(06:05)

Twitter上でも散々吠えましたが、ここでも吠えます。

以下の二つの産経新聞の記事。

• （独自）週末のアマチュア無線の国家試験実施へ　国の方針に批判も (03-Apr-2020)
• アマチュア無線の試験、急遽中止に　受験者への通知間に合わず (04-Apr-2020)

どうせ将来は消されて記事の存在自体が無かったことにされてしまうのでしょうから、魚拓へのリンクも。

• （独自）週末のアマチュア無線の国家試験実施へ　国の方針に批判も (03-Apr-2020・魚拓)
• アマチュア無線の試験、急遽中止に　受験者への通知間に合わず (04-Apr-2020・魚拓)

03-Apr-2020の記事において、

• 趣味のための同試験を実施する国の方針には批判も上がりそうだ
• 受験予定者の中からは「アマチュア無線は不要不急の資格で、中止すべきだ」との声も上がる

という部分、国の方針を実際に批判した人間はいるのか？そして、受験予定者でそういう声を上げた人は本当にいるのか？という疑問があります。それに加え、もしアマチュア無線ではなくプロ資格の無線従事者試験だった場合、そもそもこのような記事を書いたのかどうか、も。

04-Apr-2020の記事によれば、1アマの受験申込者数は657名、2アマの受験申込者数は315名だそうです。試験を行う日本無線協会は03-Apr-2020の記事にもあるように「受験費用の返金や次回以降の受験資格を与える」とのアナウンスを行っていましたから、受験が危険だと判断した受験者は延期するなりキャンセルするなりの措置を記事が出る前までに行っている筈です。なので、記事を書く時点で、取材対象（お望みの台詞を吐いてくれる受験予定者）を首尾良く捕まえる可能性はより低い。

この記事は、産経新聞社がアマチュア無線に対して批判を行いたい、「不要である」と悪意をぶつけたかっただけと解釈するのが適当そうです。先の疑問点に挙げた、国の方針に対する批判者や、不要不急の声を上げた受験者が、実際にいるかいないかに関わらず。

真面目に心配するのであれば「コロナ流行　週末の資格試験は大丈夫か」とユルい表題とし、TOEICや銀行業務検定試験などの中止や延期する例を記した上でアマチュア無線の試験が近日行われるようだが感染拡大のリスクが懸念される、程度の内容で十分。国への批判も、受験予定者の声も、要りません。

03-Apr-2020の記事を受けてか、04-Apr-2020には日本無線協会も試験を中止するとのアナウンスを急遽出しました。それに対する後追い記事をきちんと出した点は評価しますが…「ペンの力で試験を潰してやったぜ、へへん♪」と妙なヒーロー気取りを今後も続けるかどうか、アマチュア無線なら叩いても大丈夫と調子付くかどうか、これらについては厳しく監視する必要があります。58.45kg(22:20)

※この日記では日付の表記になるべくdd-mm-yyyyを使用するようにしていますが、今回は（もしこのシリーズが続くならそれも）読みやすさを重視して一般的な表現としています。年・月の表記が省略されている箇所は、それぞれ記事の書かれた年・月と解釈してください。

SARS-CoV-2の蔓延によるCOVID-19禍の進行を抑えるために8日に日本国政府は7都府県（東京・神奈川・埼玉・千葉・大阪・兵庫・福岡）に対し緊急事態宣言を発令し、一ヶ月程度の期間外出自粛等の行動制限を行うことで事態が収束すれば良いなという状況になっています。ただし、一ヶ月で確実に終わるとは誰も言っていません。

娘は小学校に通っていますが、2月27日に小学校・中学校・高等学校に対する臨時休校要請があり、これを受け3月3日から休校になっています。息子の通う幼稚園に関しても、この状況を考慮して休園しています。相模原市では2月に市内の病院に入院する患者や研修医、鉄道職員が感染し、2月27日の時点で12例の患者が確認されていました（詳細は市の特設ページを参照）。（ここから個人的な印象の話）2月末の時点では相模原市の感染者数は他の都市と比べて多かったようで、随分と相模原市に対するマスコミによる批判的な意図を含む報道は多かったように感じます（ここまで）。その影響もあったのでしょうか、休校措置は速やかに行われました。

休校措置は今月に入ってからも続いており、当初は13日に解除される予定でしたが緊急事態宣言により連休明けの5月7日解除予定となりました。登校したのは最小限の事務的な処理を行う目的だけで、先月は通知表や荷物を片付けるために一度、今月も新クラスの発表・教科書と課題の配布・連絡事項の伝達に一度だけでした。その後、居住地確認のため後日教職員が自宅を訪れること、児童の様子を聞くため電話をかけてくるとメールでの連絡が10日にありました。

幼稚園に関しても似たようなもので、休講要請が出てから現時点まで2〜3回程度の登園でした。こちらはいつになったら休園が解除されるのか、今のところは分かりません。

子供二人が家の中にいる状況なので、かなり騒がしいです。後述の理由によりリモートワークは行っていませんが、リモートワークを行うにはかなり厳しい環境です。また、子供達の学習や運動について神経を使う必要もあります。この点は妻が頑張っていて、YouTubeによる体操系の動画を観たり、以前オークション等で入手していた教材を使用して対応しています。TV等の動画類は基本的にダラ見させないことを方針としており、それはこの状況でも維持できているようです（これについては妻に感謝です）。

震災直後にはトイレットペーパーの買い占めが随分とあり、今回も買い占めにより入手な困難になる事態が発生しました。むしろ今回の方が買い占めの範囲が広く、品薄の期間も長いと感じています。3月下旬頃から、マスク、トイレットペーパー、ティッシュペーパー、米（レトルトご飯も含む）、カップラーメン、スパゲティ類（ソースも含む）辺りの入手が困難なことがありました。現時点ではマスク以外の品物は入手できるようになっていますが、スーパーマーケットによっては一人当たりの購入数に制限がかかっていることもあり、油断はできません。

昨年12月より勤務地が変わり、主たる通勤手段を自転車から自動車に変えていますが、行動が制限されている割には交通量が減ったという実感はありません。今はプログラマーではなく医療系の仕事をしているため、緊急事態宣言が出ても普通に職場へ赴き仕事をする…特に何かが変わったということもありません。

あまりSARS-CoV-2/COVID-19に絡んだ話は書かないようにしていたのですが、緊急事態宣言が出ていること、その状況でどんな生活をしているかはやはり残しておいた方が良いだろうと考え、少し書いてみることにしました。生活を淡々と書くのは難しいですね…読み返してみても何らかのバイアスが入ってしまうように見えます。

続きは気が向いたときに。書かないで放ったままになるかもしれません。事態が収束して書く必要が無くなれば良いのでしょうが、流石にその可能性は低いでしょう。56.90kg(22:00)

MMDVMHostはステータス表示用にNextion等のLCDパネルを使うだけでなく、LCDprocを使用することが可能です。MMDVM.iniの[General]セクションにあるDisplay=LCDprocを設定し、[LCDproc]セクションのAddress, Port（これはデフォルトの13666で良いはず）を設定すれば良いのですが…LCDprocの使い方で悩んだのでそちらのメモ。

LCDproc自体はLCDdとlcdprocの二つに分かれており、MMDVMHostのステータスを表示させるだけならLCDdが動いていれば良いです。apt-get install lcdprocでインストールした後、/usr/sbin/LCDdで起動するのですが…その前に、cme edit lcdprocで/etc/LCDd.confを作成する必要があります。設定が必要な項目は二つ。lcdproc/serverの、Driverにcursesを設定することと、Bindにlocalhostを設定すること。今回はOpenBSDマシンから仮想マシンのDebian上で動くLCDdにコマンドを投げるためBindを変更する必要があったのですが、通常はデフォルトの127.0.0.1のままにしておきます。

とりあえず動かすだけならこれで十分なのですが、エミュレーションされるLCDパネルの色やサイズを変えたくなったらlcdproc/cursesを適宜設定してください。デフォルトでは赤地に濃青の文字で、20文字×4行で表示されます。

…で。

LCDprocがIPv6対応していたらMMDVMHostもということでLCDprocを試していたのですが、なんかgithubのコード見ても、issue見ても、LCDproc側がIPv6未対応に見えます。

IPv6対応なコードにしちゃったけど…58.85kg(20:30)