SVX日記

　 仕事帰りになんとなく本屋に寄る。「FavoriteBlue」のアルバムでも200円くらいで売ってたなら買おうと思ったのだが見つからない。んじゃ、300円くらいでプレステのゲームでも発掘しようかな。最近はシューティングゲームが減ったねぇ。そういや「くまうた」が欲しいんだけど、中古でも売ってないねぇ。オイラはベスト版で出てるなら、むしろ積極的に中古より新品を買ってあげたい主義なのだが……ん？　なんだこれ。ナムコのゲームで「スターイクシオン」ってある。ナムコのプレステゲームは背中にエンジ色で「namco」って書いてあるのでわかりやすい。オイラにとってナムコはブランドだからとっても便利だ。

　 うわッ!!　280円かよ。予算より20円も安いぞ。しかし、ナムコのゲームで280円ってどうよ。少し躊躇したが購入。裏の画面写真から、なんとなく「アレ」っぽい雰囲気を感じるのだ。「アレ」のリメイクなら、そりゃ思っても見ない掘り出しモノである。

　 おぉっと!!　想像通り「スターラスター」のリメイクであった!!　しかも「ギャラガ」「ボスコニアン」「スターブレード」「ギャラクシアン3＋ゾルギア」「ネビュラスレイ」等の世界と融合しているらしい。こりゃある意味「スーパーロボット大戦」ならぬ「ナムコスペース大戦」ではないか。オープニングCGから、宇宙モノのナムコのハイセンス全開!!　これだけでも280円の価値は十分にあるってモンだ。

　 ナゼかセーブに5ブロックも必要なので、今のトコロちょろっと雰囲気を味わっただけだが、操作感は元祖スターラスターのがクイックでよかったような……まぁ、もう少し遊んでみよう。とりあえず、掘り出し物であった。

　 今晩は「敵は海賊」の2話目が放送。先週の期待通りラジェンドラのCDS攻撃の映像を観ることができた……が、攻撃を喰らった艦がススけたように黒くなるという表現は微妙。あとは……あまり印象なし。それとやっぱりジュビリーが青いのは違和感。もし「海賊版」も映像化するとなると、シャルファフィンも青いのか!?　それじゃ、ほとんどマゾーンではないか!?　とか余計なことを考えてしまう。うひゃぁ。

　 あ、そうそう。一昨日(15日)の日記に書いた「トークの達人」だが、ナムコ自主規制により、ワルキューレ、カイ、ジェニファー、アルテミス、ミズパックマンの登場は見送られることになった模様(根こそぎやんか!!)。理由は「既に彼氏がいる女性を口説くゲームは倫理に反するから」とのコト。しかし、ワルキューレの彼って……まさかッ!?　サンドラッ!?　おいっ!!　そうなのかッ!?　(注:このゲームは筆者の想像の産物につき発売予定はないので念のため)。

　 次期サーバが落ちまくる。今度はHDDのLEDが点灯していない状態で。シリアルコンソールを接続しておいたので、落ちる瞬間の情報や、sysrqの情報の取得を狙ったが、採取できず。まったくのダンマりじゃ、手が出ない。

　 こりゃ、完全にハードウェアくさい。HDD以外のニオイもするが、交換してみるか……と、思っている矢先にまた落ちた。仕方ない、元のサーバに切り戻す。Linuxのプロとしては屈辱的だが、ハードウェア要因ではいかんともしがたい……ぎゅー。

　 昨日100円ショップで購入した、コレクションケースに各パーツを収める加工をする。

　 ちょっとケースが大きめだけど、なにこの高級感ッ!!　特に350円のラジオのパーツの工業的造形が、100円のケースによって超引き立てられている感じッ!!

　 以前から、100円ショップのコレクションケースはガワとしてかなり有用だろうとは思っていたが、ここまでイイ感じに収まるとは予想外だった。見た目だけでなく、底が微妙に上げ底になっているので、皿ネジ加工も不要なのもポイントが高い。

　 100円ショップのタッパーも便利だが、完成品が強烈な生活感を漂わせてしまう。その点コレは、ほぼ同額なのに、一切の生活臭を感じさせない。これはイイ。また使おう。

　 甲での撃破は難しいかと思っていたが、なんと、削りに7回、最終形態2回目にしてアッサリ撃破。決めたのは大井。この後、北上が決めてS勝利だった。

　 実は、休憩所などと評されているE4で、出撃15回の大苦戦の後だったりする。どうも最近、実生活も含め自分の周囲で羅針盤が荒ぶりすぎている気がする。不意に頓死しないように気をつけないと……。

　 というわけで、約一週間、ワイドハイターEXに漬けて天日干しした結果の発表である。

　 「パワー」キーは、未処理の状態のもの。「Alt」は「パワー」キーと同じキーボードAのもの。「Shift」と「↑」はキーボードAより多少マシだったキーボードBのもの。

