サウンド系API事情04 Linux系API

前回はMacのサウンドAPIについて説明したが、今回はLinuxのサウンドAPIに関して説明する。
Linuxはディストリビューションが多数ありそれぞれにモジュール構成の方針があるため、APIが多数ある。しかも、誤解を恐れずにいうがソフトベンダーがデスクトップ版をあまり重要視していないため、それぞれのディストリビューションで規格を統一しようという考え方があまりないようで、採用しているAPIもまちまちだったりする。
こういう事情もあり、複数のLinuxディストリビューションに対応したマルチメディアソフトウェアを作るのは、結構ないばらの道になることだろう。

サウンド系API事情03 Mac/iOS系API

前回はWindowsのサウンドAPIについて説明したが、今回はMac/iOSのサウンドAPIに関して説明する。

新しいMacはiOSとAPIを同規格にしているものが多い為、昨今のAPIはiOSでも使用出来る。
ただし、サポートしている機能が異なったりレイテンシなどの品質が異なるなど、差異があるため注意が必要だ。
モバイルではバッテリ消費などを気にするため、品質や作法が異なる結果になるようだ。

サウンド系API事情02 Windows系API

Windowsは古くからゲームなどエンターテイメント筐体に採用されてきたため、複数のAPIが存在する。
デスクトップ環境としては最も使用されてきたOSであることもあり、求められる水準も高かったことだろう。
今回は、Windows環境のサウンドAPIについて説明する。

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

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

AWSでWebサービスを構築10 AWSクラスタの運用例

これまでの知識で、Apacheなどが動作するアプリケーションサーバとデータベースを構成することはできる。
冗長化や負荷分散も基本的な構成は説明した。
ドメインやサブドメインの設定も、前回の説明で可能になった。
すでにサービスの開始は可能になった。

ここで、EC2インスタンスの修正とクラスタ更新に関して、実際に運用する際の一例を説明したい。
ただ、特にAWS側で推奨している方法というわけではないため、自分に合うかを判断しながら参考にしてほしい。

AWSでWebサービスを構築09 Route 53でドメインの登録

これからは運用方法の紹介や他の便利なサービスの説明をしたいが、その上でドメイン・サブドメインなどが使えたら効率はぐんと上がる。
今回はDNSサービスAWS Route 53の使い方を紹介する。

※独自ドメインが必要になるので、お金を覚悟するか、どこからか無料のドメインを借りてくる必要があるので注意！

DNSサービスはドメイン名とIPを関連付けたり、あるいはサブドメインを設定してそれをIPと関連付けたりすることができる。
ドメインは「blogger.com」みたいなもので、サブドメインは「img.blogger.com」のようなドメインより１つ多いもの。
ドメインを１つとっておけば、そのサブドメインは自由に設定できる場合が多い。
Route 53はこのドメイン・サブドメインとIPの関連付けが簡単にできるし、独自ドメインの取得もRoute 53の管理画面から可能となっている。

Route 53のショートカットを選択すると管理画面が開くので、ここから作業をはじめる。

AWSでWebサービスを構築08 サーバ冗長化とロードバランサの構築

前回までにAPサーバ、DBインスタンスを作成した。
ただ、このままでは一般的なレンタルサーバなどと特に構成が変わらない。
AWSなどのクラウドプラットフォームだと、よりサービスに適した構成をとることが出来る。
今回はインスタンスの構成について、もう少し改善したい。

具体的には、サーバの冗長化と負荷分散機構について説明する。