ラベル Chrome の投稿を表示しています。 すべての投稿を表示
ラベル Chrome の投稿を表示しています。 すべての投稿を表示

2015年8月26日水曜日

Take an Android Chrome tracing from laptops with small storage

./tools/profile_chrome.py is our friend to take a great tracing data from Android Chrome and Chromium. But usually it requires to check out the huge chromium repository that is too large, about 8-GB, to have it in some sorts of laptop devices. This is a note to copy small set of files from an existing checkout to run the tool on another laptop device.

desktop % tar zcvf chromium_tools.tgz \
> ./build \
> ./third_party/android_testrunner \
> ./third_party/catapult \
> ./tools


laptop % scp desktop:chromium_tools.tgz /dev/stdout | tar zxv

The expanded files still need 512-MB of your storage, but would be much better than 8-GB.

2015年5月6日水曜日

HP Stream 11 d012TU その後

しばらくSD Card上のLinuxをメインに使ってますが、ディスク周りで少し設定をいじりました。やっぱりスワップが始まると耐え難い重さになるので。

まずは何はともあれzram。
$ apt-get install zram-config
でインストールしてますが、そのままだとメモリの半分をCPUの数で分割したzramが作られるので、/etc/init/zram-config.conf を直接編集してメモリの1/4だけ使うように変更してます。普通に使ってる分にはデフォルトの設定が良いような気がしますが、kvmで1GBとか持ってく時には標準設定はイマイチかな、と思って。結果256MBのzramが2つ。加えて内蔵ディスクから1GB工面して低優先度の2次スワップに当ててます。けど、やっぱりディスクまでいくと重いので、潔くOOM Killerのお世話になるのが良いのかもしれません。

あと、preloadとprelinkも。
$ apt-get install preload prelink
でインストール。prelinkはChromeに使ってます。あまり知られてない気がしますが、$HOME/.local/share/applications/chrome-app-list.desktop を使うとUbuntuのUnityでもChromeのLauncherが使えます。が、そのままだとメニュー開くのに時間かかっちゃう。
$ prelink /opt/google/chrome/chrome
みたいな感じでprelinkしとくと起動がかなり早くなる。他にも頻繁につかう共有ライブラリ使いまくりな大きめのアプリならprelinkしておくと結構幸せ。

カーネル周りの設定は/etc/sysctl.confにて。
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.swappiness = 20
あたりの設定を入れてます。ともかくディスク(SD Card)が遅いので、なるべくdirtyなページはこまめに吐き出すように、と。でないとメモリ足りなくてディスクキャッシュを追い出すときに固まりがち。あとswapinessは低め。zram入れてからはzramが緩衝材になってくれてるんで不要かもしれませんが、zramない状態だとディスクが常にスワップ関連のI/Oでフルフル。たぶん閾値付近で同じページが出たり入ったりな状態。

ファイルシステム周りはtmpfsを適宜導入してvm.dirty_*設定の副作用をキャンセル。
tmpfs           /var/log        tmpfs   defaults,noatime,size=16m 0      0
tmpfs           /var/tmp        tmpfs   defaults,noatime,size=16m 0      0
tmpfs           /tmp            tmpfs   defaults,noatime,size=64m 0      0
あと/なんかにもnoatimeのマウントフラグを指定しちゃってます。ファイル読むときに、あしあと付けないモードですね。ディスク不可軽減の足しに、ということで。

ベストな設定ってほどにはチューニングしてないんだけど、標準設定よりは顕著に快適になりました。

(補足)/tmpはアップデート時に大きなファイル持ってくる子が多いので、やっぱりtmpfsはやめました。あとbluetoothが動いてないことに気づいて、こいつを試してみたけどNG。最新のkernel branchでも該当チップのsubverが未対応っぽい?無理やり別ファーム読ませたりするとデバイススキャンが動くくらいにはなったけど、同時にWifiが不安定になるので無理せず諦めました。

2015年4月20日月曜日

Chrome 43 beta with Web MIDI

こちらでもアナウンスしたのですが、大切なことなので日本語でも言っておきますよ。しかも、もっと詳しく。

最新のChrome BetaでWeb MIDI APIが標準でサポートされるようになりました。このAPIはAndroid版と全てのデスクトップ版Chromeで利用可能になります。

MIDIはご存知の通り30年以上の歴史を持つ古い規格。よくSMFと混同されがちなのですが、音楽ファイルというわけではなく楽器同士の通信プロトコルです。その通信内容を時間情報とともにダンプしたファイルがSMF。演奏情報を記録する事でカラオケや着メロの楽曲データとして利用されてきた経緯もあり、その印象から(チープな音で演奏される)音楽ファイルとして誤解されがちですが、あくまでもそれは一応用、という事で。

