Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
Created attachment 4633 [details]
Example of bug --- run and look at console window.
Is there any solution to this problem ?
Having the same problem here.
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.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.
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
Is this still an issue? I could not reproduce this using iPhone 5S with iOS 10
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!