サウンド系API事情01 前知識

近年では、様々なプラットフォームでアプリケーションが作成される。
これがプラットフォームごとにそれぞれ異なるAPIで実装されているのだから、マルチプラットフォームのアプリ開発環境が隆盛するのも当然といえる。
ただ、マルチで開発していると何を使用しているかを意識することがなく、それぞれに抱える問題などが正確に把握できない、という問題もまた開発者にはあることだろう。
この記事では、いくつかのプラットフォームを例にとって、サウンド系APIについて説明したい。

注目点

サウンド系のAPIは、用途にとっても得られる機能が異なる。
例えばUIの気持ちよさなどが重要なコンテンツやインタラクティブ性の高いコンテンツなどは高い性能が求められるし、作曲ソフトなどはよりシビアな条件が求められる。
いくつか性能に関する観点があるが、主なものをあげてみる。

コールバック機構

音声ファイルはサイズが大きい。つまり、データが多い。
そのため、長めの音声は全て読み出してメモリに載せるのではなく、データを少しだけファイルから読み出して再生し、また少し読み込んでは再生し・・・と繰り返すことでメモリを節約し、かつすぐに再生が始められるように実装されることが多い。（ストリーミングなどと呼ばれる）
ここで次のデータを読み込むために、読み込んだデータの再生が終了したら呼び出されるコールバック機構が必要となる。

サウンドなどのドライバはOSの核の部分（カーネル）で制御していることが多かったので、このコールバックでおかしな操作を行ったらカーネルの範疇で問題が起こるため、OSの死につながりかねなかった。
そのため、意外にもこの機構は実装されていないAPIが結構ある。
コールバック機構が無い場合は同様のものを自前で作る必要があるので、これがあるのとないのでは結構実装の難易度が変わってくる。

マルチチャンネルとミキシング

この点は、ほぼ全てのAPIが当たり前にサポートしている。が、同時再生できる数に限りがあったりするので注意が必要だ。
これはその再生端末のサウンドデバイスに制限があることがほとんどだが、これをソフトウェア上で複数音声を合成（ミキシング）して単一のチャンネルだけで鳴らすことで同時再生数の問題を無効化する、という進化をたどってきた。
（OSの核でミキシングを行うことを、カーネルミキシングなどと言ったりする）
一見良い機能のように思われるが、ミキシングを行うことで音質が下がることがあるので嫌われることも多い。

また同時再生の話題としては、他アプリの音声を排他的に制御できるか、なども注目される点かと思われる。

遅延（レイテンシ）

サウンド系のAPIで問題提起される点としてよく挙げられるのがレイテンシ問題。
再生命令を出してから発音までにタイムラグがあると、使用出来る用途が限られてしまう。
人間は聴覚の時間軸の分解能が割と高いため、気になったり、遅延を意識できなくても気持ち悪かったりすることがある。
また、ミキシングなどをによって起こされるレイテンシも存在する。


音声再生に関しては、プラットフォームごとに特徴がある。
特にモバイルなどは制限などが強いため、注意して実装する必要があるだろう。
これからこのシリーズでは、各プラットフォームごとのAPIについて説明する予定だが、プラットフォームとしては
Windows、MacOSX(macOS)、Linux、iOS、Androidを想定する。
また、OpenALなどの共通APIについても、簡単に紹介したい。

今回は簡単に前知識としての注目点を説明した。
次回からは、実際にAPIを紹介していく。