なんでそんな古いものをまた……と思ったそこのあなた。Webも25年近い歴史を持つ古い技術です。垣根を超えてつながることで発展してきた、という意味ではどちらも似た志を持っており、絶妙な割り切りが的を得て発展・成功した仲間です。ここでこの2つが分野を超えて繋がることで新しい応用が広がるかと思うと、なんかワクワクしませんか?

Web MIDI APIはJava ScriptからMIDIの入出力を可能にするAPIです。具体的には電子ピアノやシンセサイザーなどのキーボード類、電子ドラム、あるいはDJ機器からの入力を受け取ることが出来るようになります。一方で、各種電子楽器に対して演奏情報や設定情報などを送信することが可能になります。これにより

  • 電子楽器の音色管理ソフトウェアをWeb上で構築
  • サイトを通じて自動演奏ピアノに曲を提供
  • Web Audioなどで作られたソフトウェア音源をキーボードから演奏
  • 演奏情報をWebからリアルタイム配信
  • Web GLなどを使って作成したVJソフトを演奏情報に同期させる
などがWeb標準技術を用いて実現可能となります。すでに多くの開発者がソフトウェア音源を作ったり、DAWソフトを作ったりしていますが、これからも多くの応用が生み出されていくと期待しています。

今現在ではWeb Audioの実装で先行していたChromeのみがWeb MIDI APIをサポートするブラウザとなっています。が、仕様はW3Cで標準化されており、同じくWeb Audioの実装を持ったFirefoxも開発を進めているところです。IEは今まさにWeb Audioの対応を進めているところであり、今後に期待と言ったところです。

2014年9月14日日曜日

ニコファーレ完結編


イベント終了。突貫工事だったけど、なんとかそれなりに仕上げることができたかなぁ、と。イベント中はプロの映像制作屋さん・オペレータの2名と一緒にLED照明卓に張り付いていたので、プロの作業を仕込みの段階から長時間見ることができたのが何よりの収穫。

作った素材的にはこの辺にあるモノ+αの15種類くらい。3chのミキサーをMIDIコントローラから制御できるようにしたホストアプリをtmalib上に構築してました。今回のために書いたコードは175 commitsにわたり、コード量も倍増。
% git log -p --full-diff --since Aug | wc -l
23742
だそうです。

Tell Your Worldのステージ中に使った素材の一部

ライブラリ実験用に作った3D版Waypointsがパラメータを変えるだけで色々と使いまわせたのは助かったです。特に直前に追加で作ることになったエンドロールとかは数時間しか作業できなかったので……。フォントからテクスチャ作るライブラリ工事だけで時間切れになっちゃった感じ。

本番のエンドロールはMichael Jackson版Behind the Mask

で、色々と見つかった課題。

  • 自分の作ったライブラリで一番まずかった点はミキサーのフェーダ。うかつにも線形に作ってしまったけど、どう考えても対数で作るべきだった。コードばかり書いてて操作をあまりやってなかったので気付かなかった。
  • 機能として足りなかったのはプレビューと速度調整。プロの現場だと、次に使う絵をプレビューで先出ししてて、ステージ上の音楽に合うように映像のループ位置や速度を調整して、ここからって場所が来たら瞬時に切り替えて使う。DJアプリと一緒ですね。今のフレームワークでもタイムラインはきちんと管理してるので、UIさえつければすぐにでも動く。けど、性能的にプレビューまで出すのはちょっとキツイ。本番ではFull HDで生成・出力をしていたけど、エフェクトを重ねてると現状でも30fpsに落ちることがあった。そもそもコンソールと外部出力、複数のウィンドウに対して、同じタイミングで絵を送るのがちょっと難しそう。Web Music Hackathonの打ち上げでも話題に出てたけど、それこそOS XのSyphonみたいな仕組みが欲しくなってくる。
  • シェーダーのコンパイルに数百msec必要で、その間requestAnimationFrameが届かなくなるため、エフェクトのダイナミックなロードが難しい。フレーム落ちを避けようとすると、基本的に曲の頭で色々なリソースを先読みする事になってしまい、メモリ消費が激しくなりがち。ちなみにこのアプリは起動時に500MB以上食ってたし、デバッグ時には作業しているうちに2GB付近まで増えてタブ落ちする事も。
でもまぁ、ウェブアプリベースで本格的な照明制御を行う実験としてはまずまずかな。思いついた事を全てやるには圧倒的に時間が足りなかったけど、まずまずは満足。


Web MIDI API update at Chrome 39

これが最初で最後になるとは思うのですが、ECMAScript 6との親和性を高く保つため、既存のJavaScriptコードに修正が必要になる変更がChrome 39で導入されます。現在はCanaryとDevのみの変更ですが、年内には安定版も含めて新APIへ移行します。

Chrome 37, 38, 39で動作するコードを考えた場合に気をつける点としては、ES6のfor...of構文が導入されたのがChrome 38という点に注意する必要があります。この構文を含むコードは、例えこの構文が実行されないパスにある場合でも文法エラーになってしまいます。そのため、Chrome 37以降で動作させるためには、next()とdoneを使ってforループを回す必要があります。

