Hi,
No, I have more constraints there. It would have to take in and convert any sample rate and any other characteristics that might come in (such as interleaved, compressed, stereo, vbr, etc), test across all those kinds of stuff passing through, and without having any effect on performance or overhead including on old phones and including in RapidEars. From my perspective the way to fix that annoyance in the long term is to figure out how to successfully decouple the input callback from the output callback because that decreases the overall complexity and the complexity in this particular case, but that seems to be sensitive core audio code and extremely underdocumented, so I haven’t gotten anywhere with it yet if not for a lack of trying recently.
This is a little outside of the scope of support that I offer because it’s getting pretty low-level and questions in this area usually lead to new questions (which is reasonable and there’s absolutely nothing wrong with it, but there aren’t necessarily the resources on my end to talk it through a lot). I completely understand that it’s important to your spec and I’m sorry I can’t support that feature right now.