Re: Audio stuttering under CPU load
Re: Audio stuttering under CPU load
- Subject: Re: Audio stuttering under CPU load
- From: William Stewart <email@hidden>
- Date: Wed, 10 Feb 2010 17:34:32 -0800
On Feb 10, 2010, at 3:23 PM, Bertrand, Pierre-Luc wrote:
Oh THANKS !! That post was awesome, it raised many bells from:
"You can do quite a lot of processing in an IOProc. I resample
the audio, which is quite heavyweight."
I don't know why but the fact that now I memcpy my buffer into
AudioBufferList *ioData->mBuffers[0].mData with the provided len
ioData->mBuffers[0].mDataByteSize, everything is smooth.
I used to change the pointer to be pointing to my own buffer and
change
the
mDataByteSize to be the size of my buffer and it caused the
stuttering.
yes. that would be bad
The way I/O generally works for core audio is that it is a pull model.
So, for audio units, the HAL on the desktop, the I/O you are asked to
complete is a given size that represents a given period of time. The
number of samples (and thus the number of bytes) is a procscribed
amount that you have to provide - if you don't have enough you do
something (!), if you have too many, you provide what is requested and
buffer the rest for the next cycle.
So, the AU wakes up, it asks you for 512 samples. You have to provide
512 samples.
Normally after finding the issue of a problem you feel happy but not
this one. There is no logical explanation to that behavior. It does
not
feel right...
Since you can resample, I think I will even try to decode in that
IOProc
thread directly to simplify my design.
You can resample, but you resample to the number of requested samples
on output, which can consume a sometimes varying number of samples on
input
Big thanks for all the support you guys provided me.
Pierre-Luc
-----Original Message-----
From: Paul Sanders [mailto:email@hidden]
Sent: Wednesday, February 10, 2010 2:49 PM
To: Bertrand, Pierre-Luc; Ross Bencina
Cc: email@hidden
Subject: Re: Audio stuttering under CPU load
Bertrand, Pierre-Luc wrote:
Now I only lock to signal the processing thread to start
processing a
chunk of 800ms.
Well, I can't really comment on your code because I can't see
it, but the way I play audio is this (and it doesn't stutter):
1. In the processing thread - i.e. the thread preparing the
audio to be streamed - I fill buffers and put them on a queue.
When the queue reaches a certain length, I stall.
2. In the IOProc, I pull buffers from the queue until I have
filled the output buffer passed to me by CoreAudio. Then I
return, remembering the fact that I am part-way through an input
buffer. Each time I consume an input buffer, I signal the
processing thread (I use my own, posix-based primitives for
this, but I'm sure there are other ways).
3. *Absolutely* no mallocs in the IOProc. This includes
instantiating any Cocoa objects (obviously) and, I imagine,
calling NSLog. I found with even one malloc in there, I got the
occasional hiccup.
You can do quite a lot of processing in an IOProc. I resample
the audio, which is quite heavyweight. The key is to be
deterministic about it (i.e. never exceeed a certain amount of
time, per buffer-full), and resampling fits that constraint.
HTH - Paul Sanders.
_______________________________________________
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