RE: Audio stuttering under CPU load
RE: Audio stuttering under CPU load
- Subject: RE: Audio stuttering under CPU load
- From: "Bertrand, Pierre-Luc" <email@hidden>
- Date: Tue, 9 Feb 2010 16:07:17 -0500
- Thread-topic: Audio stuttering under CPU load
Hi,
Thanks for the reply. I considered your proposal and modified my locking
mechanism.
Now I only lock to signal the processing thread to start processing a
chunk of 800ms. I use a queue that does not lock but rather base its
concurrency correctness on the atomicity of integer++. I am still
getting the annoying clipping in there. I also use pthread_yield_np()
before decoding each 20ms frames to make sure to relinquish the CPU to
higher priority (the audio unit).
For each call by the audio unit callback, I've measured the time it
takes to execute the function.
2010-02-09 15:56:03.916 TTS[2042:5603] Timing 0: 44.427036
2010-02-09 15:56:03.924 TTS[2042:5603] Timing 1: 8.080006
2010-02-09 15:56:03.930 TTS[2042:5603] Timing 2: 0.420988
2010-02-09 15:56:03.935 TTS[2042:5603] Timing 3: 0.395000
2010-02-09 15:56:03.941 TTS[2042:5603] Timing 4: 0.344992
2010-02-09 15:56:03.949 TTS[2042:5603] Timing 5: 0.343978
2010-02-09 15:56:03.964 TTS[2042:5603] Timing 6: 0.342011
2010-02-09 15:56:03.970 TTS[2042:5603] Timing 7: 0.351965
2010-02-09 15:56:03.975 TTS[2042:5603] Timing 8: 0.348985
2010-02-09 15:56:03.982 TTS[2042:5603] Timing 9: 0.351012
2010-02-09 15:56:03.988 TTS[2042:5603] Timing 10: 0.349045
2010-02-09 15:56:03.993 TTS[2042:5603] Timing 11: 0.458002
2010-02-09 15:56:03.999 TTS[2042:5603] Timing 12: 0.382006
2010-02-09 15:56:04.006 TTS[2042:5603] Timing 13: 0.378966
2010-02-09 15:56:04.012 TTS[2042:5603] Timing 14: 0.389993
2010-02-09 15:56:04.018 TTS[2042:5603] Timing 15: 0.407994
So it roughly takes 0.4 ms to execute once the audio unit is started.
Each of these timings is to get a buffer of 800ms worth of audio. It's
hard to believe that it could cause the stuttering. Could it be causing
it ?
Here is my setup for measuring:
static BOOL firstTimeCB = true;
static float timing[1000];
static int indexTiming = 0;
static NSAutoreleasePool * pool;
OSStatus playingCallback(void *inRefCon,
AudioUnitRenderActionFlags
*ioActionFlags,
const AudioTimeStamp
*inTimeStamp,
UInt32 inBusNumber,
UInt32 inNumberFrames,
AudioBufferList *ioData)
{
if(firstTimeCB)
{
pool = [[NSAutoreleasePool alloc] init];
firstTimeCB = false;
[NSThread setThreadPriority:1.0];
}
NSDate * begin = [NSDate date];
//**** Get the data from the processing thread here ****//
if(numBytesReceived == 0)
{
stopPlayer();
for(int i=0;i<indexTiming;i++)
{
NSLog(@"Timing %i: %f", i, timing[i]);
}
}
NSTimeInterval totalTime = [now timeIntervalSinceDate:begin];
timing[indexTiming++] = totalTime * 1000;
return noErr;
}
Thanks for your time.
Pierre-Luc
-----Original Message-----
From: Doug Wyatt [mailto:email@hidden]
Sent: Monday, February 08, 2010 8:01 PM
To: Bertrand, Pierre-Luc
Cc: email@hidden
Subject: Re: Audio stuttering under CPU load
On Feb 8, 2010, at 15:17 , Bertrand, Pierre-Luc wrote:
> Hi,
>
> I've been struggling over that issue for quite while now. I'm
currently streaming Speex codec audio to the device in realtime and the
network latency is not an issue since I'm currently using wifi. I have a
decoder thread at priority 0.0 which decodes that stream and buffers
pcm16, 8k in 200 ms chunks. When the Audio Unit for the playback call on
the callback to get audio, I get those 200ms chunks to playback so there
are only pointer assignments happening in this callback. But it seems
that because of the CPU spikes incurred by the decoding, it seems the
audio is stuttering at every callback. I can tell by putting an NSLog in
the callback and increasing the buffer size from 200ms to 800ms and it
is very apparent from the log appearing on the screen and the sound
coming out, they are in sync. Commenting out the NSLog statement still
result in the same stuttering. I also re append to the queue of pointer
for the next audio to playback the whole streaming but this time as it
has been already decoded, there are no CPU usage by other threads, and
the audio is smooth playing the same chunks.
>
> Is there a guideline saying to not do any processing while playing
back ? I've read that there was a guideline saying to not do any
processing on the audio unit callback because it causes even bigger
stuttering (I've done the mistake) which is the reason of that extra
thread.
You can certainly do your decoding on another thread; this is what we do
internally with APIs like AudioQueue, AUAudioFilePlayer, etc.
> Did anyone face these issues because I'm now running out of ideas. The
decoding is happening at a rate much faster than realtime so I don't see
why it would do that.
>
> I put in my decoding thread priority 0.0 and on the first callback
from the audio unit, I put the priority at 1.0.
>
Usually the cause of something like this is a priority inversion --
something on the audio IOProc thread is blocking on a resource (e.g.
lock) held by another thread. How are you synchronizing the decoder
thread with the IOProc thread?
Doug
_______________________________________________
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