into the void

ソフトウェアに関する雑多な調査日記

MP3のタグ情報(ID3v2)をコマンドラインで編集するツール

mp3ファイルのメタ位情報をコマンドラインで、閲覧、編集できるツールを作ってみた。
大量のmp3ファイルを一括処理したいときに、シェルスクリプトと組み合わせて使うと便利だと思う。
まだ作りかけで、ID3v2.2タグの一部のみに対応。
テストも不十分なので、使うときはオリジナルのファイルはバックアップしておいてください。

Releases · kizitorashiro/mp3meta_java · GitHub

修正

バグっていたので修正。あとv2.3のタグもreadはできるように機能追加。
Release 2nd experimental release · kizitorashiro/mp3meta_java · GitHub

Raspberry Pi 3 のUSBポートはデバイスモードでは使えない。ホストモード専用。

Raspberry Pi 3をUSBガジェット的に使えないかなと思ってUSBについて調べてみた。

Raspberry Pi 3のUSBポートは

  • USB マイクロ端子
  • USB A端子 (標準)

が用意されている。

USBマイクロの方につなぐと、デバイスとして認識されるのかもと思っていたが、どうやら給電専用らしい。確かに回路図をみると、データの線が繋がっていない…
https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/RPI-3B-V1_2-SCHEMATIC-REDUCED.pdf

USB-Aの方は、USB OTG のホストモードで動作するらしい。

USB OTGは同じ端子を使ってUSBのホストとしてもデバイスとしても動作できる規格。最近スマフォやタブレットでこの端子が付いていることが多い。
ホストとして動作するか、デバイスとして動作するかは、端子についてID線の状態で判定するとのこと。
通常のUSBケーブルが繋がれた場合、ID線はOPENになっているので、デバイスモードして動く。
USBホストケーブルなるOTG用のケーブルが繋がれた場合、ID線がGNDに短絡されているので、それを検知してホストモードで動く。
ID線があるのは、USB-miniとUSB-micro。

例えば、キーボードをタブレットにつなぎたい場合、キーボードの端子はUSB-Aなので、これをスマフォが持つUSB-microに変換しつつ、ID線が短絡されているアダプタを買ってきて接続することになる。

USB端子については下記のページがわかりやすかった。
http://ktsite.ddo.jp/kikaku/usb/index.html?PHPSESSID=aebaedf74eee0cfadb4e9fb393447fb4

Raspberry Piの基板についている端子はUSB-A端子。これがBroadcomのSoCにHub経由で繋がっていると思われる。
実際に、lsusb -tでみるとこのようになっていた。

