りんけーじ - 日記 - 2007年2月の日記

別にアーキテクチャが消えてなくなったわけじゃないですよ？

ついにうちに Intel Mac が来ました。MacBook の下から 2 番目のモデルです。初めての Dual なマシンでもあります。うちの中ではかなりイカれたスペックなので、無論今後の Mac メインマシンとなるでしょう。

開発関係の話はまた後日ってことで、とりあえずこれからはメインマシンからいなくなっちゃうであろう、PowerPC に軽くお別れの挨拶を。

PowerPC とはそこそこ長いつきあいですが、今でも、MIPS と並んで一番好きなアーキテクチャ、命令セットの 1 つです。複雑なアドレッシングがなく、命令も（AltiVec とかはともかく）とてもシンプルで好きでした。

まだまだ PowerPC は組み込みとかで元気なようなので、そのうちまたディープに関われる日が来ると思います。というか、まだ wisp で使いますが。

とりあえず、今までありがとう。……これ以上シェア減らないでね？

100円が塵とはいいませんが。

いいって言ってるのに毎度食費と称して 100 円を置いていってくれる心優しいヒトがいまして、それがいっぱい貯まりました。

ちょうど貯金箱もジャムの空き瓶もなかったので、冷凍してたんですよ。使っちゃダメって意味も込めて冷凍。ちなみに 18 枚もありました。

んで、ちょっと久しぶりに近所のケーキ屋にいったら、やたらおいしそうなケーキが。今度この資金で買って待ち伏せしてやることにします。あぁ、こういうのってなんで楽しいんだろう…（笑

あと、今日も今日とて liveice のバグ取り。fork したプロセスが SIGSEGV でやたら落ちて syslog が大変なことに。fork したあとなもんだから、gdb で追えなくて大変。

デバッグできなくて腹が立ったので、pthread で置き換えてやりました。バグも潰れて満足。

あ、Direct X の勉強を始めました。さて、いつまで続くのでしょうか。

延々と調整を続けております。

とりあえず、liveice を改良して、Unicode な ID3v2 ヘッダを読めるように直して、UTF-8 で吐かせてみた。icecast 側は無事認識。iTunes はスルー。しかしたまたま、お隣の人が接続してみたらなぜか（文字化けしてるけど）曲名が出るという。さてこれはどういうことか。

延々と延々と tcpdump と ethereal を使ってパケットをキャプチャするものの、自分の環境との違いが出ない。そもそも私の環境でも、ほかのひとのストリームを聞いてて曲名がちゃんと出たことがある。そうすると、設定や iTunes のバージョンのせいではないことになる。

そしてさらに延々と調べた結果。tcpdump のフィルタに tcp port xxxxx と書いていたけど、実は UDP でストリームの情報が横流しされていたらしい。一歩前進。

さて、ここでさらに調べてみるとですね、インターネットオプションのプロキシ設定を完全に殺すと、なんと曲名が表示される。そのときサーバに送信されたヘッダはつきのとおり。

GET / HTTP/1.1
Accept: */*
Cache-Control: no-cache
User-Agent: iTunes/7.0.1 (Windows; N)
x-audiocast-udpport: 2955
icy-metadata: 1
Host: silky.white-void.net:xxxxx
Connection: Close

x-audiocast-udpport で、iTunes が UDP ポートを指定してますね。次はプロキシ設定はオン、ただし、プロキシを使用しないアドレスに silky.white-void.net がある場合。当然ですが、ちゃんと silky に直接接続されていました。

GET / HTTP/1.1
Accept: */*
Cache-Control: no-cache
User-Agent: iTunes/7.0.1 (Windows; N)
Connection: Close
Host: silky.white-void.net:xxxxx

見事ですね。きれいさっぱり、2 つほどヘッダが消え去ってくれてます。つまり、プロキシが設定されていると、プロキシを使用しないアドレスに入っていたとしても、曲名の更新情報を受け取れない、となります。

でも、そうするとこの前曲名が出たのはなんだったんだろう…？？

隣の皆月の人と一緒に、都内まで上のモノを買いに行ってきました。おいしそうです。もったいなくて食べられません（ぇ

