SVX日記

2004|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|

2006-02-05(Sun) メモリの増設を思い立つ

  先日、準最新のノートPCを入手してホクホクのオイラであるが、あまりに快適すぎて不満が出てきてしまった。人間の業とは真に深いものよのう。つまり、ウィンドウの切り替えがちょっとモタつくのが、どーにもガマンならなくなってしまったのだ。特にPhotoshopElement。そりゃ、明らかな超重量級アプリであるから、512MBという我が人生最大のメモリ容量をもってしても、さすがにスワップインが伴っても不思議でもなんでもないのだが。

  でも、気になるのだッ!! ……えぇいッ!! 3年以上は愛用する予定なのだから、増設してしまえッ!! そういえば、最近のメモリの相場はどうなのよ。オイラの最後の記憶では、デスクトップ用のPC-100が128MBで数千円だった気が……いや、車載PC用にDDRの256Mを買ったっけ? まぁ、いいや。まずは、NECの純正メモリを確かめてみよう。

  ちょっと不思議だったのが、このノートPCに付属のマニュアルには、適合する純正メモリの型番が記載されているのに、NEC Directでは扱っていないコト。純正メモリを扱っていない直販サイトってなんじゃらほい……と思いつつ、ググってみてわかった。なんと、1GBの「PK-UG-ME022」は定価16万円(税抜)也。23%オフで129,360円!! ……とかいわれてもなぁ。いくらなんでもこのご時世、そんな値段なワケがない。NECともなれば、扱う部品の種類があまりに多岐に渡るから、値動きの激しいPC用部品のカタログ更新が追いつかなくなり、しまいにはあきらめてしまった状態なのだろうな。

  なんにせよ、価格.comに行ってみよう。なんでも「DDR2 SDRAM/SO-DIMM PC2-4200」という規格が適合するらしい。まずはNEC Directでも売っているI/O DATAの製品……3万すか、ちと高い。BUFFALOの製品も似たようなもの。高いなぁ、512MBにしとくかなぁ……そうだ、ノーブランドだとどうなんだろう? わ。1万弱であるじゃねーか!! でも、相手はメモリだからなぁ。メモリが不良だと、動作が不安定になるし、HDDと違って予備クラスタでごまかせないからなぁ……。

  ……と、しつこくメーカを横断しつつ価格チェックをしていると、ADTECという会社が目に入った。おぉ。以前にココの速度をウリにしたコンパクトフラッシュを買ったことがある。ザウルス用に16M、デジカメ用に64Mを購入した。安定して使えていたし、メーカのイメージは悪くない……でも、1万円ってノーブランドとほぼ同額じゃん? 型番が一文字違うだけの別製品は2万5千円ってどういうこと? 不安……。

  まぁでも、メーカ品ということでこれに決めることにした。適当に通販サイトで注文。あとは届くのを待つだけ。ちょっとわくわく。


2006-02-06(Mon) ディスクキャッシュで腹イッペイ

  そうそう、Linuxのサポートを仕事にしていると、当然ながらOSの挙動について詳しくなる。システムのトラブルを解決するには、大量のシステム統計情報をガリガリと読みこなし、原因を推定し、診断を下さねばならないからだ。だから、最近はLinuxのメモリ利用状況は、ログを読むだけで手に取るようにわかる。

  いきなり昔話になるが、太古のOS(MS-DOSなど)には、ディスクキャッシュという機能があった。搭載されているメモリの一部に、フロッピーディスクやハードディスクから読み込んだ部分を貯蔵して(残して)おいて、再度必要になったときに、ディスクから読まずに、メモリから取り出すことで高速化する機能である。キャッシュに利用されるメモリ量はキャッシュ機能をオンにする時に設定によって決まる。キャッシュ用のメモリ量が多いほど快適になるが、その分メインメモリが減るので、設定には熟慮を要した。

  しかし、近年のOSにはディスクキャッシュの設定は存在しない。だが、別にディスクキャッシュという機能がなくなったわけではない。搭載メモリの遊んでいる部分は、すべてディスクキャッシュに利用してしまおうという方針になっているのである。確かに余っているメモリを有効活用するという意味で、ディスクキャッシュはうってつけである。

  だから、システム起動時はともかくとして、システムが稼動するにつれて、空きメモリにはどんどんディスクの内容が充填されていく。この段階では、キャッシュした内容が再度使われるかどうかの判断なんて行われない。なにしろ、カタッパシから読んだディスクの内容を空きメモリに充填していくのである。これは、設定にもよるが、搭載メモリの90%以上が利用された状態になる程度まで進行する。つまり、真に空いているメモリが10%以下になってしまうまで続くのである。

  この状況は、freeコマンドで確認できる。

