Re: Audio glitches with aach on iPhone when locked
Re: Audio glitches with aach on iPhone when locked
- Subject: Re: Audio glitches with aach on iPhone when locked
- From: Doug Wyatt <email@hidden>
- Date: Wed, 11 Mar 2009 10:50:51 -0700
On Mar 11, 2009, at 9:20 , Neil Mix wrote:
I've been noticing glitches (very short gaps or stutters) in AAC+
(aach) audio on the iPhone, only when the device is locked. Based
on Bill's note from yesterday mentioning that I/O sizes change when
the device is dimmed, I decided to peruse the docs once more and
discovered the kAudioQueueProperty_DecodeBufferSizeFrames property
of AudioQueue. I changed it from the default (66150) to 102400, and
lo and behold it looks like the glitches have decreased dramatically
in number or gone away.
I'm fine with this as a solution, but it feels a bit "magic" to me
-- I don't *know* that the problem is fixed. I'm wondering if
someone can fill in some knowledge gaps for me:
- is this expected behavior? If yes, why doesn't this happen with
AAC or MP3 audio?
It could have to do with the efficiency of the codec.
- is there any way to calculate the correct value for this property,
or is it a judgement call?
Well, like many performance parameters, it's easier to tune
empirically than to try to devise a theoretical model, especially when
dealing with code one doesn't control.
I will say, the default is a function of the sample rate (1.5 seconds).
- the docs say that "A larger buffer provides more reliability and
better long-term performance" (yes!) "at the expense of
memory" (understood) "and decreased responsiveness in some
situations." Decreased responsiveness in what way -- latency before
audio starts? Of the audioQueue to play/pause commands? Of the
device in general? What's my downside risk if this buffer gets too
big?
I think this is a misleading comment in the docs. All it means is that
audio is committed to being played further in advance.
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