当人は微妙に希望のブツが手に入らなくてご不満のようでしたが、おそらくあちらの日記で叫んでくれるでしょう。

先日の icecast な話はさくっとページにまとまりました。ソースを読んでみると、知らなかった機能がいっぱいでした。実はまだ README 読んでないんですがね〜

qmail とかもそうですが、Linux や Unix のプログラムは、単体の機能を小さくして、パイプなどの通信によって複数のプログラムを協調動作（っていうの？）して、大きな目標を達成しているものが本当に多く感じます。ソースコードなんかを読んでも、うわー、単純だなぁ、というものが本当に多いですし。

何のためらいもなくグローバル変数を使っているところとか、1つのタスクにつき1プロセスという考え方ならでは、と思います。こんなの構造化プログラミングで十分！

Mac は裏方は BSD なので、場合によっては実行ファイルを複数使うのもありかなー、とか。具体的に何に応用するの？っていわれると困りますが。

先に書いておきますが、プログラマ以外にはさっぱりな話です。苦手な人は読まないことを推奨します（笑

いい加減 iTunes の重さにぶち切れそうになったので、管理を iTunes、再生をほかのプレーヤでーとか悩んだ結果。CPU が暇してる silky に働いてもらうことにしました。

一応2つについて軽く。icecast はストリーミングのサーバプログラム。単体でも、mp3 ファイルなどをリクエストに応じて転送する機能は有する。liveice は、マイク入力やプレイリストで指定した mp3 ファイルを icecast サーバに送信するプログラム。プレイリストだけなら、icecast パッケージに入っている shout でも可能。

ちなみに iTunes はテキストファイルでプレイリストを出力できるので、出力されたデータを Perl に食わせて silky 上のファイルのパスに変換可能。smb でマウントするなりすればストレージの問題なんてっ。

さて、この icecast+shout/liveice を使って困ったこと＆解決案のメモ。

まず、shout だと VBR や、エンコードのビットレートがばらばらなファイルを食わせるとどうしても転送エラーが出て切断されてしまう。自動調整とかいろいろあるけど、どうにもうまく働いてくれてない模様。

liveice は、mpg123 を mp3 デコーダとして、lame などをエンコーダとして利用していて、元のファイルのビットレートなどを気にしないで使える。プレイリストなどの機能も持っているので、動いてるだけである程度の CPU 負荷がかかるということ以外は shout よりよい。まぁ、結構文句はあるんですが。

割と説明はほかのサイトさんでもやってるというか、んなもんサンプルの設定ファイル読めばわかるんで、ほかの事を。

まず、iTunes などでいじった mp3 ファイルの一部が実は読めない。これは mpg123 に問題があって、MPEG の開始ヘッダ？を最初の 64KB しか検索しない。ID3 タグがアートワークなどで膨れ上がった mp3 ファイルだと、ヘッダが見つからなくて fail になる。

FreeBSD ports にある mpg123-0.59r の場合、make してファイルをダウンロード、コンパイルが始まったところで停止させて、ファイルを編集する。common.c L215〜L225 あたりにあるのがヘッダ検索のロジックで、/* step in byte steps through next 64K */ とあるとおり、for ループで 65536 までループしている。とりあえず手元にあるファイルが再生できればいいやー、ということで、1024*1024 に変更。あとは make && make install で OK。

次は liveice のバグ。liveice.cfg には、次のようなことが書いてあります。

# update script can be executed at every track change...
# Not well documented - in fact not documented at all

1曲再生が開始される度に、指定したプログラムが実行されるという、なんとも素敵なモノなんですが、これ、動きません。

あとでまとめますが、meta_data.c の execute_update_script で printf みたいに引数の展開とかやってるんですが、1文字処理するごとに system をコールしちゃってて、/home/〜 とか指定すると、system("/")、system("/h")…と大量のエラーが出るわけです。

この system を一個外のループに追い出して、ついでに /* really should fork before this */ とか書いてあるので、#include <roken.h> を加えた上で、

if(fork() == 0) {
char *args[] = {0};
execve(exec_line, args, environ);
}

