Latency comes in different flavours, but what we will talk about here is the time delay between succesively recorded tracks. When you have an audio sample on the first track and you record a second track playing along the first one, you want these two tracks to be perfectly aligned. On desktop systems, this problem is taken care of by a good audio system that has facilities like synchronised start of playback and recording, very accurate reporting of play head position and more. Examples of these are ASIO (Windows), Core Audio (OSX) and ALSA (Linux). Also, our own USB audio system has accurate positioning information.
Android however, was made primarily to make phone calls and play your mp3's. It was never made to record audio on such an advanced level as we want. That's why it has no such facilities as described above and we have to correct for latency manually, as far as we possibly can..
If the time delay (latency) between two recordings is constant, we can measure this delay and (automatically) correct for this delay each time we record. Sounds easy! Or perhaps not??
We have done extensive research analyzing the latency on various Android devices and we can only come to the conclusion that if you're lucky, you have a device where latency is reasonably stable, but if you're not, latency can vary between recording takes. What does help though is using OpenSLES and/or newer Android versions (4.2 or higher) and our 'Session latency correction'.
The good news is that when you use a USB audio interface, the latency jitter is minimal (around 0 to 2 milliseconds usually).
To see if latency on your device is constant or acceptibly constant, you can use our automatic latency detector. The first time you record a 2nd track, the app will ask you to perform the automatic latency check. If you have cancelled that or want to run the automatic latency detector again, open the Menu → Help and select Determine latency. Follow the on-screen instructions.
Starting with Audio Evolution Mobile version 3.1.8, there is an option in the app's preferences called 'Session latency correction'. When enabled, this attempts to measure the latency when you first press record after starting the app, by playing and recording a beep and measuring how much delay there was in between. If you do not change sample rate or change from mono to stereo recording, the beep will not play again and the latency will be constant and corrected for on each recording take, which will reduce latency tremendously.
Note that you need to be quiet when this beep is played and need to disconnect any headphones, otherwise the beep is not detected correctly and the wrong latency correction will be applied. You can connect headphones after the beep has been played.
If you want to let the app determine the session latency again in case something went wrong, please restart the app (or possibly force close it if that still does not work). You can also disable the option in the preferences, do a dummy recording, Undo and enable the option again.
Note: you need to choose OpenSLES as 'Audio system selection' in the app's preferences in order to use this feature!
To detect latency manually, we will put a short sine wave (beep) on exactly 00:01 (1 second). Either create your own beep sound in programs like Audacity or download our beep sound here: http://www.audio-evolution.com/downloads/BeepSine1000Hz.wav (you may need to use right click → Save target as… in order to download the file). Put the beep file on your Android device where you can find it later and Import this file in Audio Evolution Mobile using the button at the top left. This will pop up a menu where you choose 'Import sample'. Now browse to the Beep wav file and select it. The audio file will be placed on the first track at 00:00:
In order to move it to 00:01, zoom in fully (with two-finger move), select the Grid option (either a top-row button or menu item in 'Other'), and select 'Beat'. Since we are in a new project, the tempo defaults to 120 bpm, so 0:01 will be perfectly at a beat. Select the Edit mode (the pencil button) and slide the beep sample to 0:01:
DO NOT FORGET TO GO TO THE GRID OPTIONS AGAIN AND SELECT 'No grid'! Save this project for future reference.
Now that we have the sample ligned up, it's time for recording. Make sure the Latency Correction in the preferences is set to 0 (which is the default value if you haven't changed anything). Make sure that the time display says 00:00:000 at the bottom, otherwise slide your finger leftwards on the project overview at the bottom right to get it to 00:00:000. Make sure you unplug any headphones and turn up the volume using the physical volume buttons on your device. It's best to put your device flat on the table, not in your hand, which increases the chance of the microphone recording the speaker output. Make sure you and your room are silent. Press record, wait for the beep to be played and wait a second more. Press stop.
If all went well, you will see the beep recorded on the 2nd track somewhere:
If it's not clearly visible, you could normalize the recorded sample by going back to Move mode, then long-pressing the sample → Offline fx → Normalize. If your sample is completely flat, your mic didn't pick up any signal from the speaker. Put the device on the table, turn the volume to max and try again.
Now make sure the grid is turned off and go into Range mode.
If the recorded beep is BEFORE the original beep: Slide your finger on the recorded track and align the vertical dotted line to the start of the recording and release. Then slide your finger again, but now release at 00:01:000. The latency in seconds can be seen in the time display area at the bottom behind 'L'. If it reads 00:00:109, your recorded beep was recorded 109 milliseconds before playback. Cool huh? Well, just kidding, the recording started later than playback, which is what causes this. The next image shows that the recorded beep is BEFORE the original one:
If the recorded beep is AFTER the original beep: Slide your finger on the recorded track and align the vertical dotted line to 00:01:000. Then slide your finger again, but now release at the start of the recording. The latency in seconds can be seen in the time display area at the bottom behind 'L'. If it reads 00:00:109, your recorded beep was recorded 109 milliseconds after playback.
You should try this out several times after each other to figure out if the latency on your device is stable. Simply press Undo twice to remove the recorded beep and the newly created track and record again. Make sure to always record from 00:00:000!
If you found your latency to be stable, you can correct for it by zooming in so that the range is large and clearly visible. Then tap in the middle of the range: a pop-up menu will open. You can either select 'Range info' to look at how large the range is in seconds and frames or you can just go ahead and tap on 'Use as latency correction'. This will determine the latency correction based on your selected range and save it into the preferences.
You can also do it manually by entering the latency in sample frames in the menu Preferences → Latency Correction. You need to enter latency correction in frames, not milliseconds, since frames are more accurate. Simply do the following calculation:
(latency in milliseconds / 1000) * 44100.
(109 / 1000) * 44100 = 4806 frames
Important! If your recorded beep was BEFORE (to the left of) the original beep, you need to enter the latency correction as a negative value! So, 4806 will become -4806.
We urge you to find any means possible to let Google (the authors of Android) know that we need low latency, jitter-free audio for Audio Evolution Mobile. One bug report that has been there for years, which also shows it's not our fault and we are not alone in this can be found here: http://code.google.com/p/android/issues/detail?id=3434
Android Jelly Bean (4.1) brings down the latency just a little bit, but the jitter remains.