Re: High CPU audio drops?
Re: High CPU audio drops?
- Subject: Re: High CPU audio drops?
- From: Cyril Blanc <email@hidden>
- Date: Sat, 26 Dec 2015 06:44:22 +0100
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@hidden> 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@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
_______________________________________________
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