これでちゃんと動きます。引数の解析ができないのでちょっとアレですが、んなもんはシェルスクリプトに食わせればいいのです。というか、動かないよかマシ。

これで起動すればストリーミングサーバの完成。定期的にプレイリストのファイルを上記の UPDATE_SCRIPT で変えてやればおいしいかなーっと…思ったらプレイリストは読み直してくれなかった orz

以上、考えないで動いたら少し痛い目にあいました。しかしまぁ、最近はやっとオープンソースなプログラムの読み方というか、人のコードが理解できるようになったのでよかったかな、と。

さて、またまとめなきゃいけないモノが増えたぞーっ。

しばらく書かなかったら、随分書くことが溜まった。分けてもいいけど、面倒だからいいやー。

なんか昔に近所のスーパーの文句を垂れてそうな気がしたものの、書いてなかったので書いちゃおう。

うちの近所にはこの○○ーマートというスーパーが２軒あって、食べ物のうち生鮮食品はここに頼らざるを得ない状態です。一応薬局という名前のお菓子とお茶と生じゃないモノを扱ってる店はあるのですが、野菜とかお肉とかは置いてません。

んで、このスーパー。まったくもって使えません。世間では一般的なのか知りませんが、「価格に挑戦」とか常に貼りっぱなしで、でもそれが普通の状態だったり。スーパーのブランドのかまぼこが増量剤ばっかりでぼそぼそだったり。いやまぁ、ひどいもんです。競争がないとこーなるんでしょうか。

そしてつい最近、ハムが値上がりしました。前は 100g 〜円という方式でパックに値段が貼ってあったのが、値段がいきなり消滅。あれー？と思いつつ、買うとめっちゃ高い。泣けます。サラダが生産できません。

というわけで、直ちに改善を要求します。知り合いの知り合いの知り合いがこのスーパーの社長の息子と結婚したらしいので、そこから突付いてやります（ぁ

あ、パプリカが安いのだけは評価してあげます。これまで値上げしたら怒ります。

履歴書書いてます。志望動機とか言われても、変な会社だから興味がわいた、とかいうレベルなんで（実際変な会社だと思うし）、どう捏造してくれようかと。

ところで、履歴書のサンプルにある「特技：ねばり強いことです。」は特技なんでしょうか。てか、そんなんでいいのか！？

開発はまったくもって進んでおりません。自前の Objective-C ランタイムを FreeBSD で動かして遊んでたりはしますが。

S式のパーサを作らなきゃいけなさそうなものの、パースした結果をどう格納したらいいものか。配列にしろ辞書にしろ、なんらかのクラスを作らなきゃいけない。しかし、共同開発となると使うライブラリによってそのクラスが決まるわけで、そうすると…

以上は今年の頭に決めた「考える前に行動」に反するため、却下。よって、自前のライブラリを食わせるか、Objective-C に開発環境を移行させていただきます。gcc が直接食えるだけ、Pascal よかマシでしょ？＞研究室の先輩

ちょっと、勘弁してくださいヨ…。ちょうどビデオカードを注文したとこだったのにぃぃぃぃぃぃ。ほんのちょっと安いからってコンビニ支払いで先払いしたのが失敗だったか orz

実はちょっと前から chill が行方不明でして、まぁそのくらいじゃ凹みやしないんですが、さすがに２連発だとちょっと痛いです。ちゃんとこの２件の不幸の分の幸運は回ってくるんでしょうね！？（ぇ

貧弱な回線のクセにサークルのホームページのサーバにもなってたりするんですが、いい加減 ftp とかを開放してあげたいなーとか思うわけです。Web からファイルの管理ができるようにはしてあるものの、やっぱり面倒だし。はるか昔に WebDAV はぶった切ったので、使うとしたら smb か ftp かその辺かな、と。

ftp は便利だけど、セキュリティが心配。ルートディレクトリとか、その辺に危ないモノが置いてあったりしないかなーとか、権限大丈夫かなぁ、とか。

smb も便利だけど、VPN が面倒。ワームとか持ち込まれたくないし、だからといって隔離するのもまた面倒だし。あぁ、困ったもんだ…。