Where are your video files ? What Mac do you use ? > On 26 Dec 2015, at 16:50, Michael McNeela <[email protected]> wrote: > > 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] >> <mailto:[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] >>>> <mailto:[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] >>>> <mailto:[email protected]>) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/coreaudio-api/take.vos%40vosgames.nl >>>> >>>> <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] >>> <mailto:[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]
