코어 오디오 콜백은 매우 낮은 대기 시간이 필요합니다. 제 경우에는 한 번에 512 개의 샘플을 요청합니다. 44100Hz에서는 콜백이 최대로 실행될 수 있고 실행하려면 11.6 밀리 초가 소요될 수 있습니다.MonoTouch를 Core Audio와 안전하게 사용할 수 있습니까?
이제 가비지 수집을 이해하면 각 수집주기마다 VM이 모든 스레드를 중지해야합니다. 그런 다음 가비지 콜렉션주기가 Core Audio 콜백을 방해하고 고장을 일으킬 수 있습니다.
그렇다면 MonoTouch의 Core Audio를 사용하는 것이 안전하지 않습니다.
내 가정에서 정확합니까? 또는이 모두가 잘못 되었습니까?
코어 오디오 렌더 콜백은 실시간 스레드에서 매우이라는 마감 시간에 대해 엄격하게 호출됩니다. 그것의 소리에서, 때때로 당신은 렌더 콜백의 시간 여유를 초과하고 잘려 버린다 (== 글리치). MonoTouch에 대해 많이 알지는 못하지만, GC 지연이 범인이라는 추측은 매우 확연한 결론처럼 들립니다.
하는 당신에게 오디오 콜백이 렌더링 얼마나 엄격한 코어의 감각을 제공하기 위해, 여기 그 맥락에서 수용 할 수없는 몇 가지의 디스크
인해 코어 오디오의 아키텍처로, callbac 렌더링 ks는 제작하는 오디오가 들리기 바로 전에 트리거 될 것입니다. 따라서 GC가 잠시 중단 되더라도 가청 글리치가 발생할 수 있습니다.
아니오. MonoTouch VM은 코드를 결정적으로 실행하는 것으로 보장되지 않습니다. 실시간 오디오 콜백에는 모든 OS 호출 및 모든 인터프리터 오버 헤드를 포함하여 시간에 엄격하게 제한 될 수있는 코드 (일반적으로 컴파일 된 네이티브 C)가 필요합니다.
제안 해 주셔서 감사합니다. 내가 해결 한 콜백에 몇 가지 문제가 있었지만 이제는 오디오가 잘 돌아갑니다. 그러나 앞으로 더 복잡한 앱에서 GC가 수집을 위해 핵심 오디오 스레드까지 중단시킬 수 있다고 생각합니다. 이것은 C/C++에서 분명히 문제가되지 않기 때문에 이는 단지 탐색적인 질문 일뿐입니다. –