Androidのサウンド環境はJelly Beanで劇的に進化する

Androidのサウンド環境はJelly Beanで劇的に進化する 1

音楽好きなみなさん、音楽アプリ開発者のみなさん、大変お待たせしました! Android 4.1 Jelly Beanではいよいよサウンド環境が整い、音楽や音声アプリが満足に使えるクオリティに達します

これまでのAndroidは、ハードウェア的にもOS的にもなかなか厳しいサウンド環境に悩まされていました。そこでグーグルはJelly Beanできっちり改善を行うとともに、そのパフォーマンスが十分に出せるようハードウェアのメーカー側にも厳しい基準を設けました。また、新たなサウンド環境を利用したいアプリ開発者のために無料のクロスプラットフォームlibpdライブラリもありますので、後ほどご紹介していきますね。

Jelly Beanのデベロッパー・プレビュー版では、音声データのレスポンスが改善され、なめらかに再生されるようになっています。これはミュージシャンにとっても嬉しいですよね。サウンドまわりに関するJelly Beanの機能概要はCreate Digital Musicのまとめ記事も参考になるので、ぜひチェックしてみてください。

新OSとそのハードウェアでは、音声や音楽を扱うアプリのパフォーマンスが劇的に改善されています。とくに、リアルタイムな音声レスポンスが重視される楽器シミュレーションアプリなどでは、その差がさらに実感できますよ。

通常、ハードウェアやOS、アプリなどの要因によって負荷がかかりすぎると、音声再生中にクリックノイズやポップノイズが入ってしまいます。そういった状況を回避するために、アプリ開発者は音声データのバッファを大きくとるなどして、アプリのレスポンスを高速に保っています。ならば、プラットフォームとしてはじめから対策しておこうというのが、今回の試みなんですね。

Jelly Beanにおける具体的な変更点は、こんな感じです。

  • 新しいソフトウェアミキサーやAPI改善により音声出力のレイテンシ(タイムラグ)を短縮
  • レイテンシ目標値を10ミリ秒以下に設定。ただし、公式に発表された対応機種は現在サムスンのGalaxy Nexusのみ。ほかの機種も同様のパフォーマンス改善が期待されるが、対応機種や時期は未発表
  • 将来的には厳密なレイテンシ最大値をサードパーティーに要求
  • USB音声デバイスのサポート、HDMIポートを通じたマルチチャネルオーディオレコーディング機能などOSの機能拡張

ところで、なぜ今回の変更が重要なのでしょうか?

人は平均すると、だいたい同じレベルの知覚や聴覚を持っています。音声や音楽アプリにおけるほんのわずかなレスポンス遅延も聞き分けられる方は多くありませんが、音楽の再生中に音がぶちぶちいったり遅延したりするのは素人の耳でもすぐわかります。

このとき、ソフトウェアのサウンド改善に精通した人ならば様々なチューニングを行うことができますよね。でも、誰もが開発者視点で音声を扱えるわけではありません。今回はそういった「普通の人」でも音声を扱いやすくなったことに、大きな意味があると思います。

バーをあげて、スピードを上げろ

レイテンシは、ある一つの要素によって決まるわけではありません。たとえばレーシングカーに例えて考えてみましょう。エンジン、ギア、重量、空気力学...それぞれが小さな努力を積み重ねることであのスピードが生まれています。そしてAndroidのオーディオ・パフォーマンスにも同じような複雑さが絡んでいます。これまで、中途半端なデベロッパーAPI、タイムラグの大きなシステム・ミキサー、そしてデバイス固有の問題がパフォーマンス向上を邪魔していました。

アップルのiOSはオーディオ・パフォーマンスが優れているので、音楽アプリも当たり前のように揃っています。でも、多くのハードウェア・ベンダーと協業すると低レイテンシ化できないのかというと実はそうでもありません。ウィンドウズ(あるいはLinux)が良い例です。ASIOのようなAPIを使いハードウェアに関係なく優れたパフォーマンスが出せている部分もあれば、レイテンシが100ミリ秒を超える汎用ミキサーのスペックにひきずられてしまう部分もあるのです。