[mitsu@colinux mitsu]$ free
             total       used       free     shared    buffers     cached
Mem:         61416      60000       1416          0       3516      38636
-/+ buffers/cache:      17848      43568
Swap:        65528          0      65528

  上記は、coLinuxを64MBで起動して、しばらくの後の状況である。搭載メモリが61416KB、利用メモリが60000KB、空きメモリが1416KB。実にメモリ使用率97.7%である。で、どれくらいキャッシュに利用されているかというと、buffersとcachedの合計値がそれだ。42152KB。これは68.6%である。実に搭載メモリの7割近くは、ディスクキャッシュに利用されているのである。

  で、大変に質問に多いのがこの状況についてである……「たいへんです!! ウチのサーバ、ほとんど空きメモリが残ってないんです!!」……という質問である。結論から言うと、思いっきり大丈夫である。何の心配もない。ディスクキャッシュの内容なんてのは「別になくても構わない」内容であるから(だって、同じデータがディスク上にあるのだ)、別途必要になった時には即座に開放することができるからである(例外はあるが)。

  この状況では「-/+ buffers/cache」の行に注目しなくてはいけない。usedの欄はかなり少なく、freeの欄はかなり多い。これは、キャッシュに利用しているメモリ容量を、空きメモリであるとして計上した場合の容量である(実際にbuffersとcachedの数値を加減してみてほしい)。つまり「実質の空きメモリ」はこの行で確認できるようになっているのである。それを加味すると、メモリ使用率は29%。まだまだ余裕であることがわかる……

  ……と、このようにLinux環境においては、サクっとメモリについて語れるオイラであるが、Windowsはわからない。統計情報をどこで見たらいいのかさえわからない。え? やっぱそう? タスクマネージャ? そーなのか……やっぱり、テキスト至上主義のUNIXの方がどう考えても正しい姿だよな。ホントにこんな情報しかないの? でも、項目の意味すらわからないんだよねぇ。ググる……

  ……概ねわかった。タスクマネージャの「物理メモリ」と「コミットチャージ」が重要な情報らしい。まずは「物理メモリ」の「合計」だが、これは実際の搭載メモリを現している。搭載メモリが512MBなら、約512000を表示しているはずだ。

  画像の説明

  で、重要なのが「コミットチャージ」の「合計」だ。これはシステムが利用しているメモリ容量だ。400000とか表示されていたら、400MB利用しているという意味。なに? ウチは512MBしか搭載してないのに、800MB以上使っているコトになってるって? 大丈夫。別におかしくない。ざっと言うと、足りない部分はハードディスクをメモリ代わりに利用しているからだ。それが仮想メモリ。ただし、ハードディスクをメモリ代わりに使う場合は、必要なときにメモリに呼び戻さなければならないので、遅くなる。これがPhotoshopのウィンドウに切り替えるときにモッサリする理由だ。

  結局、どうすればいいのか? それは「コミットチャージ」の「最大値」を見ればいい。自分が普段使うように……できればちょっと贅沢めにアプリをたくさん立ち上げて、ウィンドウを開きまくって「最大値」を見るのだ。それが望ましいメモリ搭載量である。理論的には、その値が「物理メモリ」の「合計」を上回らない限り、仮想メモリは利用されないはずである。つまり、それでもモッサリを感じるとしたら、それはメモリのせいでなく、CPUの処理能力のせいであるということだ。

  ちなみに「コミットチャージ」の「制限値」は「物理メモリ」の「合計」と仮想メモリの容量を足した数値だ。どうがんばっても、これを超えてメモリを利用することはできないという限界量だが、限界量付近ではかなりレスポンスが悪化するハズなので、ここまで大丈夫であるとは思わないほうがいいだろう。

  あ、オマケに注意しておくと、下のグラフは「ページファイル使用量の履歴」とあるが「ファイル」だからといって、ハードディスクを利用している、つまり、仮想メモリの使用量を示しているわけではない。この値は「コミットチャージ」の「合計」と同じであり、その推移である。あー、まぎらわしい。

  ちゅーわけで、昨日注文したメモリを装着すると、物理メモリがイッキに3倍。仮想メモリは一切使用されなくなるわけで……うーん、楽しみじゃ!!

  画像の説明

  あ、そうそう。結局、職場の同僚に頼んで「巻き取り延長コード」を買ってきてしまってもらった。こっちはなかなかに高級感が漂う作りで、巻き取りもスムーズだ。そりゃ、パッケージの女の子もニコニコなワケである。ちなみに、この娘は目の下がぷっくりしていて、非常にかわいらしい。どうも、オイラは目の下フェチらしい。残念なことに歯グキがちょっと出ているのが減点であるが……って、ナニ書いているんだオレは!! ……と、さりげなく自分の好みをひけらかしつつ、ハヨ届けメモリ。


