So there are actually multiple pieces here, each worth addressing.
First, playback stopping when recording starts was a conscious decision we made on iOS. On iOS, there is something called an Audio Session which applications are required to setup. There are different modes Apple allows developers to pick from, each with different repercussions. We tried to hide these details in Corona and pick the most useful ones. In iOS, you must consciously specify you want to record something. And if you want to playback and record, there is a different mode for that. However, the combo playback and record may come at a performance price. Since usually for recording from a microphone, you don’t want feedback from the speaker, we shut off playback on iOS which should also give you the most performance to actually handle the recording aspect.
The Mac Simulator implementation doesn’t have a notion of Audio Sessions so that is why you see a difference there.
Out of curiosity, would you describe the simultaneous playback and recording case you need? It’s probably legitimate, but we expected most users won’t need this. But maybe you have a case that is more common than we think.
Unfortunately, I think there are only two solutions to this, both of which require us to make changes. We need to either always use playback and record modes for recording which could negatively impact performance for people that don’t need it or we need to expose Audio Sessions which adds complexity to the API. (And Audio Sessions have no meaning on Android.)
Second, the reason that this worked before our new audio engine introduction was actually an implementation fluke depending on undefined behavior by Apple. In reality, it probably should have never worked.
Third, I don’t know why you are seeing a performance slow down. We do have some minor optimizations in the next release, but I don’t think it will affect this. Would you please send us a reproducible test case?
[import]uid: 7563 topic_id: 5109 reply_id: 16862[/import]
