好的---我很接近发布我的音频分析应用程序，我发现使用核心音频的monotouch问题。 Monotouch实际上具有核心音频/远程io的绑定，并且由Miguel编写的样本很好地工作。 99％的情况下这很有效。问题在于我认为在coreaudio的渲染回调期间发生“停止世界”垃圾收集器的地方。那时我们在托管代码中，所以我可以认为渲染回调在gc完成之前不会返回。结果，每160帧中大约有1帧被丢弃（大约每2到4秒）。
所以我有三个选择，没有智慧知道哪个是浪费时间。
在c中编写代码音频渲染回调（以及所有其他核心音频接口代码）。然后我可以按照我的托管代码可以快速分析样本来获取样本。即使我暂停20毫秒，这也可以避免丢帧。我的主要问题是我可以使用monotouch吗？如果gc完全不受管理，核心音频回调函数是否会被gc停止？然后，我可以拥有一个非管理的循环队列，我会根据需要进行读取数据。
只是以某种方式调整gc以降低效率，但暂停世界的时间更短。如果总是低于5毫秒，我们可能会安全。我不知道如何在xamarin工作室中这样做。它只是一堆链接器选项吗？
使用其他API。我尝试过输入队列API，但延迟很糟糕。有中间立场吗？
我知道CoreAudio非常棒，而且不得不承认这个应用程序的Android端口在这方面的速度提高了大约100倍，以满足我的需求。
答案 0 :(得分：4)
Apple DTS建议在短时间的Core Audio回调中不使用通用的Objective C方法，只有确定性的直接C（可能是静态调度C ++）。任何动态调度或内存管理都可能导致音频下溢。因此，除非你能够关闭或保证确定性地绑定Monotouch运行时内的所有GC和其他内存管理（可疑），否则它可能不适合实时回调。
这是低延迟音频的成本，特别是在较旧的硬件上。