FMOD::Channel getPosition accuracy question/issue

Unreal Engine
,
1

Hello there,

We have encountered an issue with the following function:
FMOD::Channel::getPosition(unsigned int *position, FMOD_TIMEUNIT postype)

Context:
We are currently developing a rhythm game that is already in production. We utilize FMOD for reading WAV files and synchronizing gameplay to the music. In our game, the movement of actors is relative to the music’s timing.

Symptoms:
Every 4-6 frames, the getPosition function returns the same value as the previous one. As a result, we observe a noticeable “lag” in the movement of all actors every 4-6 frames.

Here’s the code snippet used to obtain the timing:

	unsigned int pos = 0;
	m_fmodSongChannel->getPosition(&pos, FMOD_TIMEUNIT_MS);
	float fmodTime = (pos) / 1000.0f;
	UE_LOG(LogFmodSubsystem, Warning, TEXT("FMOD TIME %f %f"), fmodTime , currentDeltaTime);

Result of this test:

Capture
Capture1035×568 93.5 KB

Is there a way to potentially smooth out the getPosition function?

Note: We are aware that we “could” use UE4 deltaTime. However, for some reason, on certain hardware, towards the end of the song, we noticed that getPosition can be up to 2 seconds behind UE4 time (which is not feasible for a rhythm game).

2 Likes
2

Hi, apologies for the delayed response,

I’ve been able to reproduce the exact behavior you’re describing, but unfortunately cannot offer a workaround currently. Channel::getPosition technically grabs a shadow position, which is updated asynchronously by the system, which would explain the behaviour you’re seeing. However, the typical recommendation of using Channel::getDSPClock to access the channels’ underlying DSP clock in memory, which would normally provide sample accurate timing, also doesn’t resolve the issue.

I’ll consult with the development team on this, and should get back to you on it soon.

3

The development team has confirmed that this isn’t expected behaviour, and they’ll be looking into it. Unfortunately, I don’t have a workaround for you besides calculating the average position of the channel in your own code.

4

Thanks for the answer,

I hope you will find a solution and a workaround :slight_smile:

good luck on this !

2 Likes
5

Hi,

Just to follow up on this and clarify - the large interval between FMOD’s channel position updating compared to UE’s delta time is to be expected, as the channel position updating is not explicitly based on elapsed time, but on the latest update to the DSP buffer. Typically this is both slower than and not evenly divisible by UE’s delta time, leading to the “lag” you’re experiencing. Lowering the value of your “DSPBuffer Length” in Project Settings → Plugins → FMOD Studio → Init Settings may help, but there will likely be some mismatch regardless.

As mentioned previously, averaging FMOD’s channel position delta yourself would be a workaround, but this mismatch is expected behavior, the more pressing concern is the drift in timing between UE4 and FMOD. If this is still an issue, would you mind elaborating on the gap of two seconds that you’ve observed, the structure of the audio/event in question, as well as what hardware it occurs on?