2006-02-07(Tue) メモリに安心させられる

  画像の説明

  注文していたメモリが届いた。まぁ、しかし……なんだこのパッケージは。コンドームじゃあるまいし。そんなに思い切りデカデカと「安心」なんて表示をしなくても……そりゃ確かに、オイラもそれを一番大事な要素と考えて購入したんだけどさぁ……。

  画像の説明

  しかし、例によって箱を開けると内容物は小さい。下手に大きいとノートPCの中に入らなくて困るので、そりゃ通常サイズであってほしいが、1万円も出したのにかかわらずこの大きさ……金を出した甲斐がないったらありゃしない。今は亡き、ハイウェイカードを5万円分買った時の約20%にあたる落胆ぶりである。

  PCを裏返しにして、ネジを3箇所外し、表に返し、キーボードを持ち上げると、メモリ増設スロットが現れた。で、ちょっと緊張しながら、挿し込む……前に、流しで蛇口に触れておく。これは、静電気でメモリが破壊する恐れがあるので、必要とされている儀式であるが、静電気でメモリを破壊してしまったという人の話を聞いた事がないのはナゼだろう? ここは一発、電子ライターのパッチンで、要らないメモリにプチサンダーを落とし、動作確認をしてみたいところである。意外と平気なんじゃないの?

  余談であるが、似たような儀式に「車のヘッドライトの交換時、電球には手を触れない」というものがある。なんでも、点灯時に付着した手の油脂が蒸発して、電球が割れることがあるらしい。しかし、私は以前に雑誌の特集で、コッテリとバターを塗りつけて点灯させてみた実験記事を読んだことがある。別に、電球は割れなかったという話だ。ちゅーわけで、そーゆーわけである。

  さて、増設して好きなだけウィンドウを開いて作業をしてみた。んが、コミットチャージは750MBを超えない。そりゃ、そうだよな。事前に確認してみた時でも700MBを越えるあたりがやっとだったんだから。せっかく増設したが、増設分の75%が遊んでしまっている状態である。

  しかし、だからといって1GBの増設が無駄で、512MBの増設で十分だったというわけではない。昨日書いたように、近年のOSは搭載メモリの遊んでいる部分をすべてディスクキャッシュに利用し、パフォーマンスの改善に役立てるからである……Linuxだけでなく、Windowsでもそうなんだよね……? まぁ、試してみりゃいいのである。

  cygwinから大き目のファイルのハッシュ値を求めてみよう。ハッシュ値を求めるのは、ファイルの内容をすべてナメ、全領域にアクセスさせたいだけで、今回の場合はそれ以上の意味はない。ちなみに、ファイルは30分のmpeg1ビデオファイルで1つ300MBだ。

