Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

unknown delay with music.currentTime

in Questions Posts: 500

I'm working on a project where I need my audio to play one after another. So when I call for a new audio snippet, it should interrupt the current one and play this next.

To make things easier to manage I created something like a two-track audio player. master is the first track, where the music api is used. And track is used with sound api to overdub the current audio while fading-in the next audio snippet. When fading is done, the overdub track becomes the master track.

The issue here however is, that when I swap track for master I get a awkward delay of roughly 5 frames. And I can't tell where it comes from?! I would normally set music.currentTime = track.time, where track.time is the time of the tween, which again is the same time as the fade-in lasted, but then the two tracks aren't in sync anymore.

Does anyone have a solution for this? (Or, alternatively, a suggestion on how to make this better?)

local master, track

local function remaster()
    if track then
        tween.stop(master)
        tween.stop(track)
        music(track._name, track._loop, track.subject.volume)
        music.currentTime = track.time + 5*DeltaTime -- unknown delay, maybe due to pre-loading?
        track.subject:stop()
        master, track = track, nil
    end
end

function sfx(conf)
    assert(type(conf.name) == "string", "sound missing")
    conf.blend = conf.blend or .01
    conf.effect = conf.effect or tween.easing.linear
    remaster()
    master = tween(conf.blend, music, {volume = 0}, conf.effect, remaster)
    track = tween(conf.blend, sound(conf.name, 0), {volume = conf.volume or 1}, conf.effect)
    track._name = conf.name
    track._loop = not not conf.loop
end

Comments

  • Posts: 500

    PS: I tried to capture the track._timestamp = CurrentTime before swapping the tracks and using that to calculate the delay. music.currentTime = track.time + CurrentTime - track._timestamp didn't work either...
    This calculated delay seemed even to be smaller than 5 * DeltaTime, which is wrong.

  • SimeonSimeon Admin Mod
    Posts: 4,995

    Has this delay always existed or is it something we recently introduced? (Might help me know where to look)

  • dave1707dave1707 Mod
    Posts: 7,657

    @Simeon I mentioned a delay when using sound awhile ago that I had in one of my programs. It seemed that the first time the sound was played there was a delay while the sound was loaded ??? . After the first time, there wasn't a delay anymore when the sound was played.

  • edited June 10 Posts: 500

    @Simeon Sorry, never noticed it before. I don't think it was introduced recently.

    The strange thing, is that there is almost no delay or none at all when I measured it with CurrentTime diffs. But if you start the same audio file from music() and sound() at the same time you should notice the offset. Also tried to reload the project but that didn't fix it for me..

    It almost feels like the playhead has not enough float precision or something.

    @dave1707 I know what you mean. But that is the delay just before the sound plays. After reloading the project the audio plays without any delay. But what I have here is this - PLUS another slight delay when moving the playhead with music.currentTime... I think this is another issue, but might be related...

Sign In or Register to comment.