Thanks for the input everybody. I should clarify that I’m simply playing regular ol’ video files using Cocoa’s AVPlayer; nothing spectacular, and the video playback continues unaffected as the audio stutters and drops. It’s incredibly odd.
Oh, and audio is being outputted through the Mac’s headphone port; not external audio interface via USB/FireWire, etc. I’ve stopped SSH attempts bumping the CPU, just in case they were related, but the issue persists, so now I’m at a loss. Michael 07595247282 > On 26 Dec 2015, at 05:44, Cyril Blanc <[email protected]> wrote: > > 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] >> <mailto:[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 >> >> <https://lists.apple.com/mailman/options/coreaudio-api/cyril.blanc%40numericable.com> >> >> This email sent to [email protected] >> <mailto:[email protected]> > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list ([email protected] > <mailto:[email protected]>) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/michael%40mcneela.net > <https://lists.apple.com/mailman/options/coreaudio-api/michael%40mcneela.net> > > This email sent to [email protected] <mailto:[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]
