Re: RemoteIO & hardware decoding latency
Re: RemoteIO & hardware decoding latency
- Subject: Re: RemoteIO & hardware decoding latency
- From: Zachary Kulis <email@hidden>
- Date: Wed, 09 Jun 2010 08:14:39 -0400
Thanks for your response Doug. I've performed some additional testing
and determined that there is indeed a fairly strong coupling between
fwrite() and AudioQueueOfflineRender(). My test:
(1) RemoteIO render callback notifies my audio decoder class when it
needs more audio samples. Decoded audio samples are read from an
internal ping-pong buffer.
(2) RemoteIO thread notifies decoder thread to produce more samples once
half of the ping-pong buffer is depleted (via a runloop).
(3) Decoder thread calls AudioQueueOfflineRender() to produce more
samples and store them in the ping-pong buffer.
(4) A third worker thread is set to run in an infinite loop. Here's
where it gets interesting: if the infinite loop performs a continuous
write to disk, i.e.
while (1) {
fwrite(...) // 2048 samples to disk
usleep(50);
}
the AudioQueueOfflineRender() call may occasionally take 1 second to
produce samples. Nominally, it takes roughly 100 ms to do so. However,
if I change the infinite loop to do some mathematical operation (i.e.,
no file write), then the offline render call never takes more than the
nominal 100 ms.
So what is going on behind the scenes that would connect the C
filesystem API to the hardware decoder? Are there spinlocks() being used
in the drivers that serialize these operations? If so, what is special
about ExtAudioFileWriteAsync that bypasses this issue? Most importantly,
are there other potential operations that could lead to unpredictable
behavior when using the hardware decoder?
Thanks,
Zach
> Hi,
>
> If you are decoding into a relative large number (say, 5 or more) of relatively small buffers, and you are doing significant work (like writing a file) in the context of the audio queue buffer completion callback, then it is possible that this work can block the internal operation of the queue's decoder.
>
> You could experiment with decoding into a smaller number of larger buffers. But my favorite way to avoid this entire class of problem is to use ExtAudioFileWriteAsync.
>
> Doug
>
>
> On Jun 8, 2010, at 9:32 , Zachary Kulis wrote:
>
>> I've been dealing with an intermittent issue for some time regarding
>> hardware decoding latency when using the RemoteIO. In my app, I am
>> decoding MP3 files on-the-fly using the hardware decoder (i.e., via the
>> AudioQueueOfflineRender API) and using the RemoteIO to play the decoded
>> samples. In addition, I am queueing the samples in an internal circular
>> buffer (RemoteIO thread) and dequeueing them in a separate worker thread.
>>
>> Usually, everything works fine. However, when I try to log the raw PCM
>> samples to a file on the iPhone/iPod Touch, the AudioQueueOfflineRender
>> function may fail to produce enough decoded audio samples for the
>> current time (thus causing audible "gaps" in the playback). Note that
>> there are no direct dependencies between the RemoteIO and worker
>> threads. The worker is notified (via pthread_cond_signal()) when new
>> data is available in the queue. Samples are dumped to disk only in the
>> worker thread (which should not cause the RemoteIO thread to block).
>>
>> I've done some benchmarking/debugging of the code, and it appears that
>> the AudioQueueOfflineRender() may occasionally take up to 1 second to
>> decode 32 ms of audio samples when logging raw samples to disk. This
>> clearly does not seem correct. My question is the following: is the OS
>> somehow blocked when writing to disk, such that an attempt to initiate a
>> hardware decode via the AudioQueueOfflineRender ()call would also be
>> blocked? Or could the AudioQueueOfflineRender() call somehow be getting
>> blocked midway due to the disk write? I would not expect filesystem
>> access and hardware audio decoding to be codependent operations...
>>
>> Thanks in advance for any insight into this issue.
>>
>
_______________________________________________
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