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/archive%40mail-archive.com
This email sent to [email protected]
