前のエントリで発生していた音飛び問題が解決。

原因はインタリーブのデータを非インタリーブに変換する処理が間に合ってなかった模様。

この処理はNSFの再生でも行われてるし、その程度で処理落ちするか？って気もするが、全てインタリーブで処理するようにしたら奇麗サッパリ解決した。

疑ってごめんね、ExtAudioFileたん。

本腰を入れてMac用のオーディオプレーヤーを作成中。足掛け3年位作り続けてるけど、今回は本気。もりもり機能実装中・・・と行きたいところだが、ExtAduioFileを使った各種オーディオファイルの再生で、たまにノイズが出るバグが取れなくて苦悩中。

Core Audioのレンダーコールバックで要求してくるサンプル数を多めにとってみたが、若干の改善が見られるも解決には至らず。それならばと、デコード部分を別スレッド化して非同期でバックバッファを埋めるようにしても、これまた有意な改善は見られず。バッファのロックが足かせになってるかも？と思い、急ごしらえでバッファ2枚を使ったスワップ式にしてみても駄目駄目。

開発機は4年前のMacBook Proだけど仮にもCore 2 Duo 2.4GHzのマシンだから、例えデバッグビルドだとしても、たかがAAC程度のデコードで処理落ちするとは考えられない。そもそも、ExtAudioFile自体は最適化の有無の影響は受けないだろうし、処理中もまだまだCPUの余裕はある。

NSF（NES Sound Format:ファミコンのサウンド形式）の再生は問題なく出来てるから、ネックになってるのはExtAudioFileとしか考えられないんだよなぁ…。

むーん・・・分からん。

次はCore Audioに渡すフォーマットを32bit Floatの正準フォーマットにしてみるとしよう。

会社でこんなソースを見かけた。

class Hoge
{
public:
    static Hoge *Instance;
    static Hoge *getInstance() { return Instance; }
 
    Hoge() {
        Instance = this;
    };
 
    void initialize() {
        if (Instance == 0) Instance = new Hoge;
    }
    （略）
};
 
// シングルトン
static Hoge hogeInstance;
 
void doSomething()
{
    hogeInstance::Instance->func();
}

見かけたというか、同じ仕組みのクラスがあっちこっちに散らばってた。念のために言っておく、コードはこれで間違いない。何度も見直したからね。

色々と突っ込みどころはあるけど、まず、シングルトンを想定してるのにコンストラクタをpublicで書いちゃう男の人って……。せめて多重生成検知のassertくらい入れようず。

いやいやいや、グループ会社内で（自称）一番技術力が高いと公言してるところの、仮にも俺より高給取りで優秀なプログラマが書いたコードだ。きっと俺なんぞには考えもつかない、深遠なる理由があるに違いない。

でも、色々と考えてみたけど、やっぱり何がしたいのか解らなかった。しかし、メンバ変数を触らないメンバ関数は、クラスの実体が無くても正常に呼べるって事は解った（実験済み）。つまり、上のクラスのinitialize()は期待通りの動作をする。これがC++の仕様の範疇かどうかは知らない。

静的メンバ関数がヌルポで呼び出せる（static_cast<Hoge*>(0)→staticFunc();）のは知ってたけど、メンバ関数も大丈夫だとはねぇ…。よーく考えてみれば、確かにメンバ関数はそのクラスで共用だから、関数の実体は静的に存在してるだろうから呼べてもおかしくないはない。でもやっぱり気持ち悪い。

Mac mini鯖に繋いでるデータ置き用HDDがぶっ壊れた。ディスクユーティリティで修復を試みるも「Bツリーが壊れてて直せない」的なエラーで修復不能だった。

「それでもTimeMachineなら・・・TimeMachineなら何とかしてくれる・・・!!」と思ってバックアップを除いてみたら、最新のバックアップは2009年7月2日とか言ってるの。え？何それ？バカなの？死ぬの？

fsckを直接叩いてみると、BAD SUPER BLOCK: MAGIC NUMBER WRONGだとかLOOK FOR ALTERNATE SUPERBLOCKS? [yn]とか言われ、代替ブロックを探すも見つからず、newfsを使った方法でもダメで、もはやお手上げ状態。

壊れたHDDにはそれほど重要なデータは入ってないから、もし本当にデータが飛んだとしてもそんなに痛くはない（夜のお供（自重汁）が減る程度で済むwある意味一大事ではある）が、諦めるのも何なのでDiskWarrior 4をポチった。

結果、いとも簡単に修復完了。1分も掛かってないんじゃなかろうか。

そんなわけでDiskWarriorは神。それに引き換えDrive Geniusは………買ってはみたものの、どうすんのよこれ………。

MacPortsでSubversion 1.6を入れただけでは、Xcodeから上手く使えない（システム標準の1.4が使われてしまう模様）ので、使えるようにするメモ。

…と言っても、単にコマンドとライブラリを置き換えてるだけ。

MacPortsから入れる。variantsは適当に。

sudo install subversion +bash_completion+mod_dav_svn+tools+unicode_path

cd /usr/bin
 
#一応前のコマンドを退避
sudo mkdir svn_old 
sudo mv svn* svn_old
sudo mv apr-1-config svn_old
sudo mv apu-1-config svn_old
 
sudo ln -s /opt/local/bin/svn* .
sudo ln -s /opt/local/bin/apr-1-config .
sudo ln -s /opt/local/bin/apu-1-config .

元からあるシンボリックリンクは、可能な限りそのまま活用する方針で。

cd /usr/lib
sudo mkdir svn_old
sudo find . -regex ".*libsvn_.*-.*1\.0\.0\.0\..*" -exec mv {} svn_old \;
sudo mv libapr-1.0.2.7.dylib svn_old
sudo mv libaprutil-1.0.x.x.dylib svn_old # バージョン番号を失念してしまったので、適当に補完して下さい。
 
sudo find . -regex ".*libsvn_.*-.*1\.0\.0\.0\..*" -exec rm {} \;
sudo rm libapr*
 
sudo find /opt/local/lib -regex ".*libsvn_.*-.*1\.0\.0\.0\..*" -exec ln -s {} . \;
sudo ln -s /opt/local/lib/libapr-1.0.3.5.dylib .
sudo ln -s libapr-1.0.3.5.dylib libapr-1.dylib
sudo ln -s libapr-1.0.3.5.dylib libapr-1.0.dylib
sudo ln -s /opt/local/lib/libaprutil-1.0.3.7.dylib .
sudo ln -s libaprutil-1.0.3.7.dylib libaprutil-1.dylib
sudo ln -s libaprutil-1.0.3.7.dylib libaprutil-1.0.dylib

swingとかperl用のモジュールが足りてないような気がするけど、うちでは関係なさそうなので気にしてない。無いと困るって人は、上手い事対処して下さい。

SubversionのサーバとしてMac OS Xを使用し、svn+sshでアクセスする場合はサーバ側でも同様の置換を行う。