　 見た目、未処理のものよりかなり改善している。「Alt」は「Shift」や「↑」と同程度に白くなったが、すぐ左の「キーの裏側」に比べると、やはり黄バミは完全に除去できるわけではないことがわかる。

　 せっかくなので、GIMPでキーの左上辺りの色をピックしてみたところ、妥当な結果が得られた。

　 「Alt」は「Shift」や「↑」と同程度に白くなったように見えるが、そうでもないことがわかる。やはり、人間の感覚はアテになりませんな。

　 で、なんで、右下付近のキーしか復旧していないのかといえば、そりゃ、今回は単に洗うだけじゃなくて、ちょっとしたアイデアを実装する予定があったからで……。

　 ちょっと前、タイヤ問題で1年以上もゴタゴタしていた、と書いたが、その経緯をメモ代わりにまとめておきたい。

　 発端は、昨年1/9のタイヤの交換のための組み換え。ヤメときゃいいのに(なんて今でもぜんぜん思っていないがw)自分での組み換えに挑戦した。

　 十分に動画サイトで作業方法を予習し、近所のタイヤチェンジャが使えるレンタルピットを借りて作業を行った。4時間半もかかったし、ピットのレンタル代を考えると、業者に任せたほうが安かったかもしれないが、(その時点では)特段の失敗もなく作業を完了できたので、大変な作業ではあったが、あー、楽しかった、で済んだ。

　 その後、それなりの重作業をコナせたことに味をしめ、サスの交換作業にまで手を出す。これも何とか、特段の失敗もなく作業を完了する。

　 が、問題は半年後の6/4に起きる。左リア(A)のタイヤの空気が抜けていることに気づく。自分で持ち込んで取り付けたアルミのクランプインバルブのゴムパッキンが割れたためだ。というか、バルブのナットの締めがユル過ぎたのが原因だ。

　 この締め方については「そんなに強く締める必要はない」というネットの情報を元にユルめに締めたもので、意図した締め方ではあったのだが、結果としては、それだと足りなかった、ということであった。

　 空気はかなりの速度で抜けるので、すぐに交換用のパッキンを手配し、その翌週末にはタイヤだけレンタルピットに持ち込んで修理を行った。この時点では、締め方が足りない、という明確な認識はなかったので、それでもややユルめに締めた状態で作業を終えた。

　 そして、その3ヶ月後の9/11に右リア(C)のタイヤの空気が抜けていることに気づく。状況はほぼ同じ。この時点で、バルブのナットの締めがユル過ぎたことが原因と確信する。前回と同様にその翌週末の9/17、タイヤだけレンタルピットに持ち込んで修理を行ったのだが、3度目ということで作業をナメていたためか、タイヤを外す際に、タイヤのリムを載せるところを間違えていることに気づかず、ムキになって力任せな作業をしてしまい、タイヤやホイールにダメージを与えてしまう。その因果かはわからないが、ビードも一発でうまく上がらず、ちょっとトラウマを抱えてしまう。

　 さらに悪いことは続く。10/30に左リア(A)の空気が抜けていることに気づく。思い返せば10/13にタイヤの外側に釘状のものが刺さっていたので抜去したのだが、それが原因かもしれない。その翌日、左フロント(D)の空気がだいぶ抜けていることに気づく。こっちはまたもやバルブだ。まさに踏んだり蹴ったり。その週末はカミさんと遠出の予定があったのだが、タイヤに不安を抱えて向かうわけにも行かず、アクセラで向かった。いい季節なのにもったいなかった。

　 11/4にダメ元で左リア(A)のタイヤを外して石鹸水をかけてみた。そう容易ではなかったがシツこく観察を続けたら、タイヤの外側の肩に近い部分の溝部分から空気が漏れていることを特定できた。原因はパンクで確定。この頃になると、空気圧を計測するのが日課になってしまい、空気の抜け具合が予測できるようになり、スローパンクチャを制御しながらドライブに出かけられるようになる。ちっとも嬉しかないが。

　 翌日の11/5。スローパンクチャを起こしている左リア(A)は棚上げして、左フロント(D)の修理のためにレンタルピットへ。前回のトラウマを抱えつつの出撃だったが、割とスムーズに作業完了。タイヤを外すコツは反対側のビードをしっかり下げることだ。

　 この時点で、左リア(A)、右リア(C)、左フロント(D)のバルブを修理済みだが、右リア(B)は未修理で、左リア(A)はスローパンクチャを起こしている。思い切ってリアの2本を新品に交換しようかとも思ったが、パンクの程度は十分に軽いので、内側から自転車用のパンク用パッチを貼れば修理できると踏み、パッチと接着剤を手配する。

