libpdを始めるにあたっての前提知識

とりあえずlibpdが動いている所を見たいという方はこちらへどうぞ。

Pdをコードに埋め込むという触れ込みの「libpd」ですが，これが具体的にどのレイヤの存在で，周りでどういう周辺サービスが動いてることになるのかをちゃんと押さえてないとマズかった．

まず，libpdは独自のサウンドAPIみたいな何かを持つわけではないです．一部ネットメディアで「libpdを使えばAndroidでもレイテンシが云々」みたいな紹介のされ方をしているので，あんまり詳しくない人は誤解をしてしまうかも（＝私という説）．

動作の形態としては，Pdをアプリ内アプリみたいな感じで独立に動作させ(PdBase)，こいつと通信をするためのプログラミングインターフェースとしてlibpdがあるという感じです．
特に重要なのは，PdBaseは単に設定したバッファサイズやサンプリングレートに従ってサンプル値の配列をやりとりするだけのものであって，オーディオデバイスとは無関係な存在であること（まさに純粋なデータ(pure data)か）．PdBaseと送受しているサンプルを「音」としてとらえ，オーディオデバイスに受け渡しする部分(libpd開発者の本では「Audio glue」と表現)はPdBaseの外で書く必要があります．

スタンドアロンのPdでは「PortAudio」や「JACK」を経由し，CoreAudioとかASIOで音を鳴らすように作ってありますが，libpdも各プラットフォームがサポートしているサウンドAPIを使って音を鳴らすことになります．

で，現状のところlibpdのAudio glueとして対応しているサウンドAPIは，iOSではCoreAudio，Androidではandroid.media.AudioTrack．このAudioTrackの時点でレイテンシがものすごいので，libpdを使うといきなりAndroid上でサウンドレイテンシが改善するかというと全くもってさっぱりきっかり否です．

じゃぁ何がうれしいねんというと，実際のところ注目されているのは，関連プロジェクトのpd-for-androidでのOpenSLを使った実装と、libpdプロジェクトのブランチで進んでいるPortAudio対応バージョン．

pd-for-androidはOpenSL用のAudio glueを用意したAndroid用のバージョン．OpenSLはJava上ではなくネイティブ領域で動作させるAPIなので，相応の低遅延化が期待できるというわけですね．

# OpenSLとOpenALは月とスッポンなので注意．OpenALは言うなればオーディオミキサーAPIのようなもので，提供する機能や狙う性能のセグメントとしてはもっと上級です．AndroidのOpenALは内部で前述のAudioTrackを呼んでいます．

PortAudioは，サウンドプログラミング環境のクロスプラットフォーム化を目指して， 内部でCoreAudioやASIOなんかをラッピングしているAPIです．

現状，グラフィックのテスト環境としてlibGDXのクロスプラットフォーム機能が非常に重宝しているところですが， PortAudioを使ってlibpdを走らせれば， サウンドのテスト環境もクロスプラットフォーム状態になって非常にスムーズです．PortAudioによってモバイル向けアプリのテスト環境を統一するという手は，libGDX以外のゲームエンジン…Cocos2dx等でも同じように適用できると思います．