Bug 13982 - Dropped frames in CoreAudio render callback
Summary: Dropped frames in CoreAudio render callback
Status: RESOLVED NORESPONSE
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 4.x
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2013-08-14 16:07 UTC by Joseph Broms
Modified: 2017-05-08 20:04 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Example of bug --- run and look at console window. (22.37 KB, application/zip)
2013-08-14 16:15 UTC, Joseph Broms
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED NORESPONSE

Description Joseph Broms 2013-08-14 16:07:40 UTC
I have an application that drops some audio samples about once every couple seconds.  I am using monotouch's core audio bindings and started the code from an example from Miguel.  The render callback is quite slimmed down.  It does a low pass filter and copies the samples to a fixed size circular queue.  There is a lock called to safely copy the memory into the queue and another thread occasionally locks to copy the data out (but then unlocks immediately).  Therefore I do not think the render callback is going blocked by my code unless you could attribute it so some strange priority inversion issue.

If I set the hardware buffer time to 5ms, I get dropped frames about once every 2 to 4 seconds.
If I set the hardware buffer time to 20ms, I never get dropped frames.  I can live with this but wanted to understand what was going on here and perhaps help you design a better solution for your clients.

I recreated the "bug" a slimmed down project.  At first the bug would not appear, but as I started to simulate gc allocations and some processing time, the dropped frames showed up again.  For a baseline I am using the debug build and running it on an 5th generation ipod touch.
Comment 1 Joseph Broms 2013-08-14 16:15:38 UTC
Created attachment 4633 [details]
Example of bug --- run and look at console window.
Comment 2 Michael Lukas 2013-09-26 13:20:06 UTC
Is there any solution to this problem ?

Having the same problem here.
Comment 3 Joseph Broms 2013-09-26 22:05:13 UTC
Fixed it by increasing the buffer size --- I would like to keep it at 5ms, but that is too much to ask for with the current mono runtime.  10ms or 20ms seems to work (my test was done on a 5th gen iPod touch)

			AudioSession.Initialize ();
			AudioSession.SetActive (true);
			AudioSession.Category = AudioSessionCategory.PlayAndRecord;
			AudioSession.PreferredHardwareIOBufferDuration = 0.020f;            

The only fix I see to get back to 5ms is to write the callback in native code to copy the samples your own buffer where it is impervious to gc pauses.  This only works in the case where you only want to record.  If you want to passthrough, your effect is going to need to be native as well because it is still easy to underflow your own buffer if you a realtime gaurentee to execute every 5ms.
Comment 4 Michael Lukas 2013-09-27 06:43:09 UTC
My problems are pretty extreme when using 20ms as usual for VOIP.

with around 50-80ms its much better but not fixed 100%

I have "bumps" in my audio when GC runs.

Seems like I have to write the native callback.

Thank you very much
Comment 5 Alex Soto [MSFT] 2017-04-02 04:59:10 UTC
Is this still an issue? I could not reproduce this using iPhone 5S with iOS 10
Comment 6 Timothy Risi 2017-05-08 20:04:20 UTC
 We have not received the requested information. If you are still 
 experiencing this issue please provide all the requested information 
 and re-open the bug report. Thanks!