07/21 00:25 「どこに何のコマンドがあるか」は従来を継承しているので個人的にはプレイには困ってないのだけど、褒められるUIではないわな… https://twitter.com/tiny_yarou/status/755765959755825152
(moso)
07/21 02:34 #世界樹5 初プレイ殺しは今回も健在…のはずだったんだけど、前衛２人ブッ叩かれてヤバいところまではいったものの今回は運よく生き残ったまま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 このコールバック部からでアクセスされる第２オーディオバッファに、外からスレッドで高コストな処理を使ってオーディオデータを注ぎ込む構造になっている…が、しかしなぜかこの記事では「オーディオのスレッドでは○○しない」という話になってしっており、食い違いが発生している…と
(kire)
07/21 15:42 iOS/OSXだと、OpenALを使うと「オーディオバッファ充填コールバックはOpenALが受け持ち、第２オーディオバッファの監視と処理だけをOpenAL APIで書けばいい」ようになっているので、「○○してはいけない」系の話は考えなくてよくなる…ともいえる
(kuka)
07/21 15:55 第２オーディオバッファは、タイミングにシビアな第１オーディオバッファの要求を安定して受け止めるだけの余裕として、数倍の容量が必要になる。最低でも２倍、普通は４?８倍程度。第１バッファが64サンプルなら、第２バッファは256?512サンプル
(keza)
07/21 16:00 この容量の大きさが「遅延量」になる。48kHzだと512サンプル≒10msec程度で、不自然さを感じさせないぎりぎりくらいの値。なおAndroidだと第１オーディオバッファが512サンプル以上の端末が昔は多く、これが「Androidがオーディオアプリを苦手としている理由」のひとつ
(kore)
07/21 16:04 @AoiMoe 普通はサンプル通りに作ると「オーディオスレッドはコールバックを登録するスレッドから新たに作成」になっているはずなんですけどねぇ…
(sase)
07/21 16:34 なお、この話をX68のPCM8に置き換えると「オーディオバッファコールバック＝DMA転送終了割り込み」「第１オーディオバッファ＝割り込みでDMA転送するPCMバッファ」「第２オーディオバッファ＝次にDMAに設定するPCMバッファ」「第１バッファ量＝96」「第２バッファ量＝２倍」
(seho)
07/21 16:41 で、第２バッファへの充填の際に「８本のADPCMバッファから96サンプルずつをデコードして全部加算、再びADPCMに変換して第２バッファへ充填する」という処理を行っていたということに相当する
(sose)
07/21 16:51 ちなみに、今時のDAWで使われているリアルタイムオーディオ処理はPCM8と比較して、「１トラックあたり２倍のチャンネル×数倍の精度×数倍のサンプルレートのデータ」に対して「数十倍の演算処理」を「十倍以上の本数のトラック」分だけ処理することに相当する。あんまり変わらないのよ :D
(tane)
07/21 16:58 (
@CMOStone)
@gorry5 今時のDAWの場合、ストリームにしろソフト音源にしろ全ての音が一旦CPU処理下に入るので、「システム自体が持つ、音源同士の発音遅延」はゼロですが、PCM8を使い始めた頃はFMパートに対する遅延が気になりました。
(tito)
07/21 17:09 @CMOStone 今時のPCだと、たとえばGIMICとソフト音源をリアルタイム同期させようとしたら、同じような（あるいはもっと大きい）遅延問題が発生することになります… :D
(teke)