SUZUKI PLAN blog - 妄言郷: VGS-SAL

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

2015年8月15日土曜日

ソフトシンセの作り方(7) - VGS-SAL

VGSのソフトシンセ（波形メモリ音源）の開発で得られた知見を元に、PCやスマートフォンで動くソフトシンセの作り方を解説していきます。一冊の本が書ける程度の分量なので、幾つかのパートに区切って解説していきます。このシリーズを一通り読めば、サウンドプログラミングについて全くの素人でも、PCやスマホなどのプラットフォームで動くオリジナルのソフトシンセが作れる程度になります（たぶん）

なお、このシリーズで扱うプログラミングの例題のビルドには、パソコンが必要です。OSは私が使っているMac OS X向けに解説を記述しますが、Linux（※ALSAに対応しているもの）やWindowsでも問題ありません。

今回は、VGS-SALについて解説します。

VGS-SAL

前回の記事で紹介した低レベルAPIのひとつひとつを解説すると、それだけで膨大な量の解説が必要になってしまいます。そこで、低レベルを直接叩くのではなく、VGSのSAL（Sound Abstraction Layout）を利用することにします。

VGS-SALは、Windows（DirectSound）、Linux（ALSA）、Mac、iOS、Androidの低レベルAPIを抽象化したものです。これを用いることで、全OS共通実装で「波形直書き」の実装ができます。

sal-sample

vgs2リポジトリの sample/sal-sample ディレクトリにVGS-SALを用いたサンプルプログラムが格納されています。
このサンプルプログラムでは、VGS-SALを用いて440Hzのサイン波を鳴らし続けます。
サンプルプログラムは、ターミナルで以下のコマンドを実行すれば、ビルドできます。

$ cd ~/vgs2/sample/sal-sample/ && make

sample/sal-sample ディレクトリに格納されている makefile と saltest.c を見てみましょう。

(1)makefile

saltest.cをビルドする手続きが書かれています

(2)初期化: `init_sound_cli`

SALの初期化をします
cliとは Command Line Interface（コマンド）の略です
Windowsの場合、GUI用の初期化処理が別にありますが、その点についての解説は省略します
UNIX系OSの場合、CLI用とGUI用の間に違いはありません

(3)終了: `term_sound`

SALが用いているシステムリソースを解放します
かならずプログラムの最後で呼び出すようにしてください

(4)バッファリング: `sndbuf`

一定間隔毎にSALからコールバックされるバッファリング処理です
C++で実装する場合は、必ず extern "C" で宣言するようにしてください
引数 buf : 波形情報を格納するバッファです
引数 size : 波形情報を格納すべきサイズです
buf の内容を変更する処理は、必ず lock() 〜 unlock() で囲まなければなりません
上記サンプルでは、440Hzのサイン音 が鳴り続けることになります

(5)バッファリング処理の内容

sndbuf の lock() 〜 unlock() で囲まれた範囲（バッファリング処理）の実装内容をもう少しブレイクダウンして見ていきましょう。

1行目: for(i=0; i < size16; i++, ptr++) {

2行目:    *ptr = (short)(sin(r) * 16384);

3行目:    r += PI2 / (22050 / 440); /* 440Hz */

4行目: }

1行目

size16 は引数buf (8bit array) を 16bit array とした時の長さです
そして、i = 0 〜 size16-1 の間、ptr をインクリメントしながらループすることになります
ptr は引数buf を 16bit array にしたものです
ptr のインクリメントとは、__サンプリング周期のインクリメント（+1Hz）と等価ですね

2行目

sin(r) を 16384倍にした数値を ptr に代入しています
sin関数 の戻り値は -1.0 〜 1.0 の範囲の実数です
なので、ptr に代入している値は -16384 〜 16384 の範囲の値です
つまり、この 16384 というマジックナンバーは 鳴らす音の大きさ を意味しています
16bitは -32768 〜 32767 の範囲の数値なので、限界音量の 約50% がこのプログラムで鳴らす音の最大音量となります

3行目

r を 2π ÷ ( 22050 ÷ 440 ) で加算しています
r は スタティック変数 なので、関数が return しても値が維持され続けます
そのため、sndbuf が呼び出され続けると 440Hz のサイン波 が発音され続けることになります

追記

umm...

ここから先はコードベースの解説が多くなるのですが、bloggerだと結構辛いので、GitBook辺りを使ってイチから書き直すか。

