a-ads.comの成果
最近、なかなかやる気が出なくて全然記事を書いてませんでした。
3箇所に貼り付けているa-ads.comの成果ですが、トータルで0.00083950Ƀの入金がありました。
50円ぐらいですね。まあ、ないよりはましですね。
JACKで自動的に接続するツールをGo言語で作ってみた
JACKは色々なことができて便利なのですが、PulseAudioと比べると準備に色々と手間がかかって面倒なことがあります。
面倒なことをできるだけ減らしたいので、まずは新たなポートが見つかるとjack_mixerへ自動的に接続してくれるツールを作ってみました。
audio-tools/main.go at master · ohac/audio-tools · GitHub
まだ、マッチングの処理が賢くないので、改善していく必要がありますが、とりあえずはメトロノームのjack_metro --bpm 90を立ち上げると自動でjack_mixer:metro(モノラルチャンネル)につながるところまではできました。
WindowsでJACKを使っている人はあまりいないと思いますが、これはLinuxでしか動作確認していません。
ハマったところはコールバック内でconnectはできないことと、chanがうまく使えなかったところです。 とりあえず1秒間隔のポーリングにしていますが、シングルタスク用のキューみたいなやつに置き換えたいです。
guvcviewが動かなくなったのでffmpegでキャプチャする方法を調べてみた
先日、guvcviewで動画が取れることが分かったので、定期的にギターの練習動画を取ってみて、モチベーションを上げようと思っていた。
これがそのときの動画。
PCに付属しているWebcamでは角度の調節が難しかったので、LogicoolのC270というやつを購入した。 また、Ubuntuが15.04のままでセキュリティ的にまずい状態だったので、15.10に上げてみた。
その後、気がつくとguvcviewでキャプチャできなくなってしまった。
cheeseではちゃんとキャプチャできたので、guvcview側の問題っぽいけど、よく分からなかった。
cheeseはJACKに対応していないので、PulseAudioかALSAを使わなければならず、あまりカスタマイズもできなさそうだったので、他の方法を模索していたところ、ffmpegコマンドでキャプチャできるということが分かった。
ここからffmpegのオプションと格闘することになるのだが、結果から言うと以下のオプションでうまくキャプチャすることができた。
ffmpeg -f video4linux2 -s 640x480 -i /dev/video1 -f jack -i ffmpeg -acodec pcm_f32le -vcodec yuv4 -y test.avi
JACK側から見るとffmpegというデバイスが見えるので、そこに向かって録音したい音をつなげてやればよい。 acodecとvcodecで圧縮させるとCPUパワーを使うため、このPCでは処理落ちなどが発生し、あまり使いものにならなかった。
acodecはJACK側がf32leだったため、それに合わせてみた。コンテナは.aviにしたが、他にもよいものがあるのかもしれない。
acodecがlibvorbis、vcodecがmjpegまたはmpeg1videoならほとんど処理落ちしなかったが、どうせ後で変換するのだし、ストレージは割と余っているので、上記オプションとなった。
最後に ffmpeg -i test.avi test.webm とかで小さくして、保存するなりアップロードするなりすればよさそう。
ALSA/PulseAudio/JACKのメモ
しばらく触っていないとすっかり忘れてしまうのがオーディオ周りのALSA, PulseAudio, JACKの設定など。
まず最初に ~/.config/pulse/client.conf に autospawn = no を書き、PulseAudioの自動起動を無効にする。 (この設定はログインしなおす必要があったと思う。killでもいけたかも。)
追記: pulseaudio -k で kill できる。
次にALSAのデフォルトを無音のループバックにして、デバイスをALSAに占有されないようにする。
デバイス一覧は aplay -l で表示できる。 alsamixergui -c 1 のようにカード番号を指定してミキサーを表示する。
/usr/share/sounds あたりに .ogg ファイルがあるので、これでいろいろテストできる。 特にCD品質な desktop-login.ogg が扱いやすい。これを sox で.wav に変換する。
$ sox /usr/share/sounds/ubuntu/stereo/desktop-login.ogg /tmp/desktop-login.wav
なお、CD品質に変換するには -b 16 -c 2 と rate 44100 を指定すればよい。
$ sox bell.ogg -b 16 -c 2 /tmp/bell.wav rate 44100
まずは hw を直接指定して aplay で音を確認する。事前にでかい音が出ないように alsamixergui で調整しておく。
$ aplay -D hw:1,0 /tmp/desktop-login.wav
次にこのデバイスに ~/.asoundrc で名前を付ける。とりあえず内蔵カードなので pc という名前にしておく。
pcm.pc {
type hw
card 1
}
動作確認。ログインしなおしたりする必要はない。
$ aplay -D pc /tmp/desktop-login.wav
あとは !default をループバックデバイスにする。rateやipc_keyは状況に応じて変更する。 詳しくは覚えていないが、今は以下のようになっている。
pcm.!default { type plug slave { pcm "ploop" #rate 44100 #rate 8000 } } pcm.cloop { type dsnoop ipc_key 18485 slave.pcm "hw:Loopback,1,0" } pcm.ploop { type dmix ipc_key 18486 slave.pcm "hw:Loopback,0,0" }
JACKとの連携用の設定もしておく。これもあまり覚えていないが、以下のようになっていた。
pcm.jdefault { type plug slave { pcm "jack" #rate 44100 #rate 8000 } } pcm.alsajack { type jack playback_ports { #0 system:playback_1 #1 system:playback_2 0 "jack_mixer:alsa L" 1 "jack_mixer:alsa R" } #capture_ports { #0 system:capture_1 #1 system:capture_2 #} } pcm.jack { type plug slave { pcm "alsajack" } }
JACKからこのループバックデバイスが見えたら、JACKに対応していないアプリ、例えばChromeなどからの入力を扱うことが可能となる。
参考にしたサイト
Go言語でBitcoinの署名を検証してみた(その1)
最近はGo言語のトレーニングをしていますが、慣れていないので結構大変です。 早くいろいろと記憶して楽になりたいです。
ところでgocoinというソフトがあり、その中にsecp256k1というライブラリがあったので、これを使ってBitcoinの署名を検証してみました。
GitHub - piotrnar/gocoin: Full bitcoin solution written in Go (golang)
gocoin自体は非商用利用可のライセンスのようですが、secp256k1はMITライセンスとなっておりました。 gocoinのbtcというのを使えば簡単ではあるのですが、MITライセンスの方がよいので、とりあえずsecp256k1だけを使ってみました。
今のところ、このコードでは公開鍵のhex列がないと検証できませんが、一応動いております。 署名の形式もチェックしていないので、古いクライアントで署名したものだとうまくいかないかもしれません。 ちなみにこのテスト署名はElectrumを使って署名したものです。
Bitcoinアドレスは公開鍵そのものではなく、公開鍵のハッシュ値なんですね。 だからこんなに短くできるのかと納得しました。
Bitcoinアドレスで検証するためにはどうやら署名から公開鍵に戻して、そのハッシュと比較するようです。 今回は疲れたので、このへんでやめときます。
暗号通貨を使ったプロトコルを考えてみる
ここ何日か暗号通貨を使ったサービスを考えていたが、結局のところどのようなサービスでも共通している部分はプロトコルにしてしまった方がよいのではないかと考えるようになった。
なんとなく考えているイメージは以下のようなもの。
- 基軸となる暗号通貨を決める(Bitcoin, Altcoinなど)
- メッセージングのプラットフォームを決める(メール、Web、専用アプリなど)
- 複数サポートもあり
- メッセージングのデータフォーマットを決める(JSON, MessagePackなど)
- 受付用のウォレットアドレスを決める
- 公共・分散的なものの場合はスパム防止の意味でProof of Burnを選択
これらのパラメータは各々のサービス提供者が決めればよい。
あとはサービス提供者が受け取ったメッセージをどのように扱うかというところ。
サービス利用者は専用のウォレットアドレスを1つ決め、メッセージに対して署名し、サービス提供者に渡す。通信経路が暗号化されていない場合はオプションで暗号化してもよい。
場合によっては利用者に対して返信する必要があるので、そのようなメッセージングプラットフォームを選択するか、もしくはウォレットアドレスで暗号化してWebなどでブロードキャストしてもよい。
サービス提供者は受け取ったメッセージを検証し、問題なければメッセージに書かれている要求内容を確認し、入金などの条件を満たしておればそれを実行するといった感じ。
例えば以下のようなサービスが考えられる。
- ストレージの提供
- 計算資源の提供
- 翻訳
- 広告
現状ではこれらをまとめて簡単に構築できるようなフレームワークがないと思うので、いつか作ってみたいと考えている。
ブロックチェイン上でKVS(Key-Valueストア)が使えるBlockstoreを調べてみた
Qiitaの記事で言及のあったBlockstoreというやつを調べてみました。(試してはいません。)
これはどうやらストレージ自体はブロックチェインに置かずに別のDHT(分散ハッシュテーブル)に置くようです。 ブロックチェインはBitcoinを使っており、おそらくハッシュ値だけを記録しているものと思われます。
ドキュメントを読んだ感じではNamecoinをかなり参考にしてそうな感じで、名前(name)の登録手順は似ていました。 Namecoinは独自のブロックチェイン上にデータを置いていましたが、BlockstoreはDHTに置くという違いがあります。
名前空間(namespace)の登録もできるようですが、0.4BTC以上と結構お高いので、普通は最初から用意されている .id という名前空間を使うことになりそうです。 例えば ohac.id みたいな感じでしょうか。名前空間上には名前空間の保有者でなくても名前を登録することができるようです。
名前は長さや記号の有無などでコストが変わるようで、長い文字列なら250uBTCで済むようです。 これらのコストは下記のProof of Burnのアドレスに送られるようです。
https://blockchain.info/address/1111111111111111111114oLvT2
1つの名前にはJSON形式でデータが保存でき、サイズの上限は8KBとなっているようです。
問題はDHTノード群をどのように維持していくのかといったところかと思います。
FAQを見たところ、現状ではノードを走らせるためのインセンティブがないようです。
Sybil attackも可能なようなので、DHT上にはいくつか冗長保存されるとしても少し安心感に欠けるように思います。
追記: Sybil attackについてはhttps://en.wikipedia.org/wiki/Kademlia#Next_generationに言及あり。
どの程度冗長保存されるのかまだ調べておりませんが、DHTノードだけを独立で走らせることができないのであれば各ノードはBitcoinの数十GBとDHTの両方を保存するためのストレージが必要となり、なかなかお気軽にノードを立ててみようとは思えないです。
追記: https://en.wikipedia.org/wiki/Kademlia#Locating_resources に少し書いてありました。具体的な数値はパラメータによるのかも。
このあたりがもうちょっと改善されればよさそうですね。