プログラムでの文字へのデコードを試す前に、サンプリングレートが 8kHz、 量子化ビット数が 8bit の unsigned な wave ファイルという制約を なんとか取り払えないか試してみます。
まず、サンプリングレートは簡単で、変数に入っている数値を変更するだけで 問題なさそうです。が、window_size も同じ比率で変更してあげないと、 出力に差が出てくるようです。 同じ比率を保つために、window_size はサンプリングレートの250分の1に して、出力が変化しないようにします。
ちなみに、サンプリングレートは wave モジュールで取得できるようです。 わざわざ変更するのも面倒なので、取得するようにしましょう。
また、unsigned を仮定しているのは、フレームの値から 128 を引いている 部分のようです。(量子化ビット数も関係ありますが。)
量子化ビット数を変更できるようにするには、今のフレーム(バイナリ)の 0番目の値のみを見ている所を変更する必要がありそうです。 Python のBuilt-in Types の、 int.from_bytes を 使えばよさそうです。 unsigned の制約も外すために、128 を引いている部分もビット数から計算して 引くように変更します。unsigned 8bit のときに -128 なのは、u8 が [0, 255] で、 その半分を引いて [-128, 127] にするためですね。同様に、unsigned 16bit であれば -(2^15) してあげればいいですね。signed であれば何も引きません。一般化すると、 n bit のとき、signed であれば -0、unsigned であれば -(2^(n-1)) ということに なります。
あとは愚直に実装して、ny-a/RTTY - GitHub に push すれば完了です。
GitHub のプロファイルをカスタマイズできることは知っていましたが、 ユーザー名と同じ名前を付けたリポジトリの README.md が表示されていると いうことを知ったので、試してみました。
まだカスタマイズは試していませんが、とりあえず表示できるところまで 完了しました。
今日は GitHub Actions の Failed の通知が来ていたのでログを確認した所、 GitHub のコンテナレジストリが 503 エラーを吐いていたようでした。 GitHub のコンテナレジストリなんてあるんですね。初めて知りました。
Arch LinuxのCode-OSSの拡張機能の検索先を変更する に書いてある通りなんですが、Arch Linux の code パッケージは OSS のもので、拡張機能のギャラリーは Open VSX Registry を使用しているようです。
Visual Studio Marketplace で検索した拡張機能が インストールできないと悩んでいたのですが、これが原因だったんですね。
調べてみた限りだと、ユーザーの設定ではギャラリーを変更できないようだったので、 一番始めのリンクの記事に書いてある通りに /usr/lib/code/product.json を書き換えると Visual Studio Marketplace から検索することができるようです。
これって複数指定できないんですかね？あまり VSCode の拡張機能のレジストリについては 詳しくないですが……。
Idein/rpi-vcsm の issue #2 で vcsm-cma に対応していただけるとのことだったのですが、今日 GitHub から通知が来て、 なんともう対応していただけたようです。すごく早い……ありがたいですね。
早速最新のカーネルで試してみましょう。5.10.17-v7+ で試しました。
先に rpi-vcsm をインストールします。書いてある通りです。インストールできたら py-videocore の example を試してみましょう。
py-videocore の方にも PR が出されているので、フォークされたブランチ を clone してきます。あとは書いてある通りに試していくと……エラーが出ますね。
ImportError: libf77blas.so.3: cannot open shared object file: No such file or directory
numpy のインストール時の常識でしょうか……。sudo apt-get install libatlas-base-dev しましょう。
$ python3 examples/sgemm.py ==== sgemm example (96x363 times 363x3072) ==== threads: 12 numpy: 0.4205 sec, 0.5113 Gflops GPU: 0.0294 sec, 7.3126 Gflops minimum absolute error: 0.0000e+00 maximum absolute error: 9....
ArchWiki の編集で割とつらいのが、編集が textarea で行う必要があることです。 普段はあまり気にならないですが、サイズの大きいページを編集する際などは レスポンスの悪さが気になることもあります。
これが、テキストファイルをテキストエディタで編集するようにできたら 色々な問題が解決しそうです。また、revision の仕組みなどを考えると、 git などでバージョン管理をしてあげると嬉しいかもしれません。
そこで、「git mediawiki」などで検索してみると、やりたいことズバリの Git-Mediawiki という プロジェクトを発見しました。
git は perl に依存しているので驚くことでもありませんが、Git-Mediawiki も perl で書かれていて、perl の依存のインストールが必要です。 私は、各言語の依存パッケージでマシンの環境を汚したくないので、このような 場合には Docker イメージに閉じ込めてしまう場合が多いです。 いつも通り archlinux/archlinux ベースイメージから、git と各依存パッケージを インストールしてイメージを作成しました。
さて、早速 ArchWiki 日本語版を pull していきたいところですが、実際に やってみると途中で落ちます。author の特殊文字のエスケープが抜けていますね……。
あと、今まで気付いていなかったのですが、このプロジェクトは git-core に 取り込まれているようです。知名度はそんなに高くない気がしますが、 git コミッタの周りでの使用者が多いんでしょうか……。
とにかく、この場合パッチを送るのは git-core の方になりそうなので、 git の コントリビューションの方法 を調べるところから始めないと いけないですね。
設定項目としては、標準では標準名前空間のみ対象としているため、ArchWiki の 全ての名前空間を対象にするには、
git config remote.origin.namespaces "(Main) Talk User User_talk ArchWiki ArchWiki・トーク File File_talk MediaWiki MediaWiki_talk Template Template_talk Help Help_talk Category Category_talk"...
前回生成した csv から、文字へのデコードを試してみます。(2回目)
なんか調べてみると、ストップビットは1, 1.5, 2ビットのパターン？が あるようでした。 サンプルのファイルには1.5ビットって書いてあったような気がしたのですが……。
まあ、気を取り直して、0→1または1→0に変化する箇所を抽出して、 6ビット以内はデータと考えて無視すると、綺麗に7ビットごとに 並んでいるようでした。ストップビットは1ビットだったようです。
あとはプログラムを書いて、データ部5ビットごとに区切って出力すれば、 文字へデコードするのはかなり簡単になりそうですね。
GPU で何を計算するかのアイデアを探していたのですが、 よく考えたら FFT も GPU 上で計算できそうだと思って 少し調べてみました。
すると、2次元 FFT の話題が多いようでした。 2次元の周波数成分といえば、JPEG の圧縮に使われている やつですね……(あれは DCT ですが)。
数は比較的少なそうですが、FFT の並列計算に関する話題もありました。 GPU を用いた高スループット計算システムの実装 など。
実際に実装に進んで……といきたいところですが、まずは FFT を CPU で計算してみて (numpy にもあったはず)、 それを使うコードを書くのが先ですかね……。
……とここまで書いておいてあれですが、PyVideoCore の 作者の方の Qiita 記事 に
他の人が書いたFFT(公式サンプルとしてraspbianに収録)
……既にあるみたいですねw
GPU_FFT
これとかでしょうか。 バタフライ演算の図なんかもあり、FFT の知識がなくても これを読むだけで勉強になりそうです！(？)
前回生成した csv から、文字へのデコードを試してみます。
ゆくゆくはプログラム書いてデコードしたいですが、一旦コードの 仕様確認なども兼ねて csv 上で挑戦します。
まず、0/1の2値化された値は、かなり安定しているようです。 RTTYでは一般的に 45.45Baud を使用するようなので、 8kHz だと 45.45 で割ると 176 フレームごとに1ビットという感じでしょうか。 また、一般的に使われている文字コードは Baudot code で、5bit で表現されて いて、各文字にスタートビットとストップビットがそれぞれ1, 1.5ビットの長さで 付加されているようです。
とりあえず、だいたい176回同じ値が連続するごとに区切ってみると、定期的に 中途半端な部分が出てきそうです。 試してみると……、めちゃめちゃ綺麗にアライメントされていて、半端なビットは なさそうでした。
早速困ってしまいましたが、今回のサンプルは幸い値が詳しくコメントされています。 ほぼ反則ですが、一度文字の方からバイナリ列に当てはめて考えてみようかなと 悩んでいます。
いや、それよりも FFT する方法で、諸々のパラメータが分からない場合にでも 使用できるデコーダを書くのを先に進めた方がいいかもしれません。
まあ、何か重大なことを見落としているなんてこともしょっちゅうなので、 諦めずに挑戦してみるのも大事かもしれません。
AUR の uim パッケージに、ビルドが失敗するという コメントをいただきました。
しかし、手元の Docker 環境でビルドしてみたところ、正常にビルドを完了することができました。
ビルドエラーは csi というコマンドで発生しているようで、手元のビルド環境にはこの実行ファイルは 存在していませんでした。 Makefile.in ファイルを確認した所、ビルド時に csi 実行ファイルが存在していればそのコマンドが 実行されるようになっていました。
Arch のパッケージで /usr/bin/csi が含まれているものを探してみると、
$ pacman -Fy $ pacman -F /usr/bin/csi usr/bin/csi is owned by extra/mono 6.12.0.107-1 どうやら mono に含まれているようでした。 error CS2006: Command-line syntax error: Missing '<text>' for '-R' option というエラーも、 検索してみた限りでは mono のエラーと考えてよさそうです。
ただ、uim は mono に依存していないようなので、この csi は mono に含まれているバイナリを 期待しているわけではなさそうです。GitHub の issue を探してみると、#26 で csi について言及されていました。 これによると、Chicken Scheme のインタプリタが csi という名前のようです。...
Chromium を Docker コンテナ内で安定して動かすことができるようになったので 方法をメモしておきます。
ny-a/chrome-in-docker
上記リポジトリで docker-compose up --build すれば済むのですが、解説します。
SYS_ADMIN は chrome が namespace の操作権限を必要とするので付けています。 --no-sandbox オプションをつけて chrome を起動することでも対処はできますが、非推奨です。 どちらもないと、Failed to move to new namespace というエラーが出ます。 (sysctl から設定を変更することでも可能なようですが、Arch標準のカーネルの設定で起動することを考えています。) 参考: jessfraz/dockerfiles #350
network_mode: host は、ホストの X11 サーバーに直接ウィンドウを表示するために必要です。
devices: /dev/snd があると音が出ます。環境によっては ALSA の設定なんかを Docker 内から 見えるようにする必要があるかもしれません。
${XAUTHORITY}:/home/user/.Xauthority ボリュームは、X11 の認証に必要です。
DISPLAY 環境変数は、X11 サーバーが複数立ち上がっているときに区別するために必要です。 まあほとんどの環境で :0 にしておけば問題ないはずです。
docker-compose を使いたくなければ、
docker build . -t chrome docker run --rm -te DISPLAY=$DISPLAY --net host -v ~/....