MonoGameでBGMを再生する
目次
問題点:Songクラスが不安定
2016年1月時点のMonoGameでBGMを正攻法で再生するのは色々と難しいようだ。
- MonoMacでは「Content.Load<Song>メソッド」でクラッシュする。
- Androidでは「MediaPlayer.Playメソッド」でクラッシュするらしい。
- 動かない報告のあった機種
- Nexus 6P
- Nexus 9
- MOTOROLA XOOM Wi-Fi TBi11M
- Redmi Note 3
- 動く報告があった機種
- AQUOS PHONE Xx 302SH
- Xperia ZL2 SOL25
- 動かない報告のあった機種
ググってみた結果、以下のコードで動くような気がするが、stackoverflow.comによると内部実装に色々と問題があるのでSongクラスは使うなとのこと[1]。
var song = Content.Load<Song>("heaven_BGM_tougou");
MediaPlayer.IsRepeating = true;
MediaPlayer.Play(song);
回避策:SoundEffectクラスで代用する
stackoverflow.comの指示に従い、BGM用のSongクラスとMediaPlayerクラスではなく、効果音用のSoundEffectクラスを使うことでクラッシュ自体は避けられることを確認した。
var song = Content.Load<SoundEffect>("heaven_BGM_tougou");
var backSong = song.CreateInstance();
backSong.IsLooped = true;
backSong.Play();
問題点:ファイルがでかい
ただしSoundEffectクラスを使う方法ではMonoGame Pipelineで生成されるxnbファイルがアホみたいに巨大になる。約3MBのmp3ファイルが約30MBのxnbファイルになるくらい。MonoGame PipelineでQualityプロパティをBestからLowに変えてもファイルサイズに変化はない。
回避策:音質を落としたwavを使う
ファイルがデカイ理由はMonoGame Pipelineにmp3を食わせると最高音質でwavに変換しているためのようだ。
試しにステレオ44kHzのmp3ファイルをモノラル8kHzのwavファイルに変換(約8MB)したものをMonoGame Pipelineに食わせてみたところ、wavファイルとほぼ同じサイズのxnbファイルが生成された。なお変換にはMediaHuman Audio Converter[2]を使った。
事前に音質を落としたwavファイルをMonoGame Pipelineに食わせると良いようだ。
問題点:ARM64でクラッシュする
MonoGame 3.3および3.4かつAndroidかつARM64でSoundEffectクラスを使おうとするとクラッシュする。
回避策2:MonoGame 3.5以降を使う
この問題はMonoGame 3.5で修正されている。
回避策2:ARM v7aを使う
MonoGame 3.5にアップデートするとこの問題は治るが、今度は3DCGのレンダリング周りで従来と異なる挙動になるなど不用意にアップデートできるものではなさそうだ。
そのような場合はMonoGame 3.3などの古いバージョンを使い続け、そのうえでプロジェクトのプロパティからARM64のチェックをはずしてARM v7a向けにビルドすることで回避できる。そもそもAndroidでARM64を使うメリットなど何一つないと思われる上に、簡易的なベンチマークでサクッと測った限りでは速度的な差もない。 現状ではARM64だとLLVMでの最適化も効かないので本当に何のメリットもないと思う。