Re: iPhone OS 3.0 and AudioQueueStart
Re: iPhone OS 3.0 and AudioQueueStart
- Subject: Re: iPhone OS 3.0 and AudioQueueStart
- From: bill luoma <email@hidden>
- Date: Thu, 25 Jun 2009 15:16:07 -0700
On Thu, Jun 25, 2009 at 1:51 PM, Jeff
Schindler<email@hidden> wrote:
> bill luoma:
>>
>> One way I've found around this problem
>> is to call AudioQueueStart(q, NULL);
>> then prime the buffers by manually invoking the callback.
>> On the first prime, create a timestamp
>> and set mFlags = kAudioTimeStampSampleTimeValid,
>> and convert your future mach_absolute_time to sample time
>> then pass that timestamp in to
>> AudioQueueEnqueueBuffersWithParameters.
>>
>> It seems to have more latency than the simple method that works in 2.x.
>>
>> The way I convert future host time to future sample time
>> is with a call to AudioQueueGetCurrentTime and then some math
>> that Bill and Doug posted a while back on syncing two audio queues.
>
> Hi Bill,
>
> We're running into the same issue - have you tried
> FillOutAudioTimeStampWithHostTime? I had tried the method you describe
> originally under 2.2 to no avail, which led me to use AudioQueueStart() with
> a timestamp. I'm now trying to revert back to
> AudioQueueEnqueueBuffersWithParameters w/ FillOutAudioTimeStampWithHostTime
> on the first enqueue, and it definitely delays the playback, but my queues
> are still not in sync. It sounds like you are not getting perfect sync, is
> that correct? I'm worried that Apple has left us with no solution for
> syncing audio queues...
>
> Thanks,
> Jeff
>
Hi Jeff,
I seem to remember having similar experiences
with AudioQueueEnqueueBuffersWithParameters on 2.2.
Or perhaps it worked on the first play of a given track
but on subsequent replays the ' future delay' seemed to increase exponentially
as if there was a bug in the framework that didn't reset the sample time
on AudioQueueStop.
I think FillOutAudioTimeStampWithHostTime
is an inline c++ function that just sets the mHostTime field
of the timestamp struct as well as zeroes out the rest of the struct.
AudioQueueEnqueueBuffersWithParameters only seems to
work on 3.0 with a valid future sample time.
Hence the need to convert host time to sample time.
It was kind of non-intuitive for me when i first tried the conversion,
and maybe that's just the beauty of core audio, but
my future host times are on the order of 500ms.
Let the future host time be 719 ms.
A converted sample time in my logs for 719 ms is 15865.837508 samples.
(using 22050 hz 2-channel pcm).
Now I might think, if i hadn't ever
called AudioQueueEnqueueBuffersWithParameters before,
that the track would actually start
playing at or near sample 15866.
(I can't remember if i actually thought that, I just didn't get it.)
But that is not the case. The framework
seems to 'wait' for 15866 samples to 'go by' and starts
playing at the beginning of the track.
perfect sync? hmm i don't know, i don't have any
nice test equipment/harness/objective criteria
to tell me exactly what that means.
my ear says 3.0 is not as good as 2.2
when i try to sync the same
sound files to each other (slight echo
on 3.0 not observable on 2.2).
but it's acceptable for the iphone
and my current goals.
more latency, yes.
harder to code, yes.
but you didn't ask me if it's fun.
best,
Bill Luoma
_______________________________________________
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