今はJavaScriptでベースバンドをリアルタイムに処理する時代のようです(正確に言えばIFに落としてるからベースバンドじゃないけど)。
以前、 RTL-SDRでFM放送を聴く という記事を書きましたが、恐ろしい物が出ていることに今更気づきました。なんとJavaScriptのみで、RTL-SDRからベースバンドを取得しFM復調して、FM放送を再生するというChrome Appが出ているのです。
Chrome ウェブストア - Radio Receiver
https:/
実行するにはお馴染みRTL2832U+R820Tの構成の地デジドングルが必要です。
ちょっと前までは1000円以下で売っていた気がしますが、値上がりしてるのかな。
amazonで750円で売っているDS-DT305WHもRTL2832Uを載せているのでRTL-SDRに使えるようです。
ソースはこちら。
https:/
Naclのコードも何故かありますが、
https:/
これは使っておりません。単にJSで書いたものをC++0xで書きなおしたもののようです。
コアとなるJS版とC++版を見比べてみましょう。
https:/
https:/
素直に一対一に対応していますが、基本的にJSの方が先行して開発されていて、ときたまC++版がそれに追随する形でアップデートされるようです。何のためにC++版をメンテしているのか分かりませんが、これはこれで有り難い！
Add latest FM audio formula to C++ code.
https:/
FMのステレオにも対応していますし、自動周波数補正までできますし、かなり高機能です。rtl_sdrプロジェクトのrtl_fmなんて未だにステレオに対応していないことを考えたら凄いことです。あとソースコードが綺麗なのも素晴らしいです。さすがグーグル様。
ただ、音質はSDR#の方が良いですね。SDR#は標準で2.4MS/Sなのもあるかもしれませんが、radioreceiverと同じ1.024MS/Sにしてもだいぶ差がある気がします。おそらくフィルターの設定なんでしょうね。
https:/
によると75K*0.8なので結構狭くて、これだとSDR#でも同様に厳しくなります。うちだと80Kくらいは欲しいです。ただうちのアンテナがショボイので、アンテナが良ければ問題ないのかな。よく分かりません。
さて、確かにChrome Appならusb deviceも叩けるし、当然Web Audioも使えますし、動くのは分かるけど、重いんでしょう？そう思うわけです。ところが、軽いんです。Core i5 650@3.2GHzでCPU負荷は9-10%程度です。C#で書かれたSDR#で同等のサンプリング数(1.024MS/s)にすると9-14%なので、むしろ速いです。もっともSDR#の方はFFT Displayがあったり、他にも補正が入っているので仕方ない面はありますが。いずれにせよ、ベースバンドの処理もJavaScriptで行けるじゃん、ということで、そのうちSDRソフトもChrome Appで登場しそうですね。
とはいえCで普通にやればJSの4倍程度は速くなるのが通例(?)なので、これもベンチを取ってみると面白いかも。ただ、これだけJSでも低負荷で動いてしまえば、Raspiで動かそうとかでもしない限り、JSでいいじゃん、となりそうですね。
以前、簡単な数値計算でv8がどのような機械語を吐くのか調べてみたことがあったのですが( v8の最適化をシンセの観点から調べる )、最近だとどう最適化されているのか気になるところ。
ということで色々気になる点が続出ですが、平日なので寝ます。