出てしまったようです。「新しいPCが欲しい欲しい病」。
テスト用にQuadコアのPCが欲しいなぁ、と漠然と思っていたんだけど、LenovoのThinkPad Edge E430ってかなり安くないですか？と思ったら、もう止まらなくなってしまってポチってしまいました。
いま使ってるLet's NoteのS9も速くて軽いし気に入っているんだけど、電車通勤しなくなったらここまでのモバイル性能は必要なくなってしまったし、いまならまだそれなりの値段で売りさばけるので、最新IvyBridgeなPCと事実上“交換”できるレベルであることに気づくと、これはもう買い！だな、と（←勝手な屁理屈）。
Core i7-3612QMでUSB3.0もついてなかなかよいが、本当はちょっとだけ不満なところがある。
まずはサイズ。14インチじゃなくて13インチくらいならベストだったんだけどな。ついでに言わせてもらえば、解像度も1600×900くらい欲しかった。
それから、I/FもUSB3.0があれば十分だということなんだろうけど、できればExpressカードスロットが１つは欲しかったな。
重さは軽ければ軽い方がいいけれど、まあこんなもんでしょう。でもLet'sの倍近くあるから最初は重く感じるだろうな。
メモリは８Gあるから十分だけど、今どきHDDはチョット・・・。速攻SSDに交換することになるでしょう。
早くコイコイ。環境を移行したら、Let'sは早めに売ってしまおう。
2012年7月10日火曜日
2012年6月11日月曜日
GCC ARM備忘録
arm-none-eabiなARMをターゲットとしたgccに関する備忘録（Cortex-M3を想定）
- gcc(Cortex-M3)において、関数呼び出し後のSPの位置は必ず8byte境界にアライメントされていなければならないようだ。
これまでは4byteでアライメントされていればよいと思っていた。しかし、可変長引数としてfloatやdoubleを渡そうとすると、その値は８byte境界にアライメントされて関数に引き渡されることが判明した。例えば、int型５つとfloat型１つを関数に渡すと仮定すると、int型の最初の４つはレジスタR0、R1、R2、R3に、５つ目のintはスタックにpushされ、次のfloatはdouble型に変換された上でスタックを１つ（＝１ワード＝４バイト）飛ばして、次の8byte境界となるスタック上に8バイト値（double型に変換されているので）がpushされることが分かった。
そういえば、以前Cortex-M3関係で割り込み動作を調べているとき、ISRは常に８byteアライメントを要求していたような記憶が・・・・。もう、どこで知った情報か忘れてしまったけど。 - 上記のように、可変長引数を持つ関数にfloatを渡そうとすると、doubleに変換された上で8byteにアライメントされてpushされる（レジスタ渡しの場合は[R0,R1］ペアか、[R2,R3]ペアに入る）。ということで、渡すfloat型の引数より前にある引数が奇数個であった場合はレジスタなりスタックにパディングが入る可能性がある点に注意が必要だった。
なお、va_arg()で引数を一つずつ取り出すとき、コンパイラはdouble型を取り出す場合には自動的にパディングの存在を調べてスタックをずらして読み出すので（va_argで読み出す型と順番が間違っていない限り）問題は出ないようになっているようだ。パディングの存在自体はSPの末尾３bitを調べて調整する方法をとっているようだ。なので、もし万一、関数を呼び出すときのスタックが8byteアライメントになっておらずに４バイトずれていたとしたら、上のような可変長引数を持つ関数＋float/double型引数を持つ呼び出し処理においてはおかしな動作になってしまう。 - 余談だけれど、↑のようなことに気がついたのはたまたま使っていたFreeRTOS v4.9.2に不具合があったからだ。
FreeRTOSのCortex-M3用portルーチンでタスクの初期化のところに不備があり、タスク関数が呼び出されたときのスタックポインタは８byteアライメントになっておらず、常に＋４バイトずれていた。そのため、そのタスクから呼び出される関数はすべて＋４バイトずれたスタックポインタを持っていて、通常の関数呼び出しでは問題はでないのだけれど、上のようなケースでは問題になることがあった。
ちなみに、FreeRTOS最新版（v7.1.1）では問題のportルーチンは対策されていた（タスク起動時の初期スタック状態を初期化する際に、余分にパディングワードを挿入するようになっていた）。
ああ、やっぱり組み込みは難しいなぁ。
2012年6月4日月曜日
VisualStudioのデバッグ実行が遅い件
以前から悩んでいた件が解決した。
VisualStudioでデバッグ実行を行うと、実際にアプリが起動して動作するまでにたっぷり30秒以上は待たされる。これではTAT（Turn Around Time）が長くて効率が悪いばかりかイライラしていた。
しかも、Core i5のPCでは30秒以上もかかるのに、Pentium4のPCではスッと起動するから、なおさらイライラして怒りの矛先をVisualStudio2008とMSに向けてしまったものだ。
しかし、原因がようやく分かった！
ブレークポイントの設定が多すぎたんだ！
実際、私のデバッグスタイルでは、
VisualStudioでデバッグ実行を行うと、実際にアプリが起動して動作するまでにたっぷり30秒以上は待たされる。これではTAT（Turn Around Time）が長くて効率が悪いばかりかイライラしていた。
しかも、Core i5のPCでは30秒以上もかかるのに、Pentium4のPCではスッと起動するから、なおさらイライラして怒りの矛先をVisualStudio2008とMSに向けてしまったものだ。
しかし、原因がようやく分かった！
ブレークポイントの設定が多すぎたんだ！
実際、私のデバッグスタイルでは、
- 新しく作った関数の先頭にブレークポイントを張る
- デバッグ実行してブレークに引っかかったら、ステップ実行で関数の動作を確認し、問題がなければ先頭のブレークポイントを削除する。もし、関数内の分岐条件などでスキップされる処理があれば、そのスキップされる箇所に新しいブレークポイント設定する。
- いろいろな条件で動作を繰り返して、すべてのブレークポイントが消えたら、つまりすべてのコードをステップ実行して動作確認できたら
デバッグ完了とりあえずひと安心。
という感じなので、どうしてもブレークポイントが多くなってしまう。
デバッグ実行が遅い件については、suoファイルを削除するという方法がこちらやこちらなどで紹介されているけれど、suoファイルはブレークポイント以外にも「ユーザータスク」に入力した内容なども記録されているので安易に消したくはない。単純にブレークポイント一覧からすべて選択して削除すればいいだけだった。
2012年5月28日月曜日
HV熱は終わったはずだけど・・・
2012年初頭あたりからいま乗っているクルマの車検をにらんで乗り換えを検討していたところに、ちょうどTOYOTAのアクアが出たということで試乗もしてさんざん悩んだんだけれど、結局はこのまま乗り続けることで決着したはず。なのに・・・
これまでは価格が高いし、自分の用途には向いていないということで気にも掛けなかったプリウスPHVが気になり始めている。
基本、長距離通勤（往復100km以上）に使うという点では、ネットでいろいろ言われているように、EV走行できる距離は限られているから長距離ではHVと変わらない、だからPHVは無駄だという意見が見られ、私もそのとおりだと思う。
しかし、HVを試してみたいという思う理由の一つは、エンジン走行では効率の悪い部分（上り坂や追い越し加速）でエンジンの回転数を上げるのではなく、モーターのアシストでカバーするような使い方ができれば燃費が抑えられるのではないか？という期待があるから。でも、アクアを試乗した感じでは緩い上り坂でもエンジンは唸るし、少しきつくなるとブン回さないといけない感じがあった。確かに出だしの加速はモーターのみでいい感じだけど、坂道でのアシストが貧弱なのはちょっといただけない感じだしたのが、アクアを断念した理由の一つ。
その点、プリウスPHVではバッテリーが大きくEV可能距離も長いようだから、上のようにモーターアシストが必要だと思われる部分では思い切ってEVモードに切り替えてその部分をやり過ごし、あとは定則走行＆下り坂＆ブレーキ回生のときに（再）充電してくれればなんと理想的なんだろうと（勝手な）期待をしている。しかし、価格comの口コミ情報から察するに、プリウスPHVは”EV走行してなんぼのもん！””足りなくなったら自宅で充電”というコンセプトが強いようで、回生エネルギーによる充電はするものの、エンジンを使った充電にはあまり積極的な設定ではないそうな（そりゃ、エンジンで充電するより、深夜電力で充電する方が安くなるんだから当然か）。まさに近距離での使用を想定した設定だなあ。
とはいうものの、やはり気になる存在＞プリウスPHV。
というか、実際に自分の乗り方でどうなるかを試してみたい。ディーラーに行けば試乗はさせてもらえるけど、私のような高速を使った超長距離通勤とは全然乗り方が違うのであまり参考にはならないかなぁ。１週間ぐらい連続で試せたらいいのだけれど、まして人気車、そんなこと許してくれるはずもない。あとは、敢えて自腹レンタカー・・・ですか？なんてこれもムリ！
これまでは価格が高いし、自分の用途には向いていないということで気にも掛けなかったプリウスPHVが気になり始めている。
基本、長距離通勤（往復100km以上）に使うという点では、ネットでいろいろ言われているように、EV走行できる距離は限られているから長距離ではHVと変わらない、だからPHVは無駄だという意見が見られ、私もそのとおりだと思う。
しかし、HVを試してみたいという思う理由の一つは、エンジン走行では効率の悪い部分（上り坂や追い越し加速）でエンジンの回転数を上げるのではなく、モーターのアシストでカバーするような使い方ができれば燃費が抑えられるのではないか？という期待があるから。でも、アクアを試乗した感じでは緩い上り坂でもエンジンは唸るし、少しきつくなるとブン回さないといけない感じがあった。確かに出だしの加速はモーターのみでいい感じだけど、坂道でのアシストが貧弱なのはちょっといただけない感じだしたのが、アクアを断念した理由の一つ。
その点、プリウスPHVではバッテリーが大きくEV可能距離も長いようだから、上のようにモーターアシストが必要だと思われる部分では思い切ってEVモードに切り替えてその部分をやり過ごし、あとは定則走行＆下り坂＆ブレーキ回生のときに（再）充電してくれればなんと理想的なんだろうと（勝手な）期待をしている。しかし、価格comの口コミ情報から察するに、プリウスPHVは”EV走行してなんぼのもん！””足りなくなったら自宅で充電”というコンセプトが強いようで、回生エネルギーによる充電はするものの、エンジンを使った充電にはあまり積極的な設定ではないそうな（そりゃ、エンジンで充電するより、深夜電力で充電する方が安くなるんだから当然か）。まさに近距離での使用を想定した設定だなあ。
とはいうものの、やはり気になる存在＞プリウスPHV。
というか、実際に自分の乗り方でどうなるかを試してみたい。ディーラーに行けば試乗はさせてもらえるけど、私のような高速を使った超長距離通勤とは全然乗り方が違うのであまり参考にはならないかなぁ。１週間ぐらい連続で試せたらいいのだけれど、まして人気車、そんなこと許してくれるはずもない。あとは、敢えて自腹レンタカー・・・ですか？なんてこれもムリ！
2012年5月25日金曜日
TortoiseSVNのビックリな機能
Subversionのリポジトリに入れておいたexcelのファイルを更新したので、何気にdiffをかけてみた。
おそらくバイナリでの比較になるんだろうと思っていたら・・・。
なんと、
新旧二つの.xlsファイルをEXCELで開いて並べて表示した上に、違いのあるセルが赤く表示されているっ！
ではないですか。
まさかそんなことまでやってくれるなんて・・・。やっぱり、TortoiseSVNにして正解ですね。
おそらくバイナリでの比較になるんだろうと思っていたら・・・。
なんと、
新旧二つの.xlsファイルをEXCELで開いて並べて表示した上に、違いのあるセルが赤く表示されているっ！
ではないですか。
まさかそんなことまでやってくれるなんて・・・。やっぱり、TortoiseSVNにして正解ですね。
2012年3月9日金曜日
"Terra Nova"強制終了？
大物監督＆プロデューサーとリアルな映像を武器に鳴り物入りで始まった海外ドラマ"Terra Nova"が打ち切りになるようだ。
う～ん、確かにこれまで見ていた感想としては「ちょっと間延びした感じ」というところ。
基本的な時代設定・背景設定はいいと思うし、海外ドラマではよくあるいろいろなナゾ/秘密を仕掛けているあたりは、まだ始まったばかりだしこれからの展開に期待してもよいのかな？という感じで見続けていたけど、各回のストーリー自体はなんというか幼稚かつ下世話な気がしていた。
例えば「空を覆う闇」では、結局は翼竜をフェロモンで他の場所に誘導するというチンケな結末だし、最後にジムたちが言った「色気づいた翼竜たちの声といったら聞いちゃいられない・・・」みたいなしょうもない一言のせいで更に台無しに。
先週の記憶をなくす病気の回でも、風邪を引いたジムが病気を発症しないからと言って奥さんの病気を治すのにキスをしたらもう次のシーンでは直ってる、なんていう単純な展開もどうしたものかと。
どうしよう。打ち切りと分かっていて続きを見るべきか止めるべきか。「打ち切り」ということでいきなり話がブチッと終わるのなら消化不良になるだけなのでもう止めるけど、話の結末を急いでとりあえずの終わりがあるならもうちょっと見続けてみようか・・・
う～ん、確かにこれまで見ていた感想としては「ちょっと間延びした感じ」というところ。
基本的な時代設定・背景設定はいいと思うし、海外ドラマではよくあるいろいろなナゾ/秘密を仕掛けているあたりは、まだ始まったばかりだしこれからの展開に期待してもよいのかな？という感じで見続けていたけど、各回のストーリー自体はなんというか幼稚かつ下世話な気がしていた。
例えば「空を覆う闇」では、結局は翼竜をフェロモンで他の場所に誘導するというチンケな結末だし、最後にジムたちが言った「色気づいた翼竜たちの声といったら聞いちゃいられない・・・」みたいなしょうもない一言のせいで更に台無しに。
先週の記憶をなくす病気の回でも、風邪を引いたジムが病気を発症しないからと言って奥さんの病気を治すのにキスをしたらもう次のシーンでは直ってる、なんていう単純な展開もどうしたものかと。
どうしよう。打ち切りと分かっていて続きを見るべきか止めるべきか。「打ち切り」ということでいきなり話がブチッと終わるのなら消化不良になるだけなのでもう止めるけど、話の結末を急いでとりあえずの終わりがあるならもうちょっと見続けてみようか・・・
2012年3月6日火曜日
WinUSB_ControlTransfer()が動かない理由
結局は自分のしょーもないポカミスなんだけれど、ある掲示板で同じようなことを質問していた人がいたのと、ちょっと気づきにくいミスなので、備忘録の意味も含めて書き留めておく。
WinUSBを使ってUSB通信を行うとき、ベンダspecificなリクエストを送信するコントロール転送を行うのに、
SendVendorSpecificRequest_in()とSendVendorSpecificRequest_out()と名前の関数を用意してこれを呼び出すようにしていた。
問題の始まりはコントロールOUT転送を行うSendVendorSpecificRequest_out()関数の引数の型だった。
これは送信を行う関数になるので、DATAステージのデータをconst void* なポインタで渡すようプロトタイプ宣言していた。つまり、
bool SendVendorSpecificRequest_out(
...,
const void* dat, // DATAステージで出力するconstなデータ
int len, // DATAステージで出力するデータ長さ
...);
という感じ（他の引数は省略）。
こういう関数を用意すると、この関数の呼び出し側では
static const char text_data[] = "hogehoge";
SendVendorSpecificRequest_out(
...,
text_data,
strlen(text_data),
...);
みたいな呼び出しができる訳だけれど、これが間違い。
それはこの関数の中身の実装がこうなっていたから。
BOOL SendVendorSpecificRequest_out(
...,
const void* dat,
int len, ...)
{
WINUSB_SETUP_PACKET setup_pkt;
setup_pkt.RequestType = 0x40 or 0xC0;
setup_pkt.Request = リクエストコード;
setup_pkt.Value = wValueの値;
setup_pkt.Index = wIndexの値;
setup_pkt.Length = len;
ULONG sent;
return WinUsb_ControlTransfer(
WinUSBハンドル,
setup_pkt,
(PUCHAR)dat,
len,
&sent,
NULL);
}
WinUsb_ControlTransfer()の第三引数を無理矢理PUCHARにキャストしているところが間違い。
コントロールOUT転送だからWinUsb_ControlTransfer()関数は第三引数で示されるポインタを使ってreadしか行わないだろう（＝read属性のみのメモリを渡してもキャストしておけば大丈夫）と思っていたら、内部の実装はそうではないようだ。コントロールOUT転送でもここで渡すポインタは必ずread-write可能なメモリのポインタを渡さなければならない。
という訳で回避策は、WinUsb_ControlTransfer()関数に渡す前に別のread-write可能なバッファにコピーしてから呼び出すか、そもそもSendVendorSpecificRequest_out()関数のプロトタイプからconst修飾子自体を取ってしまって、constなポインタは渡せないようにするか・・・。
WinUSBを使ってUSB通信を行うとき、ベンダspecificなリクエストを送信するコントロール転送を行うのに、
SendVendorSpecificRequest_in()とSendVendorSpecificRequest_out()と名前の関数を用意してこれを呼び出すようにしていた。
問題の始まりはコントロールOUT転送を行うSendVendorSpecificRequest_out()関数の引数の型だった。
これは送信を行う関数になるので、DATAステージのデータをconst void* なポインタで渡すようプロトタイプ宣言していた。つまり、
bool SendVendorSpecificRequest_out(
...,
const void* dat, // DATAステージで出力するconstなデータ
int len, // DATAステージで出力するデータ長さ
...);
という感じ（他の引数は省略）。
こういう関数を用意すると、この関数の呼び出し側では
static const char text_data[] = "hogehoge";
SendVendorSpecificRequest_out(
...,
text_data,
strlen(text_data),
...);
みたいな呼び出しができる訳だけれど、これが間違い。
それはこの関数の中身の実装がこうなっていたから。
BOOL SendVendorSpecificRequest_out(
...,
const void* dat,
int len, ...)
{
WINUSB_SETUP_PACKET setup_pkt;
setup_pkt.RequestType = 0x40 or 0xC0;
setup_pkt.Request = リクエストコード;
setup_pkt.Value = wValueの値;
setup_pkt.Index = wIndexの値;
setup_pkt.Length = len;
ULONG sent;
return WinUsb_ControlTransfer(
WinUSBハンドル,
setup_pkt,
(PUCHAR)dat,
len,
&sent,
NULL);
}
WinUsb_ControlTransfer()の第三引数を無理矢理PUCHARにキャストしているところが間違い。
コントロールOUT転送だからWinUsb_ControlTransfer()関数は第三引数で示されるポインタを使ってreadしか行わないだろう（＝read属性のみのメモリを渡してもキャストしておけば大丈夫）と思っていたら、内部の実装はそうではないようだ。コントロールOUT転送でもここで渡すポインタは必ずread-write可能なメモリのポインタを渡さなければならない。
という訳で回避策は、WinUsb_ControlTransfer()関数に渡す前に別のread-write可能なバッファにコピーしてから呼び出すか、そもそもSendVendorSpecificRequest_out()関数のプロトタイプからconst修飾子自体を取ってしまって、constなポインタは渡せないようにするか・・・。
Intel SSD Toolbox その後・・・
以前の書き込みでIntel SSD ToolboxがX25-Mを認識しないということを書いたあと、その後もう諦めて放置していた。
今日何となくIntelのHPを見に行ったら、新しいToolboxがダウンロードできるようになっていたのでダメ元であまり期待せずにダウンロード＆インストールしてみたらビックリ！UIが大幅に変わっていた。
あまりにも変わり過ぎで直ぐに気づかなかったけれどよく見るとX25-Mが２台とも認識されているではないか！
というわけで、optimizeもできるようになったし、SMARTも詳しく見られるようになったので満足。
ってか、今まで見えなかったのはやっぱりバグなんでしょうかね。何回も再インストールして時間を使っちゃったんですけどぉ。
今日何となくIntelのHPを見に行ったら、新しいToolboxがダウンロードできるようになっていたので
あまりにも変わり過ぎで直ぐに気づかなかったけれどよく見るとX25-Mが２台とも認識されているではないか！
というわけで、optimizeもできるようになったし、SMARTも詳しく見られるようになったので満足。
ってか、今まで見えなかったのはやっぱりバグなんでしょうかね。何回も再インストールして時間を使っちゃったんですけどぉ。
まさにオカルト・・・
おもしろい記事を見つけた。
http://magazine.kakaku.com/mag/kaden/id=700/
PCに接続して再生するタイプのオーディオ機器について、その音質について何やら理屈っぽいことを書いてありますが、 その中で「PCオーディオへの接続方法はUSB接続だと、演奏の細やかなニュアンスや空間的な拡がりが損なわれる！」とされていて、その原因が
「USB接続ではエラー訂正が行われないからだ！」
と結論付けられている。
何ともこんな理屈がまともにまかり通りと思って書いているんでしょうかね？
「USBでエラー訂正が行われない」というのは、おそらくアイソクロナス転送においてCRCエラーが発生したときにパケットがそのまま捨てられる、バルク転送のように再送はされない、ということを指しているようだけども、
そもそもUSBがもうかなり枯れた技術（SuperSpeedは除く）だし、これまでUSBアナライザを使ってUSB機器を 何種類も開発してきましたけど、USB接続でCRCエラーが発生することはそんなにありませんよ。
まあ、よっぽどひどいケーブルを使うか、延長ケーブルを入れたりしたら起きないわけではありませんが、 普通に売ってるケーブルを使えばエラーが発生する頻度なんて数千万トランザクションに１回あるかないか？くらいで、たかだか数分の曲を聴いている間に１回起きるか起きないかのエラーで「演奏のニュアンス」や「音の拡がり」が損なわれるという理屈はまったくもっておかしな話だ。
せめて、定常的に起こる（１秒間に数回～数十回も起こる）細かいエラーの頻発で音質に微妙に影響している、という論理なら、まだ理解もできるのだが、今度は逆にそんなにエラーが頻発していたらUSB通信自体 崩壊してるでしょ？って話。
それに、USBで送られているデータは通常PCMなんだよね。 仮にPCMストリーム上でランダムに１bitが化けるとしたら、そのビットがPCMデータのMSB側かLSB側かで 出てくる影響は全く違うでしょう。LSB側のデータ化けなら微妙な音質の劣化として聞こえるでしょうが、MSB側が化ける場合も想定しないといけない。
もしMSB側のデータ化けなら、それこそ「バリッ！！」と大音響でノイズが乗るのは目に見えている（いや、耳に聞こえてる。笑）。その点からしても先の記事の理屈は変だ。
まさに、この記事自体が「オカルト」。
実際には、アイソクロナス転送でビット化けが起こったとしたらCRCチェックで引っかかるからそのパケット自体が捨てられる。つまり、本来送られるはずのPCMデータの一部がごっそり抜けて無くなることになる。そうなると、やはり人間が感知できる影響というのは「バリッ」という大きなノイズになるはず。
まあ、USB DAC側で何らかの対策がしてあるとしたら、そういう大きいノイズを避けるために瞬間的にミュートされるかもしれないけど、いずれにしても音の拡がりがどうのこうのいうレベルではない。
「１パケットが失われる」＝「1ms分のPCMデータが失われる」＝「約44サンプル分のPCMデータが失われる（44.1KHz再生の場合）」ということなので、 どんなに優秀なUSB DACでもその失われたPCMデータを補完できるわけもなく、ノイズ発生は避けられまい。
ほんとに「オカルト」な話だな～。
http://magazine.kakaku.com/mag/kaden/id=700/
PCに接続して再生するタイプのオーディオ機器について、その音質について何やら理屈っぽいことを書いてありますが、 その中で「PCオーディオへの接続方法はUSB接続だと、演奏の細やかなニュアンスや空間的な拡がりが損なわれる！」とされていて、その原因が
「USB接続ではエラー訂正が行われないからだ！」
と結論付けられている。
何ともこんな理屈がまともにまかり通りと思って書いているんでしょうかね？
「USBでエラー訂正が行われない」というのは、おそらくアイソクロナス転送においてCRCエラーが発生したときにパケットがそのまま捨てられる、バルク転送のように再送はされない、ということを指しているようだけども、
そもそもUSBがもうかなり枯れた技術（SuperSpeedは除く）だし、これまでUSBアナライザを使ってUSB機器を 何種類も開発してきましたけど、USB接続でCRCエラーが発生することはそんなにありませんよ。
まあ、よっぽどひどいケーブルを使うか、延長ケーブルを入れたりしたら起きないわけではありませんが、 普通に売ってるケーブルを使えばエラーが発生する頻度なんて数千万トランザクションに１回あるかないか？くらいで、たかだか数分の曲を聴いている間に１回起きるか起きないかのエラーで「演奏のニュアンス」や「音の拡がり」が損なわれるという理屈はまったくもっておかしな話だ。
せめて、定常的に起こる（１秒間に数回～数十回も起こる）細かいエラーの頻発で音質に微妙に影響している、という論理なら、まだ理解もできるのだが、今度は逆にそんなにエラーが頻発していたらUSB通信自体 崩壊してるでしょ？って話。
それに、USBで送られているデータは通常PCMなんだよね。 仮にPCMストリーム上でランダムに１bitが化けるとしたら、そのビットがPCMデータのMSB側かLSB側かで 出てくる影響は全く違うでしょう。LSB側のデータ化けなら微妙な音質の劣化として聞こえるでしょうが、MSB側が化ける場合も想定しないといけない。
もしMSB側のデータ化けなら、それこそ「バリッ！！」と大音響でノイズが乗るのは目に見えている（いや、耳に聞こえてる。笑）。その点からしても先の記事の理屈は変だ。
まさに、この記事自体が「オカルト」。
実際には、アイソクロナス転送でビット化けが起こったとしたらCRCチェックで引っかかるからそのパケット自体が捨てられる。つまり、本来送られるはずのPCMデータの一部がごっそり抜けて無くなることになる。そうなると、やはり人間が感知できる影響というのは「バリッ」という大きなノイズになるはず。
まあ、USB DAC側で何らかの対策がしてあるとしたら、そういう大きいノイズを避けるために瞬間的にミュートされるかもしれないけど、いずれにしても音の拡がりがどうのこうのいうレベルではない。
「１パケットが失われる」＝「1ms分のPCMデータが失われる」＝「約44サンプル分のPCMデータが失われる（44.1KHz再生の場合）」ということなので、 どんなに優秀なUSB DACでもその失われたPCMデータを補完できるわけもなく、ノイズ発生は避けられまい。
ほんとに「オカルト」な話だな～。
2012年1月31日火曜日
”アクア”考...再び
発売前から注目していたトヨタのアクア。新しいもの好き＆ハイテク好きとしては欲しいところだけど、本気で乗り換えることまでは考えていなかったのだが・・・
日曜にふら～っとディーラーに立ち寄ってみた。たまたま通りがかっただけなんだけど「試乗車あります」とあったので、ちょっと乗ってみるだけのつもりで。
まず、一番気になっていたのは「視界」。kakaku.comのレビューか何かで「176cmの身長だと信号が見にくい」とか書いてあったので、それよりも+10cm以上も高い私でまともに視界が確保できるのかと。
結果・・・、問題なしです。別にルーフが目の真ん前に降りてきているわけではありませんでした。今乗っているムラーノとそんなに変わらない感じ。もちろん、アイポイントの高さは全く違いますが。その昔のexivとかEDとかの方がよっぽどヒドい。信号を見るのに前屈みで覗き込む必要がありましたから。
外観の第一印象は、小さっ！。というか、低っ！。昨今はコンパクトカーといってもvitzやfitも結構背が高いからちょっとビックリしました。軽四より低い！その分、座面も低いわけで、その点でもムラーノとのギャップは大きい。でも、デザインそのものはけっこう好きな方かな。試乗した感じでは足回りは固めでしっかりしていそうなので、（ただの飾りだと知りつつも）アルミホイール＋スポイラーをつけたくなった。まったく私らしくない発想・・・。
内装は、評判通りショボいかも。これまではアナログメータタイプのインパネしか見ていないからか、それとも知り合いのLS600hのインパネの残像が脳裏に残っているからか。シート素材はファブリックでそこそこ。というか、分相応という感じ。ステアリングホイールのスイッチはゴチャゴチャしすぎかな。でも、基本「コンパクトカー」クラスなのでこんなもんという割り切りができないレベルではない。ただ、車両＋OPなどで200万越えのクルマだと思うと、残念な気もする。が、（初代）ムラーノの内装がそんなにリッチ感漂うかというとそうでもない。まあ、レザーシートくらいはアドバンテージあるけど、そのほかは時代が進んでる分アクアの方が上とも言えなくもない（ナビとメーター周りは）。
そして、走り。初HVなのでおそるおそるの試乗でした。なるほど、止まると無音・無振動、出だしもスーっと出る感じはフィーリングに合うなぁ。ムラーノのように重い車体をぐいぐい進ませる感じなく、ほんとに車体の軽さを実感する。でもそれは「速い」を意味している訳じゃない。
残念なのは、緩い登り坂ではエンジン音がちょっと唸り始めるところ。せっかくのHVなのだから、緩い坂くらいではエンジンはそのままでモータアシストで足りないトルクを補って欲しい。実際、加速時以外でもっとも燃料を消費するには登り坂なんだから。でも、回生ブレーキはよく利いている感じでした。
最後に見積もりももらいましたが、OP最低限にしても220万を超えてきました。人気車で値引きも渋いからそんなものか？でもOP設定が多すぎとは思う。
納期は意外とかからないかも知れないと言ってました。ネットでは半年待ちとか言ってますが、そのディーラではなんとか４ヶ月くらいで入れることができそうだと。
総評としても微妙ですね。
まず価格ですけど乗り出しで180万くらいになってくれると、内装のマイナスイメージを引いててもグッと「買い」に傾くのですが、現在220万くらいですからね～。この差は埋めがたい。
それから、パワーの件。コンパクトカーとしては、あるいは実用上十分であることは分かったんですが、やはりムラーノほどパワーに余裕が感じられない。特に坂道や追い越し。ムラーノと比べること自体間違っているけど、いざ乗り換えを考えると「それでガマンできるのか？」と自問自答してしまう。
室内の広さもちょっと考えてしまう。通勤用として使うことがほとんどだから私一人乗るくらいには十分なんだけど、家族でちょっと遠出する可能性を考えるとやはりアクアでは小さすぎるのでは？後席については特に。ここでもやっぱり脳内ではムラーノと比較している自分がいる。
最後にアイポイント、つまり目線の高さ。アクアでは結構目線が低くなるので、どうしても他車からの威圧感を感じてしまう。というか、ムラーノのように上から見下ろす優越感がなくなるなぁ、というべき。まだそういう試乗はさせてもらっていないが、特に高速道での追い越し（追い越され）のときは隣りのトレーラーが怖くなるのかな～、とか。見方を変えれば、目線が低いとスピード感が高まって楽しい（？）ということもあり得る。
う～ん、ここまで気になる存在でありながら、なぜ乗り換えに躊躇するのか？をまとめてみたい。この点が整理できれば、気持ちも（買い換えるか、乗り続けるか、どちらにしろ）決まるだろう（たぶん）。
日曜にふら～っとディーラーに立ち寄ってみた。たまたま通りがかっただけなんだけど「試乗車あります」とあったので、ちょっと乗ってみるだけのつもりで。
まず、一番気になっていたのは「視界」。kakaku.comのレビューか何かで「176cmの身長だと信号が見にくい」とか書いてあったので、それよりも+10cm以上も高い私でまともに視界が確保できるのかと。
結果・・・、問題なしです。別にルーフが目の真ん前に降りてきているわけではありませんでした。今乗っているムラーノとそんなに変わらない感じ。もちろん、アイポイントの高さは全く違いますが。その昔のexivとかEDとかの方がよっぽどヒドい。信号を見るのに前屈みで覗き込む必要がありましたから。
外観の第一印象は、小さっ！。というか、低っ！。昨今はコンパクトカーといってもvitzやfitも結構背が高いからちょっとビックリしました。軽四より低い！その分、座面も低いわけで、その点でもムラーノとのギャップは大きい。でも、デザインそのものはけっこう好きな方かな。試乗した感じでは足回りは固めでしっかりしていそうなので、（ただの飾りだと知りつつも）アルミホイール＋スポイラーをつけたくなった。まったく私らしくない発想・・・。
内装は、評判通りショボいかも。これまではアナログメータタイプのインパネしか見ていないからか、それとも知り合いのLS600hのインパネの残像が脳裏に残っているからか。シート素材はファブリックでそこそこ。というか、分相応という感じ。ステアリングホイールのスイッチはゴチャゴチャしすぎかな。でも、基本「コンパクトカー」クラスなのでこんなもんという割り切りができないレベルではない。ただ、車両＋OPなどで200万越えのクルマだと思うと、残念な気もする。が、（初代）ムラーノの内装がそんなにリッチ感漂うかというとそうでもない。まあ、レザーシートくらいはアドバンテージあるけど、そのほかは時代が進んでる分アクアの方が上とも言えなくもない（ナビとメーター周りは）。
そして、走り。初HVなのでおそるおそるの試乗でした。なるほど、止まると無音・無振動、出だしもスーっと出る感じはフィーリングに合うなぁ。ムラーノのように重い車体をぐいぐい進ませる感じなく、ほんとに車体の軽さを実感する。でもそれは「速い」を意味している訳じゃない。
残念なのは、緩い登り坂ではエンジン音がちょっと唸り始めるところ。せっかくのHVなのだから、緩い坂くらいではエンジンはそのままでモータアシストで足りないトルクを補って欲しい。実際、加速時以外でもっとも燃料を消費するには登り坂なんだから。でも、回生ブレーキはよく利いている感じでした。
最後に見積もりももらいましたが、OP最低限にしても220万を超えてきました。人気車で値引きも渋いからそんなものか？でもOP設定が多すぎとは思う。
納期は意外とかからないかも知れないと言ってました。ネットでは半年待ちとか言ってますが、そのディーラではなんとか４ヶ月くらいで入れることができそうだと。
総評としても微妙ですね。
まず価格ですけど乗り出しで180万くらいになってくれると、内装のマイナスイメージを引いててもグッと「買い」に傾くのですが、現在220万くらいですからね～。この差は埋めがたい。
それから、パワーの件。コンパクトカーとしては、あるいは実用上十分であることは分かったんですが、やはりムラーノほどパワーに余裕が感じられない。特に坂道や追い越し。ムラーノと比べること自体間違っているけど、いざ乗り換えを考えると「それでガマンできるのか？」と自問自答してしまう。
室内の広さもちょっと考えてしまう。通勤用として使うことがほとんどだから私一人乗るくらいには十分なんだけど、家族でちょっと遠出する可能性を考えるとやはりアクアでは小さすぎるのでは？後席については特に。ここでもやっぱり脳内ではムラーノと比較している自分がいる。
最後にアイポイント、つまり目線の高さ。アクアでは結構目線が低くなるので、どうしても他車からの威圧感を感じてしまう。というか、ムラーノのように上から見下ろす優越感がなくなるなぁ、というべき。まだそういう試乗はさせてもらっていないが、特に高速道での追い越し（追い越され）のときは隣りのトレーラーが怖くなるのかな～、とか。見方を変えれば、目線が低いとスピード感が高まって楽しい（？）ということもあり得る。
う～ん、ここまで気になる存在でありながら、なぜ乗り換えに躊躇するのか？をまとめてみたい。この点が整理できれば、気持ちも（買い換えるか、乗り続けるか、どちらにしろ）決まるだろう（たぶん）。
- ムラーノにはまだ４年しか乗っていない。当初は「乗り潰すぞ！」と意気込んでいたのに何故？というプチ罪悪感。
- デザインくらいしか評価されないムラーノだけど、やはりそれなりのステータスを持ったクルマ。そこから内装ショボいなどと評価の低く、クルマとしての格が２周り・３周りも違うコンパクトカーに乗り換えて満足できるのか？という不安。
- 家族で遠出するときの不安。ムラーノなら大人４人乗っても全然窮屈じゃないけど、もしアクアで遠出した場合、異常に疲れてしまうのではないか？
やはり、現車であるムラーノとの比較論になってしまう。比較するレベルじゃないのは分かっているのだけれど。ムラーノに対する感情的な思い入れをどう吹っ切るか？と、アクアの物理的制約（室内の居住性など）にどう折り合いをつけて「通勤車」と割り切れるか？がポイントだな。
登録:
投稿 (Atom)