Re: Core Audio playback precision on iOS devices (and simulator)
Re: Core Audio playback precision on iOS devices (and simulator)
- Subject: Re: Core Audio playback precision on iOS devices (and simulator)
- From: Antonio Nunes <email@hidden>
- Date: Sat, 17 Jul 2010 06:01:08 +0100
On 16 Jul 2010, at 21:56, Jeff Moore wrote:
> I'll admit to having some trouble deciphering your code, but the busy loop in the the driver function isn't going to yield particularly great timing. At best, you will have an error that is going to average about half the duration of the IO cycle (well, given the short sleep period, probably much less then that) plus scheduling latency.
Thanks for the elaborate explanations Jeff.
I'm not sure I understand, especially in light of what you write later, where you appear to confirm that I am placing the ticks at sample perfect time. Since the busy loop runs well ahead of the render proc, and keeps the buffer nicely filled, I don't see how the busy loop would cause an error.
> But it's unclear if that will really matter much. It looks like the goal is to keep at least one buffer on the stack so that the render proc has something to handout. In that respect, it should probably be OK. It will fall down if the thread executing the driver function ever has a scheduling latency larger than the duration of the IO cycle, though. Not a common occurrence, but it could happen if the system was particularly busy. You could fix it by keeping at least one buffer queued at all times.
Although I don't believe this is likely to be an issue, or at least not unless *very* rarely, what do you mean by "keeping at least one buffer queued at all times"? Do you mean using an audio queue?
> True. It appears that modulo a catastrophe, this code will play continuous data.
In my testing it does indeed.
> I think the issue here is one of expectation. You are expecting the hardware to run at the nominal rate. The fact is few audio devices will run at their nominal rate. Nearly all of them will run a little faster or a little slower than nominal.
I understand that clocks between devices may drift, but I would have expected the margin of error on iOS devices to be in the range of microseconds, not milliseconds per minute. I'm surprised indeed that the error is this significant.
I should make clear my goals with this code: I do not need to sync between multiple devices. I simply need to get the best possible timing accuracy. Do I correctly conclude from your comments that I can not get greater accuracy than what I'm achieving currently (where each tick is placed with single sample precision)?
>> I would have thought that if I place the sample with absolute precision in relation to the sample rate (44100), that I should then see (hear) that precision reflected during playback.
>
> Actually, I'd argue that you are. The fact that the audio signal is continuous shows that. I think you just had the wrong expectations about what you were going to see with your test.
Yes, I suppose I should then just give up on trying to achieve greater accuracy. Although I will have to run some more tests to make absolutely sure, it's interesting that, from past tests, older iPhones and iPods, like the iPhone 3G and 1st gen. iPod, appear to run measurably more precisely than the 3GS and iPhone 4, at least where this type of timing is concerned.
António
--------------------------------------------------------
Today you are You, that is truer than true.
There is no one alive who is Youer than You.
Today I am Me, and I am freer than free.
There is no one alive who is Me-er than Me.
I am the BEST I can possibly be.
--Dr. Seuss
--------------------------------------------------------
_______________________________________________
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