I’m not entirely sure what you mean by “track” and “layer” in this question, so please forgive me if I’ve misunderstood something, but it sounds like you’ve put sound modules on multiple different audio tracks of an FMOD Studio event, and they’re do not always starting in sync.
If that is the case, the issue most likely results from the way our scheduling system interacts with multiple simultaneous streams. By nature, streams buffer continuously, which allows them to play without waiting for their assets to completely load, but also means that the time between their being triggered and their actually starting to play can vary. Under normal circumstances, this slight variability is too small to detect, but when you have multiple streams starting at the same time while resources are constrained, it can become noticeable.
There are a number of possible workaround for this. The simplest to implement, but most expensive in terms of memory, is to not use streams for your music. Simply go into the Assets Browser, select the offending sound files, and click on the “STREAM” toggle button. This will set those files to load completely before any event that uses them begins to play, but will increase the memory requirements of that event.
As an alternative, you could bake the individual sound files as separate channels of a multi-channel sound file, and then use the FMOD Channel Mix effect module to separate them out onto different tracks in Studio. This would allow you to use a single stream that always remains in sync with itself, but may be inappropriate or difficult to implement if you’re using timeline logic - and it sounds like you are.
A third option would be to use the FMOD Studio programmer’s API set the scheduling delay of this specific event to be higher than its default. This will create a slight latency when playing the event, but will give the streams in that event a little longer to buffer, increasing the chance of their both being ready when the event starts to play. This may be the best option, but may require you to tweak the code a few times to find the right balance of speed and reliability.