Android開発チームよると、このプラットフォームはついに正しい方向に進みはじめたそうです。逆にモバイル向けのWindows 8は過去のAndroidと同じ課題を抱えています。最新情報をもとにWindows RTやWinRT/Metroライブラリを見る限り、WindowsタブレットではUSBやマルチチャンネルが使えないだけでなく、レイテンシ・ターゲットも100ミリ秒を超えています。ただし、私たちが知らない朗報もあると思いますので、ひきつづきマイクロソフトからの情報を待ちましょう。

Windows 8では、シンプルにシステムミキサーを通したサウンドルーティングの実現が重要だと思われます。WindowsRT、WinRTでは未実装ですが、Androidはついにこの山を乗り越えていくようですね(ちなみにiOSやウィンドウズ、Linux、Mac OS Xは何かしらのかたちで実装済)。

レーシングカーの比喩に戻りましょう。ここで自分がドラッグレース(直線コースでタイムを競うレース)に出場するところを想像してみてください。誰もいない道と大都市の混雑した道、どちらで走りたいですか?

汎用的なシステムミキサーは、概して後者の状況にあります。Google I/Oの質疑応答でAndroid開発チームが説明していたのは、まさにこの部分。彼らは、レイテンシを10ミリ秒以下にすることがゴールだと発表しました(オーディオエンジンを稼働させるとき、音声にバッファをもたせて再生と思われますが、もし違っていたら教えてください)。

Androidはソフトウェアとしても確実に進化していますし、ハードウェアベンダーとの調整にもさらなる努力を費やしています。たとえばサムスン Galaxy Nexusは、Ice Cream Sandwich(Android 4.0)で100ミリ秒だったレイテンシをJelly Bean(Android 4.1)では12ミリ秒にまで短縮し、さらなる改良を積み重ねていくとのこと。もちろん12ミリ秒でも実用的な速度ですが、10ミリ秒を切ればサウンド開発者にとって魅力的なプラットフォームになりますね。なお、ASUSのNexus 7タブレットのほうは、ハードウェアのサウンド・パフォーマンス改善について今のところとくに言及されていません。

高速化されたミキサーはSoundPoolToneGeneratorOpenSL APIとの相性もよさそうです。とくに、OpenSL APIは以前のOSでもパフォーマンス改善が見られるという開発者の声もあり、新OSでの期待も高まるところです(無料のlibpdを用いたOpenSLの使い方は、この記事の下のほうでご紹介します)。

ただし、市場に投下される新デバイスがひととおりこの目標値に達するまでには、まだ少し時間がかかりそうです。グーグルは各デバイスに対してレイテンシの最大値を決めていく姿勢を明らかにしていますが、具体的な時期については不明とのこと。

現状のAndroidは端末による違いが多いので、開発者は最低限の要求を満たすだけでもけっこう大変な作業を強いられますよね。15ミリ秒以下のレイテンシがJelly Beanデバイスで標準化されればAndroid 4.1バージョンでの必要条件が分かるので、動作不具合によるクレームも避けられそうです。

とはいえJelly Beanは、ハードウェア・アクセサリや音質、アニメーション、フレームレートなど様々な面で全体的に進化を遂げています。これまでiOSを面白くしてきた要素、ユーザや開発者の満足度向上につながっていた要素も満たしてきています。アップル製品のソフトウェアはスペックだけに依存していないという声も聞くこともありますが、彼らはハードウェアを無視していたわけではありません。実用に耐えうるクオリテイになるよう、きちんと測定していたのです。

オーディオ環境の改善点

