07/21 02:34 #世界樹5 初プレイ殺しは今回も健在…のはずだったんだけど、前衛2人ブッ叩かれてヤバいところまではいったものの今回は運よく生き残ったままLv5まで達してしまい…(苦笑
(gozo)
07/21 14:52 とはいえ、いたずらに忌避型アイテムを設置して遊ぶ者が現れるのは想像に難くないし、かといって設置に適当な障壁を設けると「設置できない」をサポートするコストも馬鹿にならない…(苦笑 https://twitter.com/jiro_aqua/status/755999443770413056
(paso)
07/21 15:06 「サウンドデバイスへオーディオデータを積むコールバックハンドラではファイル読み込みやメモリアロケーションなどの高コストな処理を行うべきでない」というのは常識だけど、それとスレッド処理を勘違いしてないかな、この記事は…
(puno)
07/21 15:36 iOS/OSXだとAudioUnitが最下層のオーディオバッファ充填コールバック型ということになっていて、ここでのオーディオデータ生成に高コストな処理を入れてはいけない、という話。この記事で出てくるライブラリもこの構造になっている (kiha)
07/21 15:38 このコールバック部からでアクセスされる第2オーディオバッファに、外からスレッドで高コストな処理を使ってオーディオデータを注ぎ込む構造になっている…が、しかしなぜかこの記事では「オーディオのスレッドでは○○しない」という話になってしっており、食い違いが発生している…と
(kire)
07/21 15:42 iOS/OSXだと、OpenALを使うと「オーディオバッファ充填コールバックはOpenALが受け持ち、第2オーディオバッファの監視と処理だけをOpenAL APIで書けばいい」ようになっているので、「○○してはいけない」系の話は考えなくてよくなる…ともいえる
(kuka)
07/21 15:55 第2オーディオバッファは、タイミングにシビアな第1オーディオバッファの要求を安定して受け止めるだけの余裕として、数倍の容量が必要になる。最低でも2倍、普通は4?8倍程度。第1バッファが64サンプルなら、第2バッファは256?512サンプル
(keza)
07/21 16:00 この容量の大きさが「遅延量」になる。48kHzだと512サンプル≒10msec程度で、不自然さを感じさせないぎりぎりくらいの値。なおAndroidだと第1オーディオバッファが512サンプル以上の端末が昔は多く、これが「Androidがオーディオアプリを苦手としている理由」のひとつ
(kore)