4

I've been working on a very specific project for iOS, lately, and my researches lead me to an almost final code. I've solved all the extreme difficulties I've found until now, but on this one I don't seem to have a clue (about the reason nor the possibility of solving it).

I set up my audioqueue (sample rate 44100, format LinearPCM, 16 bits per channel, 2 bytes per frame, 1 channel per frame...) and start recording the sound with 12 audio buffers. However, there seems to be a delay after every 4 callbacks.

The situation is the following: the first 4 callbacks are called with an interval each of about 2 ms. However, between the 4th and the 5th, there is a delay of about 60ms. The same thing happens between the 8th and the 9th, the 12th and 13th and on...

There seems to be a relation between the bytes per frame and the moment of the delay. I know this because if I change to 4 bytes per frame, I start having the delay between the 8th and the 9th, then between the 16th and the 17th, the 24th and the 25th... Nonetheless, there doesn't seem to be any relation between the moment of the delay and the number of buffers.

The callback function does only two things: store the audio data (inBuffer->mAudioData) on a array my class can use; and call another AudioQueueEnqueueBuffer, to put the current buffer back on the queue.

Did anyone go through this problem already? Does anyone know, at least, what could be the cause of it?

Thank you in advance.

27 de Abril
  • 117
  • 1
  • 11

1 Answers1

3

The Audio Queue API seems to run on top of the RemoteIO Audio Unit API, who's real audio buffer size is probably unrelated to, and in your example larger than, whatever size your Audio Queue buffers are. So whenever a RemoteIO buffer is ready, a bunch of your smaller AQ buffers quickly get filled from it. And then you get a longer delay waiting for some larger buffer to be filled with samples.

If you want better controlled (more evenly spaced) buffer latency, try using the RemoteIo Audio Unit directly.

hotpaw2
  • 70,107
  • 14
  • 90
  • 153
  • 1
    Thank you a lot, that is exactly the path I was looking for. It took me several hours to rewrite my code using the RemoteIO API, since the documentation and sample codes are not straightforward, and there are a lot of "traps" to understand. But it is finally working, now, and I can actually say that your answer was perfect. There is no delay, but a very stable sequence of about 2.94ms (on an iPhone 4), in the fastest configuration possible. – 27 de Abril Jul 14 '11 at 23:40
  • @27deAbril Can you provide an example? Or did you manage to fix it with AudioQueue? It took me days to understand the problem I have like yours. It fills an internal buffer with 1024 samples and than calls the callback one after another (with queue-buffer of 160 bytes). – AndaluZ May 11 '18 at 08:37
  • 1
    @AndaluZ I'm sorry, but unfortunately it has been too many years and I don't have access to that code anymore. From what I remember, this was only fixed by rewriting the code using the RemoteIO Audio Unit API. – 27 de Abril May 14 '18 at 21:29
  • That's exactly what I'm doing. AudioQueue can't change the internal buffer of CoreAudio. Using AudioUnit with RemoteIO is the only solution. Thnx for your comment. – AndaluZ May 15 '18 at 10:54