I'd propose this: battery bench doesn't use the plugin buffer at all, but steals his 512bytes from the main ram. So, stop playback -> start battery bench -> start playback again. There's also other plugins doing this. I assume those 512 shouldn't have a huge impact on the battery life. But this way, you couldn't only change settings while running a battery test (given that the settings menu is a plugin), but also could messure plugins impact on the battery life.
The battery_bench callback mechanism works already quite nice and simple, if settings move to a plugin and tries to change a setting while battery_bench is running, the user will get notified. Why alter current behaviour and "steal" from audio buffer when the plugin itself is supposed to keep track of battery runtime without touching anything (most of the times at least)? Hi. because, what happens if a user wants to change a setting that impacts on how music is played back they wouldn't be able to do it if settings was turned into a plugin and battery bench was left in its current state. They would therefor have to disable battery bench, change the setting, run battery bench again and restart playback, you must admit that would be a very annoying situation.
