PresetReverbは特別なんですか。そうですか。

Visualizerのリスナー内でgetEnabledを実行される前にreleaseをしてしまうと、リスナー内でgetEnabledをした際に意味不明なダンプを出力して落ちてしまう。
とくにこれ、OnDestoryやOnPauseなどでやっていると注意、リスナーモードをNONEに設定しても飛んでくるので。
ということなので、Visualizerのインスタンスにnullを設定することで、リスナー内の処理を実施しないようにしました。
いちおう、これで落ちにくくはなった。その後調子にのって、他のAudioEffectも実装し、PresetReverbまで実装したところで、またまた例のダンプが頻繁に発生するようになってしまいました。
内心またかぁ、まったく。。AudioEffect難しい、、もうこれEquqlizerだけ使えるよう程度にしようかなとおもったりもします。

調べていくと、どうやらPresetReverbはちょっと特別らしい。
たしかに、以前からこれ全然効果ないしおかしいなぁとと思っていました。

公式のリファレンスをみると、下記の様に書いてあります。

The PresetReverb is an output mix auxiliary effect and should be created on Audio session 0. In order for a MediaPlayer or AudioTrack to be fed into this effect, they must be explicitely attached to it and a send level must be specified. Use the effect ID returned by getId() method to designate this particular effect when attaching it to the MediaPlayer or AudioTrack.

Creating a reverb on the output mix (audio session 0) requires permission MODIFY_AUDIO_SETTINGS

これみると、PresetReverbはAudioSessionを０で生成しないとだめって言ってる、しかも、その場合、MODIFY_AUDIO_SETTINGSのパーミッションも有効にしないといけないよって。 たしか、ほかのAudioEffectはAudioSessionを０で使うのはDuplicatedになっているので盲点でした。ようするに、PresetReverbだけ特別扱いしないといけないと、、そういうわけです。 現在、ServiceとActivityで処理をしているので、AudioSessionの使い分けはめんどくさいことになりそう。やっぱり、これがまた後々新たな面倒の種になるとと厄介なので、せっかく前回Activity側でもAudioEffectを持つようにしたけど、それはやめて、Service側が持つものだけにし、アクセスはAIDL経由で行うようにしたほうが管理しやすいきがしてきました。 あぁ、めんどくさい。また修正か。。