Time stamps and Audiobus

Hi chaps,

My app plays audio while recording from the hardware input. To synchronise the recorded audio with playback I calculate the difference between the audio callback and render callback timestamps. This works perfectly until I load my app into an input slot in Audiobus then the resulting audio is out of sync. When using my app stand alone I get roughly 2290 frames difference between callbacks which is accurate enough to put my audio in perfect sync however If it's loaded into Audiobus as an input I get only a 79 frame difference and my audio is out of sync.

Are the time stamps altered by Audiobus or TAAE somewhere?
Does anyone know of a way to calculate the true timestamp difference when in Audiobus as an input?

Interestingly LoopyHD behaves the same way. If you add it as an input slot in Audiobus and try to record it's own metronome back into the iPad mic then the result is out of sync.

Any help appreciated!


  • Hey @jmarshallhfs. Unfortunately, this is a limitation of Inter-App Audio, the system that Apple forced upon Audiobus a few years ago. IAA doesn't let you associate timestamps with incoming audio like Audiobus 1 did, so there are certain circumstances, like those you describe, where the audio doesn't quite line up. There's no simple solution to that, sadly.

  • edited August 2016

    Thanks @Michael for clearing that up. AUM has a sneaky way to send latency information to the host app via IAA remote control events. See here under "Report latency from IAA node to host": http://lijon.github.io/iaa_latency_comp.html

    Have you considered anything similar for Audiobus or is this not feasible?

  • Actually, Audiobus already handles latency reporting in a similar way (for both senders and filters), although we are also considering supporting Jonatan's scheme for compatibility.

    Unfortunately though, this is actually a different thing to input timestamps. While it's possible to query the current audio session's input and output latencies, these don't actually give you a mapping between the input timestamp and the output timestamp (the one that IAA/Audiobus actually has access to). This is due to the vagaries of audio IO processing, but in short, merely reporting latency doesn't get us a robust solution.

  • edited September 2016

    Hi @michael, thanks for all your help!

    I've discovered that if I use TAAE's 'setAudiobusSenderPort' function then my time stamps are not altered and I get accurate timing when connected to an IAA host. I presume this is because TAAE is buffering the audio and therefore it's not being pulled directly by the host.

    This great but now I can't get any information back from the IAA host, such as transport sates and tempo/beat info. Basically I need a reference to the audio unit that is connected to the IAA host but I have no idea how to get it. Is it even possible?


  • edited September 2016

    Alright so as usual it was staring me in the face. Simply, '_senderPort.audioUnit' after initialising the audio unit with 'setAudiobusSenderPort'. Now I can receive HostCallbackInfo callbacks!

    I was wondering if there are any downsides to using ABSenderPorts in this way? I noticed on another thread that a user was having trouble when connected to Cubasis. Apparently Cubasis was running the IAA node faster-than-realtime thus causing the buffers in the AEBlockChannel to run dry.

    Here's the thread:


Sign In or Register to comment.