SUZAKU:/MyDocuments/My Videos/megaten $ ls
合計 612920
-rwx------+ 1 mitsu 筏 313814368 Feb 20  2005 0220megaten1.vcd.mpg*
-rwx------+ 1 mitsu 筏 313814368 Apr 10  2005 0410megaten1.vcd.mpg*

  まずは、1回目。ハードディスクのランプは点きっぱなしになり、17秒弱を要した。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0220megaten1.vcd.mpg
f1b51c53ee2ebd5bb97bf6dc9abdbee3 *0220megaten1.vcd.mpg
 
real    0m16.929s
user    0m4.806s
sys     0m1.301s

  そして、2回目。ハードディスクのランプは点灯せず。前回の半分以下の7秒強で終了。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0220megaten1.vcd.mpg
f1b51c53ee2ebd5bb97bf6dc9abdbee3 *0220megaten1.vcd.mpg
 
real    0m7.092s
user    0m5.027s
sys     0m1.181s

  念のため、3回目。ハードディスクのランプは一瞬点灯。しかし7秒強で終了。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0220megaten1.vcd.mpg
f1b51c53ee2ebd5bb97bf6dc9abdbee3 *0220megaten1.vcd.mpg
 
real    0m7.253s
user    0m4.876s
sys     0m1.361s

  今度は別のファイルを試す。ハードディスクのランプは点きっぱなしになり、20秒強を要した。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0410megaten1.vcd.mpg
65c2d0261cd90151f1bd06fc63c3c5df *0410megaten1.vcd.mpg
 
real    0m20.343s
user    0m4.566s
sys     0m1.141s

  別ファイルの、2回目。ハードディスクのランプは一瞬点灯。前回の半分以下の7秒弱で終了。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0410megaten1.vcd.mpg
65c2d0261cd90151f1bd06fc63c3c5df *0410megaten1.vcd.mpg
 
real    0m6.897s
user    0m5.117s
sys     0m1.111s

  念のため、もう一度。7秒弱で終了。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0410megaten1.vcd.mpg
65c2d0261cd90151f1bd06fc63c3c5df *0410megaten1.vcd.mpg
 
real    0m6.966s
user    0m4.917s
sys     0m1.321s

  最初のファイルを再度やってみる。7秒弱。

SUZAKU:/MyDocuments/My Videos/megaten $ time md5sum 0220megaten1.vcd.mpg
f1b51c53ee2ebd5bb97bf6dc9abdbee3 *0220megaten1.vcd.mpg
 
real    0m6.876s
user    0m4.917s
sys     0m1.311s

  どうやら、Windowsでも搭載メモリの遊んでいる部分は、すべてディスクキャッシュとして利用されるようである。この実験をやった時のコミットチャージは約740MB。利用可能メモリは約870MB。上記のファイルは2個で合計600MBであるが、ディスクアクセスはなかった。つまり、600MBがスッポリとキャッシュされているということである。一方で、もしメモリを1Gしか搭載してない場合は、利用可能メモリは約360MBになるだろうから、上記を交互に実行すれば、毎回ディスクアクセスが発生するはずである。

  それはそうと、メモリを大量に積んだので、アプリ立ち上げ放題なのはよいのだが、問題はタスクバーである。幅が足りずに切り替えボタンが出てきてしまうのである。これはどうにかしないと、不便で仕方ない。まっとーな案としては2段に増やすのがよいのだろうが、それももったいない……なんか名案はないものか、トホホ……。