具体的な例としてYAMAHAさんがGitHubに公開しているコードに対してパッチを作ってみたので参考にしてみて下さい。



To be more friendly with ECMAScript 6, we will introduce incompatible change to Web MIDI API that requires applications' JavaScript code being modified in Chrome 39. It's in Canary and Dev channel for now, but all channels including Stable will migrate to the new API by the end of this year.

If you want to support Chrome 37, 38, and 39, you should be careful about that the ES6 'for...of' syntax can be available in 38 and laters. It will raise a syntax error. To avoid this problem, you need to use next() and done to run a for loop correctly.

Here are two examples for YAMAHA's GitHub projects that may help you.


2014年8月29日金曜日

Web MIDI API - the past, the present, and the future -

Web Music Meetup #1で発表したスライドを公開しました。Chromeでの実装についてのまとめです。今までHTML5についてはWebSocketとWeb MIDIについて関わってきましたが、どちらもメディアアート系の人たちに気に入ってもらえているのが嬉しいです。


2014年6月14日土曜日

続・ChromeにおけるWeb MIDI APIの実装状況

昨年末にWeb MIDIの実装状況について書かせて頂きました。その後の更新状況についてまとめたいと思います。

Chrome 34
  • Linuxサポート(ALSAをサポートするシステムのみ)
  • Androidは出力のみ対応(ただし、初期化手順の問題で最初の呼び出しは失敗する)
  • リアルタイムメッセージのサポート
  • システムメッセージ(sysexではない)はパーミッションなしで送信できるように修正
  • 送信メッセージにエラーがある場合、詳細情報がエラーメッセージとして書き出されるようになった
  • パーミッション許可を求めるinfobarが file://... に対しても表示されるようになった。ただし、セキュリティの都合上、許可・不許可は記憶されない。
  • Windowsでtimestampが間違っていたのが修正された
Chrome 35
  • PromiseがWeb MIDI向けの機能限定版から、フル機能版に差し替えられた
  • Chrome OSサポート
  • Androidの入力サポート(初期化手順の問題は未修正)
  • OS Xにおいて送信されるMIDIメッセージにCore MIDIのtimestampが正しく付加されておらず、Chromeから送信されるデータをDAWで受信すると、正しいタイミングで録音できない問題が修正された
  • MIDIAccess.sysexEnabledアトリビュートが追加された
Chrome 36
  • Androidの初期化手順の問題が修正された
Chrome 37(予定)
  • LinuxとChrome OS向けの実装が改善された(ALSA sequencer APIに対応)
  • Android向けのUI実装完了(infobarと設定画面)
追記:Chromeで実装しているAPIは最新版と若干異なります。最新の使用に合わせて近々更新する見通しですが、それまではこちらの旧APIを参照願います。またMIDIConnectionEventの実装も新APIになるまで見合わせています。

For English readers;
I'd summarize Web MIDI implementation status on Chrome. I also did it at the end of the last year, but in Japanese. So, I'd mention also previous status together.

Chrome 30
  • chrome://flags#enablr-web-midi appeared on OS X
  • Input ports were available on OS X, but there was a bug on sysex until Chrome 32
Chrome 31
  • Output ports were also available on OS X
  • Infobar and settings UI were implemented as a part of content settings
Chrome 32
  • IAC driver was available
Chrome 33
  • Web MIDI worked on Windows, but had wrong timestamp values
Chrome 34
  • Web MIDI worked on Linux (but only ALSA supporting systems)
  • Also, worked on Android, but only output ports are available
  • There was a problem on initialization process, so the first API call didn't work on Android
  • Real-time messages were available from this version
  • System messages were available without a sysex permission from this version (previous versions required a sysex permission even for system messages)
  • Error provided detailed messages on invalid send messages
  • Infobar appeared even on local files, but browser could not remember the permission because of security reason
  • Wrong timestamp was fixed on Windows
Chrome 35
  • Now, Promise is not limited version Promise, MIDIAccessPromise, but fully featured proper Promise
  • Now the API is available on Chrome OS
  • Input ports are available on Android, but the initialization issue is not fixed yet
  • Fix a bug that sending messages had wrong CoreMIDI timestamp and caused a problem that DAW could not record Chrome sending messages with correct timestamp
  • MIDIAccess.sysexEnabled attribute is added
Chrome 36
  • Android initialization issue will be fixed
Chrome 37 (planned)
  • Linux and Chrome OS supports will be improved so to support ALSA sequencer API
  • Infobar and settings UI for Android will be implemented
Note: The implemented API is slightly different from the latest W3C spec. You can see the old specification here. Also, MIDIConnectionEvent is not implemented yet. It will be available once new API is ready.