CODEWITHSUNDEEP
xamarin.ioscore-audio
user2680276
user2680276

Reputation: 1

Coreaudio render callback in monotouch

Ok --- am I soooo close to releasing my audio analysis application and I found an issue with monotouch using core audio. Monotouch actually has binding for core audio / remote io and a sample written was by Miguel that works nicely. That works great 99% of the time. The problem arrises where I think the "stop the world" garbage collector occurs during a render callback in coreaudio. At that point we are in managed code so I can thinking that the render callback is not going to return until the gc is finished. As a result, about 1 out of every 160 frames is dropped (approx every 2 to 4 seconds).

So I have three options without the wisdom to know which is a waste of time.

Write the code audio render callback (and all the other core audio interface code) in c. Then I could pinvoke to get the samples as fast as my managed code can analyze it. This would avoid dropped frames even if I get paused for 20 ms. My main question is can I do this with monotouch? Will the core audio callback function get stopped by the gc if it is completely unmanaged? I could then have an unmanaged circular queue that I pinvoke to read data as necessary.

Just tune the gc in some way to be less efficient but with less time of the world paused. If it was always under 5 ms we would probably be safe. I don't know how to do this in xamarin studio. Is it just a bunch of linker options or something?

Use another API. I've tried the input queue API but the latency was terrible. Is there a middle ground?

I know CoreAudio is awesome and all that, but have to admit the Android port of this app was about 100x faster in this area to develop for my needs.

Upvotes: 0

Views: 256

Answers (1)

hotpaw2
hotpaw2

Reputation: 70703

Apple DTS recommends not even using generic Objective C methods in short duration Core Audio callbacks, only deterministic straight C (maybe static dispatch C++). Any dynamic dispatch or memory management can potentially cause audio underflow. So unless you can turn off, or guaranteed deterministically bound, all GC and other memory management inside the Monotouch runtime (doubtful) it's probably not appropriate for real-time callbacks.

That's the cost of low latency audio, especially on older hardware.

Upvotes: 4

Related Questions