2006-02-09(Thu) 夫婦(めおと)PCチーミング

  とりあえず

  画像の説明

  画像の説明


2006-02-10(Fri) FT245AMテスト基板プチ進捗

  とりあえず

  画像の説明


2006-02-15(Wed) Cygwinでsoxしてlameする

  PCを新調して、HDDが80MBになったので、iTunesをインストールして、手持ちのCD百数十枚をすべて放り込んだら、ナンでもカンでもこのPCに集めてしまいたくなってきた。残りHDD容量は15GBを切っているが、まだ15GBもあるという見方もできる。なんとなく、過去にCD-R焼いて保存してあった、デジカメの写真もHDDに呼び戻してしまう。なーに、容量が不足したら、改めてDVDに焼いてしまえばいいのだ。

  そうだ。そういえば先日、過去に録り溜めた「英会話入門」のCD-Rが見つかったのだった。mp3に圧縮して、CD5枚ほどになっているから、軽く数年分はありそうだ。以前に書いたとおり、最近「英会話入門」が再開されたのだが……しかし、どうも昔のノリでないんだよなぁ、コレが。で、番組を聞く環境整備もできないまま、しばらく聞かずに自動録音サーバを放置しておいたら、いつの間にか遠山顕先生は「英会話中級」に移っていて、録音時間がズレ、録音しソビれていた……えぇい!! なにしろ、このCD-RもすべてPCに放り込んで、聞く環境を整備するのだッ!!

  ……と、意気込みつつ、昔のCDを読ませたトコロ、妙にmp3のファイルサイズがデカい。英会話入門は15分番組なのに8MBも食っている。普通の曲だと15分で15M弱になるはずなので、8MBは十分に小さいが、モノラルのしかもAMラジオの録音に、44kHz、80kbpsというのは、ちょっとオゴりすぎじゃねぇか。当時のオイラはナニを考えていたんだろう? こりゃマズい。なにしろマズい。マズいったら、マズい。これは再エンコードしなおして、正しい状態にしなければ。

  最終的に英語を聞くのが目的なのであれば、ビットレートなんて気にせずにサッサと聞き始めればいいのだが、どーもオイラの悪いクセが出た。こーゆー問題を解消しないと聞く気にならなくなってしまうのである。だが、これは技術者全般の悪いクセであろう。正しい状態にして、キチンとライブラリ化しないと気がすまない。だってそうすりゃ、プレイヤへの転送も速くてラクだ。ラクするための苦労をいとわないのが正しい技術者の姿である。だから、これでいいのだだッ!!

  再エンコードする方法にもこだわる。イッキに、ラクに、確実に……と考えると、コマンドインターフェイスのヤツ以外には考えられない。unix系のmp3エンコーダである「lame」とサウンドコンバータ「sox」を利用することにしよう。これをcygwin環境にインストールするのである。

  しかしながら、cygwin用のバイナリ配布は行われていない。よって、サックリとはインストールできず、いわゆる「./configure、make、make install」を行う必要がある……のだが、オイラはこの方法でちゃんとインストールできたコトが少ないんだよねぇ。大丈夫だろうか。まぁ、とりあえず、やってみる。

  まずは「lame」だ。「./configure、make、make install」……お!? これは一発でインストールできた。特に問題も生じない。じゃ、この調子で「sox」だ……が、ダメ。最後の「make install」する段になって……