ソフトシンセの作り方(6) - 音を鳴らす方法

コンピュータで音を鳴らす方法

音と情報量の関係

コンピュータが音を鳴らす方法は、時代と共に大きく変化（進化）してきました。

そもそも、音というのはデータ量として極めて大きな部類のものです。

昨今のスマートフォンアプリケーションは、市販ゲームなら数百MB以上のものがゴロゴロありますが、そのゲームの構成要素の内、音のデータが占める割合はかなり大きいです。

一般的なCD音質の場合、1秒間のデータ量は 44100（サンプリング周波数）× 2（16bit）× 2（ステレオ）バイト（176400バイト=約172KB）です。そのため、1分間で約10MBもの容量を必要とします。圧縮技術の進化により、1/10程度への圧縮（エンコード）が可能になりましたが、それでも1分間で約1MBのディスク容量を必要とすることになります。

RPGなどの音楽数が多いジャンルのゲームなら、音楽だけで数百MBもの容量を喰うことになります。

チップチューン音源が生まれた理由

昨今のPCやスマートフォンなら、それぐらいの容量でも問題無く処理できますが、8bitや16bitの頃のコンピュータでは、そんなに大きな容量のデータ処理は不可能です。また、CPU性能も遅いので、仮に現代の圧縮技術があったとしても、リアルタイムにデコードしながら再生することは、ほぼ不可能です。

そのため、制御信号だけで音を鳴らす仕組みとして、米国General Instruments社のAY-3-8910や、YAMAHAのYM-2203（OPN）といったLSIが誕生しました。

チップチューン音源が廃れた理由

しかし、Windows 95が登場した頃を契機に、PCが一般家庭に普及し、ストレージやメモリの容量、CPUの演算速度が爆発的に進化した結果、わざわざ音楽専用のLSIが無くても、音声全般を扱えるPCM音源だけで全て事足りるようになったため、チップチューン音源をPCに搭載する実用上の理由が無くなったことで、ハードウェアとしてのチップチューン音源 は、完全に姿を消しました。

ただし、SUZUKI PLANはその時代の流れに逆らって、チップチューン音源を復活させることを目指して活動しています。東方BGM on VGSも、いわばその活動の一環です。

それはともかくとして、現代のコンピュータで音を鳴らす手段は PCM音源に一本化された といえます。

という訳で、コンピュータでPCM音源を用いて音声を再生する方法について解説します。

PCM音源で音声を再生する方法

PCM音源で音声を再生する手段には、大きく分けると 低レベルAPI と 高レベルAPI の2種類があります。

低レベルAPI

最も原始的なPCMを再生する手段で、「波形直書き」と呼ばれる方式です。

低レベルAPIは、PCM音源デバイスに対して、PCMデータ配列を入力することで、PCM音源が発音するという極めてシンプルな仕組みで、Windows、Linux、Mac、Android、iOSのどのOSでも提供されています。

ただし、Androidの場合、波形直書きができるようになったのはバージョン2.3.3以降からのみで、バージョン2.2以前は、MediaPlayerと呼ばれる音楽を再生する仕組みと、SoundPoolと呼ばれるaacやoggなどのファイルから効果音を鳴らす仕組みしか提供されていませんでした。

高レベルAPI

Android 2.2以前から有る MediaPlayer や SoundPool は、非常に簡単に音を再生できる反面、独自に生成した波形データを再生することができないため、自由度が低く、またレイテンシが酷すぎてゲーム等では使い物にならない残念な機能です。（iOSでもAudioUnitで似たような機能が提供されていますが、これはAndroidよりは大分マシです）

このように、自由度を犠牲にしてより簡単に音を再生できる方式 のことを高レベルAPIと呼びます。高レベルAPIでは自由度が低すぎるため、ソフトシンセを作ることは不可能なので、以後本書では取り扱いません。

各OSの低レベルAPI

OS	低レベルAPI	備考
Windows	Wave Mapper, Direct Sound	本書ではDirectSoundを使用
Linux	ALSA, OSS (Open Sound System)	本書ではALSAを使用
Mac	Open AL
iOS	Open AL
Android	Open SL/ES

※ Mac と iOS の OpenAL は、全く同じです

見事に四者四様ですね。

ですが、できることは皆同じ「波形直書き」なので、使い方にはそれほどの大差はありません。

登録: 投稿 (Atom)