Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

I have an app in which I use an AudioTrack in streaming mode to play dynamically generated audio. The app doesn't have to respond instantaneously to inputs, so the latency issues don't bother me for that side of the program.

The problem is that I have an animation that needs to be as precisely 'in-sync' as possible with the audio and it seems that different devices have different amounts of time between when the AudioTrack stops blocking the write() call and asks for more data, and when that audio is played from the speaker.

My current solution gets me most of the way there -- I count the number of frames I've passed in to the AudioTrack so far, and compare it to getPlaybackHeadPosition() . It looks basically like:

long currentTimeInFrames = 0;
while(playingAudio) {
  currentTimeInFrames += numberOfFramesToWrite;
  long delayInFrames = (currentTimeInFrames - audioTrack.getPlaybackHeadPosition());
  audioTrack.write(frameBuffer,0,sampleSize);
  doAnimationAfterDelay(delayInFrames);
However, there's still some latency that getPlaybackHeadPosition() doesn't seem to account for that varies by device.
Is there a way to poll the system for the latency of the AudioTrack?
API level 19 adds a method in AudioTrack called  getTimeStamp(). From the documentation:
Poll for a timestamp on demand.
If you need to track timestamps during initial warmup or after a routing or mode change, you should request a new timestamp periodically until the reported timestamps show that the frame position is advancing, or until it becomes clear that timestamps are unavailable for this route.
You specify an AudioTimestamp object as the function's parameter and it will fill in the most recently "presented" frame position along with its "estimated" timestamp in nanoseconds. The nanosecond value corresponds to the millisecond value returned by SystemClock.uptimeMillis().
You can then determine the latency by figuring out when you wrote that particular frame to AudioTrack vs. when getTimestamp() thinks it actually presented. I have found this method to be more accurate than the other methods mentioned above.
You have to be careful though. The documentation says getTimeStamp() is not supported on all platforms or all routes. You can determine if the call was successful by checking the boolean return value. I have found with the devices I have tested that the function returns false until audio begins presenting, and then subsequent calls return true. I have only tested with AudioTrack in STREAM_MUSIC mode. Your mileage may vary.
                Thanks for sharing! Can you explain more about how you actually calculate the latency? Do you store a list of (frame,time) pairs when writing into the AudioTrack and then compare them against getTimestamp later? How often do you call getTimestamp?
– tmm1
                Mar 29, 2018 at 22:55
                @tmm1 -- (sorry for not responding sooner.) I have a latency calculation I am using in my app. However, I'm not convinced that it is correct, so I haven't posted it yet. I want to do some more research and maybe tweak my solution. I'll update my answer when I do.
– josmith42
                Jun 5, 2018 at 1:34
                getTimeStamp(1) return value corresponds to System.nanoTime(), not SystemClock.uptimeMillis(). See here: developer.android.com/reference/android/media/AudioTimestamp
– Stéphane
                Sep 1, 2018 at 8:29
Consider driver's latency. There's hidden function AudioManager.getOutputLatency(int) to get this.
Call it like this:
AudioManager am = (AudioManager)getSystemService(Context.AUDIO_SERVICE);
   Method m = am.getClass().getMethod("getOutputLatency", int.class);
   latency = (Integer)m.invoke(am, AudioManager.STREAM_MUSIC);
}catch(Exception e){
I get about 45 - 50 ms on different devices.
Use the result in your calculations.
                There is another hidden method AudioTrack.getLatency that is more accurate, since it lives on the AudioTrack instance and thus can account for hardware/route-specific latency as well. It can be invoked in a similar fashion via reflection: developer.amazon.com/docs/fire-tv/…
– tmm1
                Mar 29, 2018 at 22:51
You should take into account the buffersize you passed along into the AudioTrack creation.
final int minBufSize = AudioTrack.getMinBufferSize(Application.PLAYRATE,
AudioFormat.CHANNEL_OUT_STEREO, AudioFormat.ENCODING_PCM_16BIT);
out=new AudioTrack(AudioManager.STREAM_MUSIC, Application.PLAYRATE, 
AudioFormat.CHANNEL_OUT_STEREO, AudioFormat.ENCODING_PCM_16BIT, minBufSize, 
AudioTrack.MODE_STREAM);
extraLatencyFrames = minBufSize/4;
                Hmm.. now that I think again of it. It would be weird if that minimum buffer size was not accounted for in the head position.
– user458577
                Sep 10, 2013 at 13:28
Okay, this is the key. First you need to extend the Audiotrack class, and then use the getNativeFrameCount to have an approximation on the latency involved in the native side of things.
class MyAudioTrack extends AudioTrack
    public MyAudioTrack(int streamType, int sampleRateInHz, int channelConfig,
            int audioFormat, int bufferSizeInBytes, int mode)
            throws IllegalArgumentException {
        super(streamType, sampleRateInHz, channelConfig, audioFormat,
                bufferSizeInBytes, mode);
        System.out.println("Native framecount "+getNativeFrameCount());
    public int getFrameCount()
        return getNativeFrameCount();
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.