SUZAKU:/home/mitsu/sox-12.17.9 $ make install
make: `install' は更新済みです

  ……とか出ちまってインストールができない。なんだ!? ナニが悪いのか? 最近はLinuxのサポートをやっているので、不具合の根っこを調査するのに、ソースを読んでどうこうするのには慣れたが「./configure」や「make」はいまだに苦手科目なんだよなぁ。こういう場合は、どうやって問題の根を探したらいいんだ?

  落ち着け。そもそも、soxを「./configure」する時点でおかしい。

$ ./configure
 :
 :
Old Rate enabled..................   no
Fast ulaw enabled.................   yes
Fast alaw enabled.................   yes
GSM Support.......................   yes
ALSA Driver.......................   no
OSS Driver........................   no
SUN /dev/audio....................   no
Ogg Vorbis support................   no
MAD MP3 Decoder...................   no
LAME MP3 Encoder..................   no

  soxは外部に関連プログラムがあると、自動的にそのライブラリを利用するようにコンパイルされる。今回の場合はlameだ。ライブラリを取り込んで、soxが直接mp3を吐けるようになる。だが、既にlameのインストールは終わっているハズなのに表示が「no」のままだ。別にsoxでmp3を吐けなくても、パイプでlameに渡してもいいのだが、せっかくそのような機能があるのに、利用しないテはない……というか、利用できるハズなのに理由がわからず利用できないのは、どうにも気持ち悪い。

  さらに気になるのはその前のmadというヤツ。こいつがあればsoxが直接mp3を読めるようになるっぽい。今回の場合は入力も出力もmp3であるから、そんなものが利用できるなら、利用しないテはない……というか、利用できるハズなのに理由がわからず利用できないのは、どうにもこうにも気持ち悪い。

  ちょっと本腰入れて「./configure」について勉強するか。ググると「configureをデバッグする」なんてぴったりのページが見つかった。ふみふみ……config.logを読めって?

SUZAKU:/home/mitsu/sox-12.17.9 $ vi config.log

  おぉ!! 「./configure」ってのは、内部で小さなプログラムをコンパイルしまくっていたのか!! 知らなかったぞ!! ほんじゃ、lameが失敗する理由は?

configure:4695: checking lame/lame.h usability
configure:4707: gcc -c -g -O2 -mno-cygwin -Wall  -mno-cygwin conftest.c >&5
conftest.c:68:23: lame/lame.h: No such file or directory
configure:4713: $? = 1

  即席で作られた「conftest.c」の中には「#include 」が含まれていて「そんなファイルはない」って結果を受けて、lameが見つからないコトになっているわけね。じゃ、試しに以下のコードをコンパイルしてみる。

#include <lame/lame.h>
 
int main() {
        printf("Where is lame?\n");
}
 
$ gcc test.c

  フツーにコンパイルできるじゃん!? じゃ「./configure」の中身と同じオプションでコンパイルしてみる。

$ gcc -c -g -O2 -mno-cygwin -Wall -mno-cygwin test.c
test.c:1:23: lame/lame.h: No such file or directory

  ダメだ!! どのオプションが影響しているのか!?

$ gcc -mno-cygwin test.c
test.c:1:23: lame/lame.h: No such file or directory

  「-mno-cygwin」だ。これってナニ? 調べたら、cygwinライブラリを利用しないバイナリを生成するオプションとのコト。cygwinライブラリを組み込むと、cygwinをインストールしていない環境で動かなくなるとか、自動的にGPLになってしまうという政治的な問題があるらしいが、そんなの自分のPCで使う分には関係ないやん。サクッと……

SUZAKU:/home/mitsu/sox-12.17.9 $ vi configure
   2849 case "$target" in
   2850     *cygwin* )
   2851 #       CFLAGS="$CFLAGS -mno-cygwin"
   2852 #       CPPFLAGS="$CPPFLAGS -mno-cygwin"
   2853 #       LDFLAGS="$LDFLAGS -mno-cygwin"
   2854                 ;;
   2855 esac

  ……コメントアウト。再度「./configure」する……でも、最終的な結果は変わらず。もう一度、config.logを読む。

configure:4695: checking lame/lame.h usability
configure:4707: gcc -c -g -O2 -Wall  conftest.c >&5
configure:4713: $? = 0

  おぉ。さっきのトコロはうまくいってるぞ。

configure:4831: checking for lame_init in -lmp3lame
configure:4861: gcc -o conftest.exe -g -O2 -Wall   conftest.c -lmp3lame   >&5
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lmp3lame
collect2: ld returned 1 exit status
configure:4867: $? = 1

  今度はココでコケとる。「-lmp3lame」が見つからん? ライブラリの「libmp3lame.a」がないってことか? それが「/usr/local/lib」下にあるのは確認済みじゃゾイ。ライブラリの位置を教えたればいいんかな? 以下のようにオプション付けて、再度「./configure」じゃ!!

$ ./configure "LIBS=-L /usr/local/lib"
 :
 :
Old Rate enabled..................   no
Fast ulaw enabled.................   yes
Fast alaw enabled.................   yes
GSM Support.......................   yes
ALSA Driver.......................   no
OSS Driver........................   yes
SUN /dev/audio....................   no
Ogg Vorbis support................   no
MAD MP3 Decoder...................   yes
LAME MP3 Encoder..................   yes

  よしゃーッ!! なんだか、OSS Driverなんてのもyesになってしまったぞ。ウホウホ。抜く手も見せずに「make」して「make install」するッ!!

SUZAKU:/home/mitsu/sox-12.17.9 $ make install
make: `install' は更新済みです

  うげ。相変わらずやん……コレ、意味わからん……でも……「$ make -n uninstall」は動くんだよねぇ……って、もしかして、アレか? この「install」って名前が悪い? つーか、同じディレクトリに置いてある「INSTALL」っていうドキュメントファイルに反応している!?