Jelly Beanはグラフィックの進化も素晴らしいですが、サウンドは需要の多い機能を搭載してきた印象。具体的にはこんな感じです。

  • USBオーディオがサポートされ、Androidオープンアクセサリ開発キット(ADK)を用いた出力が可能
  • HDMIポートを通じたマルチチャンネルオーディオをサポート
  • ハードウェア、ソフトウェアのメディア・コーデックは低レベルアクセスが可能に
  • オーディオレコードトリガー
  • オーディオ処理
  • シームレスな再生を可能にするオーディオ連結
  • メディア・ルーティング(アップルのAirPlay的な機能)

この中でミュージシャンにとって魅力的なのは、なんといってもHDMIマルチチャンネルとUSBオーディオですよね。どうやったらUSBオーディオが使えるのか、iOSのようにUSBオーディオのクラスがサポートされているのか、USB MIDIがサポートされているのか、といった情報は現在調査中です。

なお、このあたりの情報はJelly Bean概要に掲載されています。開発者のみなさんは、その先の情報やSDKの詳細を求めていそうですけどね。

libpdとOpenSL

ピーター・ブリンクマン(Peter Brinkmann)さんが開発した「libpd」は無料のオープンソース。これは、デスクトップ/モバイルOSの両方で使えるPure Data(作曲などに使われるビジュアルプログラミング言語。以下、Pd)の埋め込み可能版といったところでしょうか。ほかのアプリ内でPdパッチが簡単に使えるようになる言語で、OpenSLのサポートにも注力しています。

「OpenSL」はモバイル端末のハードウェア側で音を制御するためのインターフェースで、再生・録音、音量、イコライザ的な機能なども扱うことができます。ピーターさん曰く「全ての検証デバイスにおいて、OpenSLは標準的なJavaオーディオよりも優れている」という結果が出ているとか。libpdライブラリ以外にも、JavaやC言語などを使うAndroid開発者もそのメリットを享受することができます。

さらに、OpenSLはAndroid以外でも使えるようになるようです。ピーターさんは「PortAudio(オープンソースのオーディオ・インターフェース・ライブラリ)を用いて、15分もあればMacで快適に稼働するプロトタイプをすでに作成した」とのこと。「ほかのプラットフォームへのプログラム移植は、makefileの調整に少し手こずる程度。libpdは、Java Soundのようなものを必要とせずにJava言語のオーディオ・ソリューションを提供できるスタンドアローンのライブラリになる」そうです(ピーターさん、あなたのメールを引用してすみません。でも、読者のみなさんがあなたの取り組みを支援してくれるという願いをこめて、ここに公開させていただきます)。

libpdとOpenSL ESについてピーターさんが作成した資料は、一読の価値がありますよ。Androidオーディオの開発に関する未来、Pdなどを用いたクロスプラットフォームのフリーソフト開発の未来が垣間見えるかと思います。

libpd and OpenSL ES, Part I: Squaring the circle

libpd and OpenSL ES, Part II: Yet another JACK-like API for Android

libpd and OpenSL ES, Part III: Receiving messages

libpd and OpenSL ES, Part IV: Extending the API

またAndroid向けのlibpdも利用してみてくださいね。

FroYo(Android 2.2)以前に対応したAudioTrack/AudioRecord、そしてGingerbread(Android 2.3)以降に対応したOpenSLをサポートするpd-for-androidを作成しました。不可能を可能にし、すべてのトランジションが開発者にも分かるようにしました。低レベルのオーディオ処理方法を除けば、アプリ作成時に何らかの調整をする必要は全くなくなります」

オーディオエンジンの切替ができると、JACKやCore Audio、ASIOといったものをほかのOSで使うときにも便利ですよね。libpdに関する情報は以下のサイトからどうぞ。

http://libpd.cc

音声や音楽に関するニュースは、今後も一般ユーザー向けから開発者向けまでプラットフォームを問わずお届けしていきます。ぜひご期待ください。

Peter Kirn - Create Digital Music(Rumi/米版