Hello This happens also when you do not have time to read samples in time. To fix this review pre-load buffers size and audio buffers size Use Sata III interfaces with SSD to put your samples
Do not use USB 2 and Firewire disks to put your samples Best Cyril > On 24 Dec 2015, at 00:35, Take Vos <[email protected]> wrote: > > Hi, > > I use audio HAL in my application. When customers have the issue of "I/O > cycle overload” from CoreAudio it has never been an issue of a CPU overload. > Most of the time it is due to a bad USB or Firewire cable that has dropped a > packet of samples (real time audio does not get retransmitted) this is > reported as dropped samples between interface and application. > > The description of that Core Audio exception is less than clear. > > This can be a very intermitted problems like once a week, several times a > day, every second; each time it was a bad cable. > > Cheers, > Take > > >> On 23 December 2015, at 23:17, Ross Bencina <[email protected]> >> wrote: >> >>>>> Does it sound *plausible* that a sudden spike in CPU could cause >> audio to >>>>> stutter & drop? >> >> To me it seems unlikely if "sudden spike in CPU" is the only problem. >> >>> Sure. If the code responsible for filling audio buffers never gets >>> scheduled on the CPU, then those audio buffers will contain garbage >>> and you'll get stutter. >> >> *if* the thread never gets scheduled it is plausible. But that's a big "if". >> >> A correctly written proc should get scheduled. Core audio buffer fill >> happens in the Mach real-time scheduling band. It's difficult to imagine >> that networking code would get priority (unless perhaps it's also been >> scheduled in the real-time band?). >> >> That said, if the thread is implemented incorrectly, then there could be >> other causes: >> >> - There might be priority inversion with a thread of equivalent or lower >> priority to the SSH tasks. This could happen if you were acquiring mutexes >> in the real-time thread, or calling code that acquires mutexes. >> >> or >> >> - The real-time thread(s) had been demoted out of the real-time band >> (e.g. because they exceeded their time quota). >> >> >> The attacks might be causing some kind of CPU-wide performance degradation >> (e.g. killing some or all CPU caches, or performing excessive LOCK prefix >> instructions). That might degrade the audio thread performance enough to >> cause the demotion I mentioned above. A rough way to check would be to track >> whether your audio proc exceeds its time quota (some % of the buffer period). >> >> >> Just my two cents, >> >> Ross. >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Coreaudio-api mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/coreaudio-api/take.vos%40vosgames.nl >> >> This email sent to [email protected] > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/cyril.blanc%40numericable.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