SUZAKU:/home/mitsu/sox-12.17.9 $ mv INSTALL INSTALL.txt
SUZAKU:/home/mitsu/sox-12.17.9 $ make install

  で、できた……な、なんつーアホタレな……CygwinはベースがWindowsだもんだから、ファイルの大文字小文字の扱いが適当なんだよな。そんでもって、変換はこうだ!!

$ sox before/1007.mp3 -b -r 16000 -t wav - | lame -b 24 - - > after/1007.mp3

  なんだか、結局、パイプでつないでるんですが……だって、soxからビットレートが指定できないんだから仕方ないんだもん!! ……ま、それはそうと、これで15分2.5M程度というAMラジオの録音にはふさわしい、通常の楽曲のmp3の1/6程度という状態に持っていけるようになった。よっしゃよっしゃ。


2006-02-26(Sun) FT245AMテスト基板稼動

  久々に、ちょっと気合を入れて作業してみた。思い返せば、基板を設計してから約1ヶ月、基板が届いてから1ヶ月、ハンダ付け始めてから1ヶ月……で、今日になってやっと通信に成功した。まったくもってヒドい開発ペースである。

  今回作った回路はこんな感じ。

  画像の説明

  途中まで裏表逆に設計してしまった上に、使った線がちょっと太かったので、なんだかムチャなことになっている……が、ちゃんと動くからこれでよいのだ。USBに接続すれば、ちゃんと認識されるし、Cygwinから/dev/com8にデータを送れば、ちゃんとPICが受信してくれる。一応、変換基板としては動作確認完了といってよいだろう。ほっ、よかった。

  画像の説明

  とりあえず、これといって作りたいUSB対応機器はないのだが、以前から便利に使っていた「CPU使用率メータ」のUSB版でもサクッと作ろうかと思っている。今、職場で使っているPCはノートだもんだから、シリアルポート用のアイテムが使えないんだよね。

  余談だが、この開発は、以前に愛用していたジャンクのメビウスノートを引っ張り出してきてやっている。というのも、以前に作ったRS-232C切り替え器はPICライターの接続に便利だし、4ポートの内蔵USBハブもこれまた便利なのだ。233MHzの遅さはちょっと気になるが、まぁ、Cygwinのviでソース書いて、アセンブルして、PICに書き込む程度なら、さして気にするほどでもない。

  しかし、なんといっても一番の利点は、電気的にエラいミスやらかしちゃってPCがぶっ壊れても、あぁーあ……で済むことであったりする……なはは……。


