Re: Audio stuttering under CPU load
Re: Audio stuttering under CPU load
- Subject: Re: Audio stuttering under CPU load
- From: Doug Wyatt <email@hidden>
- Date: Mon, 8 Feb 2010 17:00:40 -0800
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