　 そしてすべての問題の解決を目指して11/26にピット作業。内容は、左リア(A)のパンク修理と右リア(B)のバルブ修理。なので、自走して向かう。ついでにローテーションすべく4輪ジャッキアップし、割とスムーズに作業完了。パンクも直った模様。が、ここで大事件。右リア(C)を右フロントに移動する際に、内側側面にコブができているのに気づいてしまう。位置が変わって、右フロント(C)は、先に作業に手こずりムキになって力任せな作業をしたヤツだ。無理にビードをメクり上げた時にカーカスコードを切ってしまったのだろう。しゃーない。とりあえず、そのまま帰宅。

　 悪いことに12/1には2度目の車検を予約していた。が、こんなコブ持ちタイヤでは車検は通らないかもしれないと、事前に確認したところ、残り溝が残っていることが基準なのでコブは問題ないとのこと。お役所仕事的だが、とりあえず助かった。言葉通り、マツダのディーラー車検は無事にクリア。

　 んが、翌日にびっくり。コブ持ちタイヤの空気圧が低い。どうも、スローパンクチャ症状も併発しているようだ。

　 そんなこんなをやっているうち、パンタジャッキにイヤ気が差してきて、安いフロアジャッキを購入。やはり、すごくラク。というわけで、コブ持ちタイヤを外して、コブの様子の観察と、石鹸水によるパンク箇所の特定を試みる……と、なんとパンク箇所はコブ周辺でなくリムであった。そんなことあんのか。

　 いずれにしてもコブはリスクなので、タイヤの交換は必須だ。問題はこの時点で、タイヤ交換から7000km走っており、残りの寿命が80%というところ。トレッドはそれなりにすり減っており、新品のタイヤとは直径が変わっているのである。こういう場合、反対側とセットで2本交換するのがセオリーとされている。しかし、反対側の左フロント(A)はパンクを修理したばかりだ。割と賭けに出た修理方法ながら、ワザワザ修理をして直したんだからなぁ……と、悩んだ挙げ句、1本だけ新品タイヤに交換することに決める。

　 が、ここでまたとんでもなく運の悪いことに、ジークス(ZIEX)のZE914Fがディスコンのようで買えなくなっていた。同じジークスのZE310Rというのは買えるようだが、製品としては別物のようだ。左右で違うタイヤというのも、だいぶ避けるべき状況に思える。やはり反対側とセットで2本交換するしかないか。

　 と、グズグズとした思いを抱えながら、ダメモトでヤフオクを眺めていたら、なんと、中古のZE914の195/50R16が1本だけ税込み送料込みで5000円で出品されているではないか。山は多めに残っている(=多少は減っている)ということで、中古であることがよりプラスに働いている状況である。こんなとんでもなく運の良いことってあるものなのか。慎重に考えても、多少のリスクはあるとはいえ買わない理由はない。ということで、12/14にポチる。で、翌日に届いたタイヤはZE914ではなくZE914「F」であった。ますますラッキー。

　 あとは、このタイヤに交換するだけだが、ふと、スローパンクチャの原因がホイール側にあった場合、またもや再修理が必要になってしまうことに気づいてしまう。車検の時に「旧い仕様のパーツも買える」と聞いたので、実際ホイール1本がいくらで買えるか聞いてみると16000円＋税とのこと。実はモノタロウでいくらで買えるかは知っていたのだが、特に値上げもなくその値段であった。タダではないが、ホイールとしてはだいぶ安い。

　 というわけで、注文し、一週間弱ほどで届いたのが1/28。その翌日、今度こそすべての問題の解決を目指してピット作業を済ませ、その後は何の問題も出ていない。コブ持ちタイヤはそのまま工房に置いてある。スローパンクチャも起こしているが、ローテーション作業や、イザという時にテンパータイヤとして100km前後を走る程度のことには使えるはずだ。あとはホイールの観賞用w。

　 で、改めて気づいたことをいくつか。タイヤを外す場合、表から外すのと、裏から外すのでは、難易度が異なる。普通はしないだろうが、バルブの修理をする場合、裏側に外すと、完全に外さなくても修理できるので、そうしたくなるのだが、ホイールの断面は、表と裏では異なり、表側のがリム裏の落差が大きい。つまり、裏側だとビードが内側へ入る量が少なくなるので、外しにくいのだ。こういう「表 Ｌ＿／｜ 裏」こと。

　 それと、今回、右フロント(C)だけ中古タイヤに交換して心配だったのが、左フロント(A)に比べてトレッドの減りが少ないこと。溝の様子から1mm前後は少なく、つまり、直径が2mm前後大きいということだ。2*PIで、1回転で6mmくらい差が出る計算になる。外形600mmなので、ちょうど1%程度。最悪、直進する際にハンドルのセンタがズレたりするのか、と思っていたが、実際には何も起きなかった。

