Click when looping

Sometimes, when I try to setup a loop by overlapping the same audio file and setting the loop point to be the exact same position on both files, I get a click every time the loop wraps around. However, the expected behavior is that it would be seamless (regardless of the crossfade) because it should be looping at the exact same sample. Not sure I’ve described this very well, but the attached screenshot should explain it. Snapping is turned on, so I’m pretty sure this loop should be seamless. I’ve had some loops that do work well this way, and others do not. In case it helps understand the screenshot, the loop region is snapped to 24 bars length.

Could you double check to see if your asset (“synth”) is set to “Streaming”? If it is, try again with it set to not streaming.

A streaming asset requires a little time to load in a buffer of the audio and if you require sample-accurate positioning then it might be causing some popping.

You could also try splitting the audio file into two files - an intro and a loop - if this is still causing popping.

I tried disabling the stream setting, but that didn’t seem to fix it. I also tried the exact same setup as in the screenshot, but using a duplicate file for the second event (duplicated via osx finder, ie synth.wav and synthCopy.wav) instead of the exact same file. Same gap in playback though. In theory, this should work, because it is still essentially an intro and loop, and it’s looping at the exact same point in the file. I know that I’ve gotten the technique to work on a previous project a couple years ago, but don’t remember how, or if it was just luck.

Would you be able to share the “Synth” audio file you have? I’d like to try and reproduce it on my machine.

I guess you can actually reproduce this with any ambient audio file. I checked a game that I worked on a couple years ago (older version of fmod), and this actually happens with a few of the tracks. If you take any ambient track and loop it as I did, it will get the click. But, to me, this seems like the most logical way to loop a track (and easiest, if it’s not going to need any transitions, etc).

I see. The issue is that the looping points aren’t zero crossing perfectly (if I’m using that term correctly). Simply put the volume at the end of your loop isn’t perfectly matching the beginning of the loop.

It’s a bit of a complicated task to loop assets seamlessly so it’s best practise to look at a few videos on how to make zero crossing loops.

That shouldn’t be the case though…because it should actually be looping back to exactly the same point in the file. It seems that it shouldn’t matter how you prepare the wav file, as long as you are looping back to the same point in the file. Maybe the glitch is happening in the “handoff” between the two instances of the file (or between 2 files, when I used a second file).

Wouldn’t zero crossing only matter if you’re trying to line up items which are different? But in this case, what should be happening is, let’s say the end point of the loop is set at a point in the second wav file where you aren’t at a zero crossing, let’s call it +3 above zero and headed towards +2…when it loops back to the identical first wav file, it should just be continuing where it left off, no? So the next bit that plays should be +2 and so on…

That’s probably not the most eloquent way of putting it, but long story short, I would think that whether or not you’re at a zero crossing, when the locators are set as in this example with two identical files, the next thing that plays when the loop wraps around, should be exactly where the last thing left off, right?

I know the issue, too.
I think the problem is, that there is a minimum of processing time. (probably has something to do with how FMOD handles output voices)

If the event is in play mode you see the activation by the highlight of the sample. The thing is, if the next sample isn’t in the timeline ahead (which is here the case because of the loop) the first sample gets activated when the playhead is already there. That’s what I observed.

If I want to make this “copy end of loop to beginning and crossfade” thing, I allway make a hard render in my DAW and import the edited file to FMOD… That works fine, because the sample stays in the active state.

Yeah, I think that’s what is happening. It’s too bad, because this method of looping in the photo above would save tons of time in rendering/splitting files. It may not seem like much, but when you’ve got many files to deal with, not to mention many revisions, this could save so much time. It also would open some doors for procedurally generated music in Fmod, which is what I was working on when I encountered this. It would be nice if there were a way to force the two events to be active constantly so you can loop smoothly like this within fmod. I’m sure there’s a technical reason it’s not like that, but nothing wrong with putting it on the wish list!

“It would be nice if there were a way to force the two events to be active constantly so you can loop smoothly like this within fmod.”
I am not sure, but there must be a possibility to do that with the FMOD API! That would be a programming thing (and yes: additional effort), but maybe, if it is done once, you might copy&past the code.

I’ve forwarded this onto our API team to take a closer look into. Like you said, it should work but we need to see exactly what’s happening under the hood. We’ll get back to you once we’ve found out more.

Thanks, Richard! My guess is there’s probably a technical reason it’s like this, but that doesn’t mean it necessarily has to be that way.

For example, maybe it can be optional whether to have an event always active. Or maybe in the case of a duplicate event on one track, they can all be active.

If this type of looping could be enabled in Fmod somehow, it would be super easy to have Fmod automatically loop sections by finding the same loop point in each event (or by snapping to the same point in two events when dragging the loop region).