技術情報 :: Magome

開発環境＆実行環境 ^[1]

• Magome サーバー及びクライアントアプリ
  • WindowsXP (32bit,64bit) 以降
  • VisualStudio2008(VisualC++9.0) SP1 Standard 以上 - MFC 使用 - 32bit ビルド　
• Web サーバー
  • LAMP（"L"ではなくFreeBSD(なのでFAMP?)。PHP5.x。MySQL5.x) + XOOPS Cube

VST ^[2]

• VSTSDK2.4 を使用。3.0系は未調査、未着手。
• 規格上かなりローレベルなインターフェースなので、VST によって NG なお作法などがある。特にスレッドについての取り決めはかなり緩そう。
  • メンテされている VST プラグインであれば、排他処理やスレッド管理をしっかりとしてそうなので、ホスト側をどう組んでも動いてくれそうだけど、そうでもない VST プラグインが存在していそう。
  • VST ホスト処理として安全に組むなら、全てのインターフェースを１つのスレッドでのみ使うのがいいんだろうが、オーディオ処理系と設定画面(UI)系を同じスレッドで処理するのは、パフォーマンス的に厳しそうなので、そこは分けるしかなさそう。
  • なので、VST ホスト処理としては、cubase とかの有名アプリではそうしているであろう挙動に合わせていくのが正解っぽい。
  • もしかしたら世の VST ホストアプリの中には、特定プラグインの場合には特別な処理をするとか、そういう継ぎ接ぎっぽいことをしているものもあるのかも。

ASIO ^[3]

• ASIO SDK 2.1 を使用。
• レイテンシは小さい。けっこうローレベルな IF なので、自前で諸々処理が必要。

DirectSound ^[4]

• レイテンシはそんなに大きくなさげ。デバイスをアプリで独占するわけでないので、MediaPlayer で MP3 を再生させつつ、VST の出力も再生するとかもできる。

複数の出力デバイスの同時再生 ^[5]

• Magome 内部の再生エンジンは、 複数のオーディオ出力デバイスから、同時に音を出すことを可能にしている。
• ASIO も DirectSound も混在して同時に使うことが可能。がしかし、同時に使った際にデバイスによる時間のズレをどう吸収するのがよいのか。（とりあえず手元のデバイスでは、複数デバイスのズレが気になることはないが、理屈上は有りえそう。）
• Magome では、PC の高分解能カウンタをマスターとして使う。もし PC のカウンタとそれぞれのデバイスのカウンタ(時間)にズレが出てきたら、PCのカウンタに合うように発声のタイミングを調整する。
  • PC の機種によっては高分解能カウンタはアテにならないということもあるようだが、昨今のPCなら問題なさそうな気配がするので気にせず使用。

MIDI ^[6]

• Windows標準のMIDI音源はレイテンシがものすごく大きい。VST などと同時に再生させたときのズレを吸収させる工夫は要実装。

boost ^[7]

• boost 1.56.0 を使用。

boost::asio ^[8]

• Winsock をなるべく直接は使わず boost::asio のお世話になっている。が、通信以外でも、非同期IFとしての利用にも便利。
• Web サーバーのとの通信には基本的に使わない。Magome サーバーとクライアントアプリ間の通信で使用。（Web サーバーとのやり取りは IE コンポーネントを利用。）

SQLITE ^[9]

• Magome サーバーにて、楽曲データなどの管理で使用。

cairo ^[10]

• 描画処理で使用。Win32API(GDI)を出来るだけ直接使わないように。
• メモリリーク？
  • 使っていくうちにメモリを切迫していくようなものではなさそうだけど、アプリ終了時にメモリ解放してないように見受けられる箇所があるっぽい。OSのプロセス終了によりメモリ解放を期待しているってことなんだろうか。それとも当方の使い方が悪いのか。他で cairo を使っているアプリ（GTK+とか）はどうしているんだろう。

アプリケーションの自動更新 ^[11]

• アプリ起動時にサーバーのファイルを参照して、新しくなっていれば、ダウンロードして自身を置き換える。
• サーバー上の zip ファイルを参照する。フル版とかアップデート版とかの区別はナシ。（リリース時の手間やミスを減らす為、ファイルを zip で圧縮してサーバーにアップすればリリース完了という仕組み）
• zip ファイルのヘッダにあるハッシュ値と、ローカルファイルのハッシュ値を比較して要更新かを判断する。zip のヘッダ箇所だけで判断可能にすることで無駄な通信を行わないようにしている。

zlib ^[12]

• zip のヘッダについては自前で処理が可能だが、アプリ更新の際、圧縮されたデータを展開する為に zlib を使用。

ループ再生 ^[13]

• 時間の正確さを重視した作りを念頭に。
  • ループ位置に巻き戻る処理では時間を止めずシームレス（ギャップレスっていうのかな？）に処理する。

Webサーバー ^[14]

• 自前サーバーで頑張るのは何かとコストがかかる為、よくある単純なレンタルサーバーで動作出来ることを念頭に置いている。
• HTTPS 通信を基本にしている。Facebook や twitter の OAuth 認証を利用している手前もあるし、XOOPS 標準のユーザー認証もあり得るので、平文は避けといたほうが無難。
• 現在はさくらのレンタルサーバーを利用している。SSL証明書もさくらインターネットが用意しているものを利用。

XOOPS Cube ^[15]

• Web サーバーの土台として利用。
• ユーザー(アカウント)の管理は Web サーバー(XOOPS Cube)の管轄。
• 自作の Magome 用の管理モジュールを組み込んである。
• UserAgent を見て Magomeサーバーおよびクライアントからの接続の場合には、それぞれのアプリ向けに適したページを出力する。