　 が、考えてみれば、FR車の場合、フロントタイヤなんて付いているだけに近いわけだから、仮に1cm差があったって、直進している限り、距離に対する回転数が変わるだけだわな、と気づいた。リアだとLSDが付いており、フロントとは状況が異なるので、ローテーションするかどうかは迷うところだが。

　 というわけで、1年以上もゴタゴタしていたタイヤ問題はようやく片付いた。幸い出先でレッカーを頼むようなことにならず、それなりに多くの体験を通じて知見が得られたので、総合的にはやって良かったと言えよう。次のタイヤ交換が楽しみである(って、また自分でヤル気マンマンなのであったw)。

　 さぁ、今週末から、超ロングドライブである。

　 Linuxのサウンド機能についておさらいしたところで、だーいぶ以前に作った自作のDTMスイート「CUIck DTM suite」を引っ張り出してみることにした。当時はまだWindozeを使ってたので、Cygwin環境に向けて書いたものだ。何度か何度か何度かお色直しして使い続けているが、いまでも使えるものだろうか？

　 「CUIck DTM suite」には「melod」という発声デーモンがあって「konk」というアプリを組み合わせることで「PCのキーボード」が「楽器のキーボード」と化す。過去にはソレ用にこんな風に塗り分けたりしてた頃もあった。

　 「melod」は「/dev/dsp」にPCM波形を書き込み続けるデーモンで、当時はよく考えずに作ったものなのだが、これはOSS(Open Sound System)アプリだったわけだ。

　 まずは、前回まとめたところの、以下の経路で使ってみる。

OSSアプリ → OSSエミュ(PulseAudioの) → PulseAudioエミュ(PipeWireの) → PipeWire → ALSA

　 PulseAudioのOSSエミュレータ「padsp」を噛ませて起動するわけだ。

$ padsp ./melod

　 通常の環境には/dev/dspは存在しないのだが、padspを噛ませた中の環境には/dev/dspが出現するので、それを経由してPulseAudio……ではなく、PipeWireを経てALSAから鳴るわけだ。実際、アッサリと鳴った。よく考えてみれば、エラく回りクドいことをやってたんだな。

　 しかし、別にその経路が唯一というわけではない。OSSエミュレータはALSAからも提供されているのだ。カーネルモジュールの形になっており、通常はロードされていないが、ロードすりゃ使える。

# modprobe snd_pcm_oss

　 これにより/dev/dspではないが、/dev/dsp1, /dev/dsp2が出現する。/dev/dsp1がノートPC本体のデバイス、/dev/dsp2はドックのデバイスを指すものだ。これを使えば、以下の経路を使うことになる。

OSSアプリ → OSSエミュ(ALSAの) → ALSA

　 melodの/dev/dspを/dev/dsp1に書き換えて起動してみる。

$ ./melod

　 んが、動かん。音を鳴らそうとした瞬間に落ちる。どうもfragment(バッファ)のサイズが足りないらしい。なんで？

　 fragmentのサイズを調べようと思って、ioctlでSNDCTL_DSP_GETBLKSIZEを発行してみる。どうでもいいけど、ioctlってどこかに仕様がまとめられていたりしないの？ カーネルのコード読むほかないのかしらん。

    x = [0].pack('i*')
    p dsp.ioctl(0xc0045004, x)                                  # SNDCTL_DSP_GETBLKSIZE
    printf("%04x\n", x.unpack('i*')[0])

　 55hって値が返ってきたが、なんのこっちゃ……って、アレ？ なんか音が出るようになっているのだけれど。なんで!?

    x = [0, 0, 0, 0].pack('i*')
    p dsp.ioctl(0x8010500c, x)                                  # SNDCTL_DSP_GETOSPACE
    printf("%04x %04x %04x %04x\n", *(x.unpack('i*')))

0020 0020 0080 1000
 ↓
0020 0020 0300 6000

　 事前にSNDCTL_DSP_GETBLKSIZEを実行すると、fragmentサイズとして55hが返ってくるのだが、なぜかその後のfragmentサイズは6倍(80h->300h)になっている……ワケワカラン。まぁ、鳴ったからいいけど。当然ながら、この経路でALSAを使う場合、デバイスは専有されるので複数起動することはできない。

$ ./melod
./melod:26:in `initialize': Device or resource busy @ rb_sysopen - /dev/dsp1 (Errno::EBUSY)

　 しかし、なにより驚いたのは、padspの実体がシェルスクリプトになっていたことだ。以前はバイナリだったんだがな。

　 結局、この辺りは「いつまでも工事中」ということなんだろうな。ベストを求めて、常に発展途上であり、使う時にはちゃんと最新事情を調べて理解することが重要ということだ。前回と同じ結論だな。以上。解散。