2006-02-27(Mon) ほろ酔いケース加工

  ちょっと工作づいてきたんで、久々にドリルを出してガリガリやる。

  なんだか、久々にやり始めたら楽しくなってきちゃって、廊下の端に座り込んで、グラスのスコッチをチビチビやりつつ、その辺に転がっていたプラの名刺ケースの箱をガリガリ。史上最強にいい加減な加工をしてしまったが……まぁ、とりあえず十分である。あ、ちなみに、今回使用するアナログメータは、以前に90円で買ってきたバッテリチェッカをバラしたジャンク部品である。シャレであるから動けばよいのだ。

  画像の説明

  まだ、PIC上のファーム側(たぶん)に問題があって、針がちゃんと動かない状態なのだが、そっちには手付かず。こんなモノは早く仕上げてしまって、他に放置してあるプロジェクトを再開したいトコロらのらが……ふぁ〜、気分らよくなっれきら〜、おやふに〜……。


2006-02-28(Tue) CPU使用率を得てみる

  ここ数日「USB接続版アナログCPU使用率メータ」を作っているワケであるが、あくまでハードウェア側は「入力された数値をアナログ表示するだけ」のガジェットであるから「CPU使用率メータ」にするためには、PC側から「CPU使用率」をハードウェア側に継続的に送信しなくてはならない。

  以前にCPU使用率メータを作った時には、ネット上からWindows用のCPUメータアプリ(ソース付き)を持ってきて、適当に流用して作った。今回もそれを使おうかな、オレ用cvsからプロジェクトを落としてと……あれ? リンカを通らない……あぁ、前回はBorlandのフリー版Cコンパイラ用に書いたんだっけ……Cygwin上のgccだとなんだか大量にエラーを吐いてしまう。いまさらコレだけのために、別途Cコンパイラを入れるのもイヤだなぁ……面倒くさい。

  どぉーしよぉー……ん? 待てよ? Cygwinにはtopとかvmstatとかってないんだっけ? ……ない……ん? じゃ、/procの下になんかないの? お!? あるじゃん!! /proc/stat!! Cygwinってイザという時に期待を裏切らない。イザという時以外には、よく期待を裏切られるけど……。

  ちなみに、/proc/statの中身はこんな感じだ。

$ cat /proc/stat
cpu 4120394 0 5247745 79092769
cpu0 4120394 0 5247745 79092769
page 2388170 390404
swap 2388170 352464
intr 62255651
ctxt 338348792
btime 1141097464

  大事なのはcpuの行。詳細はman procするか、ココを見て欲しいが、なにしろ、CPUが仕事してた時間と遊んでた時間の合計はここから得られるのである。あとは単位時間ごとに差分をとって比率を得るだけ。

      1 #!/usr/bin/ruby
      2
      3 # CPU使用率を求める
      4
      5 busy = all = nil
      6
      7 loop {
      8     open('/proc/stat', 'r') {|psh|
      9         lastbusy = busy
     10         lastall  = all
     11
     12         if(psh.readline =~ /^cpu\s+(\d+)\s+(\d+)\s+(\d+)\s+(\d+)\n$/)
     13             user = $1.to_i; nice = $2.to_i; sys = $3.to_i; idle = $4.to_i
     14             all = (busy = user + nice + sys) + idle
     15         end
     16
     17         if(lastall)
     18             p (lastbusy - busy) * 100 / (lastall - all)
     19         end
     20     }
     21     sleep 1;
     22 }

  わ……以前のバージョンは結構苦労して作って、苦労してコンパイルを通したのに、/procを利用してRubyで書けばコレだけかよ!! 仕事中でもサクッと書けちゃったよ……あれ? ……あ、いや……その……えーっと、オイラの仕事はLinuxのサポートなのだからして、/procの下に何があるのかキチンと知っておくのも大事な仕事なのだからして……あひゃひゃひゃひゃ。