[pi@raspberrypi:~ $ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M

ハブがあって、そこにsmsc95xxが繋がっているようだ。これがUSB-LANのチップになっている。

ハブとSoCの結線がおそらく、SoC側のID線を短絡する形でされ、常にUSBホストとして動作する回路になっていると思われる。Pi 3のSoCと周辺機器の接続がわかる回路図が公開されていないのではっきりとは分からないが、少なくとも Pi 1の回路図ではUSB IDの線がGNDに接続されていた。

なので、
Raspberry Pi をUSB Gadget的に使ってみたいと思ったのだけど、無理だということがわかった。残念。

USB探偵団の簡単USBシリアル変換器がMacで認識されないで困った

LinuxカーネルのUSBドライバ周りのアーキテクチャを把握しておきたいなと思って、ソースを読んでみたんだけど、そもそもUSBの仕様を知らなさすぎて、よく分からない…

インターフェースのバックナンバーに良さげな特集があったので、必要な部品を集めて、勉強用の基板を組み立ててみた。


PICを使った二つの基板を組み立てるのだけど、USBシリアル変換基板の方が、PCに接続しても認識されない。

回路図を見直しても間違いはなさそう。PICに書き込むプログラムのソースを見てみたけど、そもそもこれからUSBを学ぼうと思っている者に分かるはずがない。データシートを参考に初期化時のレジスタの設定順を変えてみたけれどダメ。

もしかして、うちのPCがMacだからか?と疑って、会社のWindows PCに試しに繋いでみるとサクッと認識された…。

Macとの相性が悪いってことだと思うけど、電気的なものか、USBのプロトコル的なものかは不明。分かっていることは、対処法が不明であることだけ。

仕方がないので、完成品のUSBシリアル変換基板を買った。

いつかは自作基板がMacで認識されるように、回路かソースをなおしたい。


Raspberry Pi 3 の Kernelをビルド

Raspberry Pi 3でローカルビルド

Kernelのもっとも簡単なビルド方法はRaspberry Piの環境でのmake。
時間はかかるが、手順通りにやれば確実にビルドできる。
所要時間は85分。

Kernel Building - Raspberry Pi Documentation

sudo apt-get install bc
git clone --depth=1 https://github.com/raspberrypi/linux 

KERNEL=kernel7
make bcm2709_defconfig
time make -j4 zImage modules dtbs
  ...
  ...
  IHEX2FW firmware/keyspan_pda/xircom_pgs.fw

real	85m25.273s
user	230m6.130s
sys	10m58.340s

Ubuntuでのクロスビルド

Ubuntuでのビルドも簡単。ツールチェインを入れる手間があるだけで、手順通りにやればできる。
さくらVPSの環境でビルドしてみた。およそ20分で完了。

sudo apt-get install build-essentials
sudo apt-get install git
sudo apt-get install bc

git clone https://github.com/raspberrypi/tools

git clone --depth=1 https://github.com/raspberrypi/linux 

KERNEL=kernel7
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- bcm2709_defconfig
time make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage modules dibs

...

real	19m40.302s
user	34m15.342s
sys	4m39.830s

Mac OS X EI Capitanでのクロスビルド

MacでPS4のリモートプレイ

試してみた。
PS4リモートプレイ Windows® PC / Mac

Destinyをプレイしてみたけど、画像が乱れたり、コントローラの操作の遅延が大きかったり、最終的には切断されたりで、いまいち使えませんでした。
ネットワークの問題かなと思ったけど、アクティビティモニタで表示されるスループットは5Mbps程度。うちのWiFi環境でも10Mbpsは余裕で出るはずなので、ここがボトルネックなわけではなさそう。

よくよくSONYのページをみると、CPUの推奨スペックがCore i5 の2.4GHz以上とある。うちのMacBook Airは1.7GHzしかないので、ここのスペック不足っぽい。CPU使用率的には振り切れているわけではないんだけど、デコード処理が遅いのかな。

MacからPS4にpingを打ってみると、レスポンスタイムのばらつきが大きい。これが原因かも。WiFiだとしかたないかな。

$ ping 192.168.0.14
PING 192.168.0.14 (192.168.0.14): 56 data bytes
64 bytes from 192.168.0.14: icmp_seq=0 ttl=64 time=11.757 ms
64 bytes from 192.168.0.14: icmp_seq=1 ttl=64 time=304.342 ms
64 bytes from 192.168.0.14: icmp_seq=2 ttl=64 time=20.408 ms
64 bytes from 192.168.0.14: icmp_seq=3 ttl=64 time=32.174 ms
64 bytes from 192.168.0.14: icmp_seq=4 ttl=64 time=93.335 ms
64 bytes from 192.168.0.14: icmp_seq=5 ttl=64 time=2.335 ms
64 bytes from 192.168.0.14: icmp_seq=6 ttl=64 time=12.876 ms
64 bytes from 192.168.0.14: icmp_seq=7 ttl=64 time=4.050 ms
64 bytes from 192.168.0.14: icmp_seq=8 ttl=64 time=7.066 ms
64 bytes from 192.168.0.14: icmp_seq=9 ttl=64 time=64.049 ms
64 bytes from 192.168.0.14: icmp_seq=10 ttl=64 time=3.796 ms
64 bytes from 192.168.0.14: icmp_seq=11 ttl=64 time=29.522 ms
64 bytes from 192.168.0.14: icmp_seq=12 ttl=64 time=61.225 ms
64 bytes from 192.168.0.14: icmp_seq=13 ttl=64 time=7.752 ms
64 bytes from 192.168.0.14: icmp_seq=14 ttl=64 time=70.928 ms
64 bytes from 192.168.0.14: icmp_seq=15 ttl=64 time=27.266 ms
64 bytes from 192.168.0.14: icmp_seq=16 ttl=64 time=273.481 ms
64 bytes from 192.168.0.14: icmp_seq=17 ttl=64 time=7.161 ms
64 bytes from 192.168.0.14: icmp_seq=18 ttl=64 time=198.923 ms
64 bytes from 192.168.0.14: icmp_seq=19 ttl=64 time=13.567 ms
64 bytes from 192.168.0.14: icmp_seq=20 ttl=64 time=116.529 ms
64 bytes from 192.168.0.14: icmp_seq=21 ttl=64 time=55.151 ms
64 bytes from 192.168.0.14: icmp_seq=22 ttl=64 time=73.552 ms
64 bytes from 192.168.0.14: icmp_seq=23 ttl=64 time=12.972 ms
64 bytes from 192.168.0.14: icmp_seq=24 ttl=64 time=20.984 ms
64 bytes from 192.168.0.14: icmp_seq=25 ttl=64 time=457.897 ms
64 bytes from 192.168.0.14: icmp_seq=26 ttl=64 time=63.360 ms
64 bytes from 192.168.0.14: icmp_seq=27 ttl=64 time=88.778 ms

さくらVPSにIPv6アドレスをつけてPCからアクセスしてみる

さくらVPSのサーバにIPv6アドレスをつけて、自宅のPC(Mac)からアクセスしてみる。
まずは自宅ルータにて、普段はオフにしているIPv6設定をオンにする。
Macのターミルでifconfig en0して、IPv6のグローバルアドレスが付いていることを確認する。
IPv6 Ready なサイトにSafariからアクセスすると、確かにIPv6でのインターネット通信ができるようになっていることがわかる。

IPv6 test - IPv6/4 connectivity and speed test
https://ipv6.google.com/?gws_rd=ssl

次にさくらVPSにインストールしたUbuntuIPv6アドレスを設定する。IPv6アドレスは、さくらのVPSコントロールパネルに表示されているものを使う。
IPv6アドレスの設定方法|さくらインターネット公式サポートサイト

設定したら一度再起動して、ifconfigやip -6 routeコマンドでIPv6のアドレスが付いていることと、ルーティング設定がされていることを確認する。

次に、MacのターミナルからIPv6アドレスを使ってサーバに接続してみる。
まずはping6で。次にsshで。
sshは特にIPv6であることを指定しなくても、パラメータとして渡すアドレスをIPv4からIPv6に変えるだけで繋がる。

サーバ側でnetstatをみて、Macから22番ポートにTCP6での接続があることが確認できる。

$ netstat -an | grep tcp6
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 XXXX:XXXX:XXXX:XXXX:XXXX:22 XXXX:XXXX:XXXX:XXXX:XXXX ESTABLISHED

サーバ側にWebサーバを入れてアクセスしてみる。Webサーバはlighttpdを使うことにした。
apt-get install lighttpdでインストールした後、lighttpd.confを編集してIPv6でのリスンができるようにする。ついでに、アクセスログもとれるように変更しておく。

こんな感じ。
追加したのは、server.modulesのところのmode_accesslogと、accesslog.filenameとinclude_shellのipv6の項目のコメントアウトを削除した3点。

# cat /etc/lighttpd/lighttpd.conf 
server.modules = (
	"mod_access",
	"mod_alias",
	"mod_compress",
 	"mod_redirect",
#       "mod_rewrite",
	"mod_accesslog"
)

server.document-root        = "/var/www"
server.upload-dirs          = ( "/var/cache/lighttpd/uploads" )
server.errorlog             = "/var/log/lighttpd/error.log"
server.pid-file             = "/var/run/lighttpd.pid"
server.username             = "www-data"
server.groupname            = "www-data"
server.port                 = 80

accesslog.filename	= "/var/log/lighttpd/access.log"



index-file.names            = ( "index.php", "index.html", "index.lighttpd.html" )
url.access-deny             = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

compress.cache-dir          = "/var/cache/lighttpd/compress/"
compress.filetype           = ( "application/javascript", "text/css", "text/html", "text/plain" )

# default listening port for IPv6 falls back to the IPv4 port
## Use ipv6 if available
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"

今度はサーバからMacにping6を打ってみる。ルータでフィルタされているようで届かない。
ルータの設定を変更して、サーバのIPv6アドレスからの通信を許可してみると、届くようになった。