【Bluetooth接続断念】AndroidのカーオーディオFMトランスミッタ接続

少し前になりますが、Android買いましたよ～

併せて16GBのMicroSD Cardを購入したので、手持ちのCD(ogg圧縮済み)は全てAndroidで持ち運べる。
ネットラジオも3G経由で聞けるので、容量関係なく音楽漬け...
TuneWikiとかLast.fmとか機会があれば紹介します。

まあ、そんなに音楽好きでもないのですが、ドライブのときにCDをセレクトして持って行ったり、いちいちCDチェンジするのはちょっとと思いますので、Androidのカーオーデイ化に挑戦です。


先ず考えたのが、Bluetoothで繋ぐこと。
HT-03Aにはなんと物理接続端子がUSB miniBの独自拡張の一つのみ(ステレオヘッドフォン、マイク、リモコンを押し込んでいます。もちろん?充電もここから)。
この潔さは大好きですが、充電用に汎用USBコードを繋ぐとオーディオ有線は無理。

AndroidはBluetooth 2.0 A2DP対応なのでこれがリーズナブルかと思ったの次第。

我が家のカーオーデイオはbluetooth対応でないものの、赤白端子くらいはありそうなので、ここにシガーライター電源のBluetooth受信機を接続すれば終わりかと。

ところろが、そんなものはヨドバシやAmazonを調べても存在しない。
シガーライター電源の赤白端子接続ケーブルはiPod用のものしか...
iPodスピーカーをBluetoothスピーカーにするBluetoothレシーバなるものがあるようなのでこれを組み合わせれば、と思ったのですが、iPodというClosedな仕様を挟まざるを得ない気持ち悪さと、出費が嵩むのことから断念。

それにしても、カーオーディオケーブルといい、スピーカーといい、それ用のBluetoothレシーバといい、いかにiPodが音楽再生機の一大勢力であるかを再認識させられます。


次に考えたのが、接続端子は分岐アダプタで増やすとして、

 オーソドックスにFMトランスミッタ接続。

例によってFMトランスミッタもiPod用のものが大半ですが、さすがにステレオminiプラグ+USB充電端子を備えたものを見つけることが出来ました。

 これで、カーオーディオ接続完了です(コード邪魔だけど)。

次はAndoroidホルダか?

古くて新しいOS機能への回帰の動向

Firefoxの未来形ではタブ毎にプロセスを分ける設計を検討しているそうです。

Firefoxのタブも、Chromeに似たマルチプロセス化へ － ＠IT

もちろん、タブごとのマルチプロセス化による恩恵は、グーグルがChromeの発表時に広く宣伝したことで知られるようになったとともに、IE8ベータの影響も大きいようです。

これはある意味、新しくて古いOSの機能への回帰ですが、こういった流れはブラウザの他にもあるようです。

最近流行の(?)JavaVMやサーバ仮想化におけるVM(VMWare等)は、アプリケーションからしてみれば単なるOS層の再定義に過ぎません。しかしこの再定義は、JRockitのような一部の試みを除いて、HV、OS、JVMなどの言語VM、と階層が深くなる一方であり、そのオーバーヘッドも無視できなくなったようです。
これは先に述べたPCのブラウザ環境においてもそうですが、特にAndroidのようなハード制約が厳しいモバイル環境においてはなおさらです。

ここにおいて、Googleの解はOSへの回帰です。

Androidのアプリケーション開発環境は独自のJava環境ですが、その実行環境であるVMはJavaVMを用いずにDalvik仮想マシン, http://ja.wikipedia.org/w/index.php?title=Dalvik%E4%BB%AE%E6%83%B3%E3%83%9E%E3%82%B7%E3%83%B3&oldid=25752724 (last visited 5月 11, 2009).を用いています。

Dalvikの特徴の一つは、アプリケーション毎に異なるVM(Linuxのプロセス)を立ち上げることです。
これによって、OSのメモリ管理の恩恵にあずかれます。

OSのメモリ管理の利点の一つは、強力なアクセス保護機構ではないでしょうか。
これにより、バグやそれを悪用したマルウェアからの不正アクセスや以上終了から守られます。これはPCのブラウザ環境において、マルチプロセスをChrome、IE8が採用し、Firefoxが採用を検討している理由と一致します。

OSのメモリ管理の利点のもう一つは、OSのメモリ回収機構を利用できることでしょう。
これは一般にMMUのようなハードウェアのサポートを受けられることを意味しています(ARMの下位モデル等モバイル環境にはMMUがないケースもありますが)。
つまりJVMにおけるGCの厄介な問題をハード・OSに任せられることを意味します。

Dalvikは先に述べたようにアプリケーション毎にVMプロセスを分離しますので、少なくともアプリケーション終了のタイミングではOSのメモリ回収機構を活用できます。

さらには、アプリケーションプロセスのライフサイクル内におけるGCもDalvikでは特徴的です。
DakvikのGCはdlmallocというGoogle再実装libcにおけるメモリ割り当て機構(?大元はCreative Commons License)における領域サイズ毎に分けて管理されたfree関数そのもののようです。

これにより、シンプルかつ強力なメモリ管理が行われる、と言うことでしょうか。
これらこそ正に新しくて古いOS機能への回帰です。

最低解像度更新 (iPhoneキタ)

  長らく本ブログへのアクセスクライアントの最低解像度であった800x600が更新(?)されました。

iPhoneｷﾀ━(ﾟ∀ﾟ)━!!!!!
って感じです。

って、ちょっ、その上の解像度!

早くAndroid来ないかな～