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