コグノスケ

信号は賢くなかった

先日（2016年6月5日の日記参照）の続きです。夜間の信号は眩しく感じないから、昼間と夜間では信号は明るさが違うのではないか？という仮説を立てました。

今回はその検証のため、夜間の信号を撮ってきました。信号は高い所に設置されているので、どう控えめに見ても道端で夜空を撮る不審者にしか見えませんが、気にせず強く生きたいと思います。

比較のため、昼間の信号の様子を再掲します。

昼間のLED式、歩行者用信号（1/33倍速撮影、1000fps）

次に夜間の信号の様子です。条件を揃えるため、昼間撮った信号と同じ信号を撮っています。

夜間のLED式、歩行者用信号（1/33倍速撮影、1000fps）

どう見ても、昼も夜も同じ間隔で点滅していますね。仮説は残念ながらハズレました。

試しに隣の交差点の信号も撮りましたが、同じ間隔で点滅していました。この明るさは全国共通なのかな？？

高速度カメラとLED掲示板

私の持っているデジカメ（CASIO EX-ZR1300）には、解像度と明るさを犠牲にしてフレームレートを上げるユニークな動画撮影機能が搭載されています。FullHD 30fpsの撮影はもちろん可能ですが、120fps（640x480）、240fps（512x384）、480fps（224x160）、最高で1000fps（224x64）まで撮影が可能です。

フレームレート低め（120〜240fpsくらい）でも、普段目に出来ない面白い画が撮れます。例えば、阪急高槻駅のLED構内案内板を撮ってみます。

阪急高槻駅、LED構内案内板（1/8倍速撮影、240fps）

白のLEDが上から下に向かって再描画されている様子が見えると思います。他のオレンジ、緑の部分はフリッカが見えないので、白い部分だけ描画が遅いということになります。面白い設計ですよね。

白いLEDだから描画が遅いかというと、そんなことはありません。阪急の列車（1000系？）のLED行き先案内表示を240fpsで撮ってもフリッカは見えません。

阪急電車、LED行き先案内（1/8倍速撮影、240fps）

若干モヤモヤして見えることからもわかりますが、常時点灯しているわけではありません。240fpsだと遅すぎて再描画の様子が映らないだけです。論より証拠で、次に1000fpsで撮ってみます。

阪急電車、LED行き先案内（1/33倍速撮影、1000fps）

すさまじい勢いで上から下に再描画が掛かっています。この動画をコマ送りで見ると5コマ程度で全体を書き終えているように見えます。カメラの性能を信じるなら、案内板のフレームレートは約200fpsです。何故だかわかりませんが、べらぼうに速いですね。

他にも高速に再描画しているものはあります。阪急富田駅のLED案内板を1000fpsで撮ってみます。

阪急富田駅、LED案内板（1/33倍速撮影、1000fps）

これは7〜8コマで書き終えているようなので、約150fpsくらいでしょうか。これも人の目にはまず感知できないでしょう。

さきほどからLEDばかりですが、同じLEDでも変わり種のLED式の歩行者用信号を1000fpsで撮ってみました。

LED式、歩行者用信号（1/33倍速撮影、1000fps）

高速にON -> OFFされていることがわかります。信号に再描画は要らないので、明るさ調整のためのPWM制御でしょう。お昼でも信号は全力で点灯しているわけではないのが意外でした。

で、ここからは推測ですが、運転していて「信号がまぶしい！」と思ったことはないので、昼と夕方と夜で、信号の明るさを変えていると思われます。

すなわち、同じLED式信号機でも、時間を変えて撮影すれば、今回撮った動画とは違う間隔でON -> OFFされている様子が撮れるのではないか？と考えています。

心配事があるとしたら、夜は恐らく光量不足で撮影不可能だし、何度も撮りに行くのが激しく面倒くさいことですね…。

In to Outのレイテンシ - Linux編

目次: ALSA

昨日（2016年5月29日の日記参照）の続き。Linuxでも測ってみました。

Windowsで測ったときと同様に、オシロの目盛が振り切れない程度に音量を調節しました。Linuxはループバック再生のやり方は特にありませんので、下記のようにarecordとaplayをパイプで繋いでみました。

arecord -D plughw:1 -f dat -B 10000 | aplay -D plughw:1 -f dat -B 10000

バッファはデフォルトだと500ms近かったので、arecord側もaplay側も10msに設定しています。パイプの分もバッファがあるので、最大で20ms + α 程度のレイテンシになると思われます。

まずCreativeのSound Blaster Play! を測ってみました。

In to Outのレイテンシ(Linux) - Sound Blaster Play!

おお、結構良いじゃないか。と思ったのですが、なぜか入力より出力が遅いようで、しばらく放っておくとレイテンシが変わってしまいます。

In to Outのレイテンシ(Linux) - Sound Blaster Play! その2

同じ機器なのに、録音と再生の速度が違うのは妙です。録音側をplugで変換しているからでしょうか。良く分からんな…。

In to Outのレイテンシ - Windows編

目次: ALSA

先日（2016年5月22日の日記参照）の続き。オシロスコープを引っ張り出してきて、測ってみました。

Windows側でサウンドデバイスの設定は特にせず、オシロの目盛が振り切れない程度に音量を調節したのと、録音デバイス側の「このデバイスを聴く」のチェックをつけ（＝ループバック再生）るだけに留めました。

下記のように接続して、オシロスコープのCh1に単発トリガを掛けて、どれだけ遅れて音が鳴るかを調べました。スプリッタと格好良く書いていますが、単にステレオで出力して、赤白ケーブルの赤と白に分けているだけです…。

In to Outのレイテンシ測定

ちょっとした工夫として、入力信号の周波数を低め（100Hz）にして、波長の整数倍（今回は0.05s、つまり5波形分）のパルスにしています。

周波数を低くするのは、オシロの時間軸を長めに取ったときでもグラフが潰れず波形をカウントしやすいためです。

パルスを波長の整数倍にするのは、入力と出力の一致を見るためです。たまに無音状態から出音すると先頭の音が欠けてしまう（ポップノイズ防止のため、ボリュームにフェードを掛けて出す）デバイスがあります。その手のデバイスに当たると、フェードの分だけ遅れているように見えるため、不当に悪く評価してしまうからです。

最初はCreativeのSound Blaster X-Fi Go! Pro（約4,000円）です。

In to Outのレイテンシ - Creative SoundBlaster Go! Pro

約100msですね。

次は、同じくCreativeのSound Blaster Play（約1,000円）です。

In to Outのレイテンシ - Creative SoundBlaster Play!

わずかに早い、約90msです。

最後はONKYO SE-U33GXV2（約13,000円）です。このデバイスは内部で直結されているらしく「このデバイスを聴く」をチェックしなくてもループバック再生されていました。

In to Outのレイテンシ - ONKYO SE-U33GXV2

これは0msと言っても過言では無いです。あまりにも同時に鳴ってしまい、グラフが重なって見えないので、グラフを上下にずらしています。

しかしWindowsの設定なんて完全に無視してくれるので、ループバック再生できているとは言えないような。。。

In to Outのレイテンシ - ONKYO SE-U33GXV2「このデバイスを聴く」

ちなみに「このデバイスを聴く」にチェックを入れると、同じ音が二回鳴ってしまいます…。レイテンシはやはり100msくらいです。Windowsはこんなもんなのかなあ？