Re: High CPU audio drops?
Re: High CPU audio drops?
- Subject: Re: High CPU audio drops?
- From: Take Vos <email@hidden>
- Date: Thu, 24 Dec 2015 00:35:20 +0100
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@hidden> 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@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden