Re: Synchronisation of multiple Audio Queues
Re: Synchronisation of multiple Audio Queues
- Subject: Re: Synchronisation of multiple Audio Queues
- From: Doug Wyatt <email@hidden>
- Date: Tue, 25 May 2010 09:58:50 -0700
Hi,
On May 25, 2010, at 7:51 , Charlie Fuller wrote:
> Hi,
>
> I'm trying to play multiple Audio Queues, in sync, with the ability to pause, resume and skip to a specific location on iPhone OS 3.1.3.
>
> Playing back the AQs in sync is fairly straightforward - by giving them all the same AudioTimeStamp to start on. However, one problem I've been struggling with for the past few days is getting paused AQs to resume at a specific time, precisely in sync. The inStartTime parameter of AudioQueueStart appears to be ignored when resuming playback. Is this to be expected?
That is certainly the case in 3.1.3, but I won't be surprised if it is implemented in a future release :-)
> I'm also having trouble skipping each AQ to a specific point, say jumping ahead 2 seconds. My current attempt at this is as follows for each AQ:
> -AudioQueuePause (to temporarily stop playback)
> -AudioQueueReset (to flush out the existing buffers - not at all efficient for short skips but I'm trying to cover all cases here, e.g. skipping ahead 5 minutes or skipping back 10 seconds)
> -Update packet index (based on the desired time point in the audio file to skip to)
> -For each of the 3 buffers:
> -AudioQueueFreeBuffer (to dispose the existing buffers)
> -AudioQueueAllocateBuffer (to allocate new buffers starting at the new packet index)
> -AudioFileReadPackets (to load the audio data from disk)
> -AudioQueueEnqueueBuffer (to queue the buffer ready for playback)
>
> I've tried replacing AudioQueueEnqueueBuffer with the extra parameters version for the very first buffer and specifying a start time but this has given unpredictable results.
That *ought* to work, but it could be that you are running into the same issue that someone posted about last week. I'll find that and reply to it next...
If you like, please file a bug report with details.
> I've looked into AQ timelines but don't think they'd solve these problems, although may be worthwhile implementing anyway.
no, that's all about observing HAL overloads (which might be symptoms of a default device change)
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