0
0

Do end callbacks fire when a channel loops, or just when it stops playing?

If they do, you should document this.

If they don’t, you should document this, and I hope I can use sync points to trigger a callback when a song loops, then. :)

(A loop callback would be great, I think, but maybe it’s not worth adding since sync points are available? Just a time saver.)

Also, if I pass a value into the [i:1kc8wh3i]command[/i:1kc8wh3i] parameter in Channel::setCallback, can I expect to get that value in the actual callback? It says the parameter is unused for end callbacks, so I’m not sure if that means it’s ignored or if it just means that FMod doesn’t care about it.

[b:1kc8wh3i]Edit:[/b:1kc8wh3i] Um, a bit of a problem here:
Sync points at the end of a track never fire.
I’ve tried placing one at LENGTH ms, and one at LENGTH-1 ms, and neither one ever fires. Where should I place a sync point if I want it to fire immediately when a track loops/ends?
Placing one at LENGTH-1000 works fine for the specific purpose I’m after right now, but that’s a bit less accuracy than I’d like in general.

  • You must to post comments
0
0

[quote="brett":3iaqomav]thats because the sound looped before you called System::update probably, but it might be something i can look at im not sure if it will cause other problems though.

The easiest solution is just put a syncpoint at 0 (or loopstart) and ignore the first one.[/quote:3iaqomav]Okay, that’s what I figured the problem was. It’s not really necessary to have a loop callback if you can use syncpoints to do it reliably, so either syncpoints at the end working or a seperate loop callback would work. Right now I just have the syncpoint set 1 second before the end of the track, and I start a fade-out when I hit it, so it works out alright.

  • You must to post comments
0
0

I’m having some really confusing problems with sync points firing at the wrong time. I’m not sure if somehow my tracks are ending up with sync points that I didn’t set, or if somehow my sync points are being placed in the wrong point, or what. But they’re definitely firing well before they’re supposed to and I’m having trouble figuring out what the cause is. Are there any circumstances that could cause this to happen?

What I’m doing is immediately after I load my sounds, I place a sync point named ‘start’ at 0ms and a sync point named ‘end-1’ at Length-1000ms. For the most part, this seems to work, but while I was just testing a particular track was reproducibly ending well before its Position had reached its Length. The tracks are all AoTuV Ogg Vorbis; do I need to enable ACCURATETIME or something for length to be correct?

  • You must to post comments
0
0

[quote="brett":t5dk6bky]hi,
That is a bit odd, ACCURATETIME wont help, that is only for mod/s3m/xm/it and mp3 right now. (because none of those formats store the length anywhere)

We get the pcm length from the vorbis file itself, so maybe the file has the wrong length stored within it?

what is ‘AoToV’?

I can maybe check it out if you like you can upload it to http://ftp.fmod.org l:upload p:upload[/quote:t5dk6bky]AoTuV is an improved vorbis encoder that generates higher quality files, they merged most of its changes into Vorbis around 1.1 iirc

I’ll see if I can find out anything more about the file – the length value might be wrong. If I can come up with a simple test case, I’ll send it your way.

  • You must to post comments
0
0

Okay, I can definitely reproduce this now. It’s kinda flaky, and I’m going to have to throw a bunch of asserts and sanity checks into my callbacks now, because there’s DEFINITELY something strange going on.

The audio files all seem to have proper headers and such, so I think we can rule that out. I did a little testing to see if there’s any consistent pattern in when the sync points (incorrectly) fire, and there seems to be one:

My game has a sort of a ‘playlist’ system, in which it queues up the next track about a second before the current track ends, and crossfades the two. They’re all streams. Once the current track has faded out, it stops.

So, at loadtime, I place a sync point at 0ms in the stream, and another sync point at LENGTH – 1000ms in the stream.

Now, here’s what I do to reproduce it:
I play through the entirety of my first playlist track, which is about 108 seconds long. The second sync point fires at ~107 seconds, as expected. Next track queues up. After a few seconds, I skip the next track. Track is faded out and stopped automatically and the new track is played.

This new track is the one that seems to misbehave (though I’ve been able to reproduce it with other tracks, so I’m thinking it has something to do with my seeking/skipping/premature stopping behavior): A syncpoint mysteriously fires at around the same general location as the sync point in the original track. Interestingly enough, if I use setPosition to skip through the current track, the phantom sync point will not fire at that location – but if I allow it to play through normally, it fires pretty reliably at around that spot. I was able to record it by attaching a simple script to the syncpoint event that prints the channel’s position and the sound’s length value:

Loading track 2: Brandon Abley – Johnny Depp
Skipping track
Loading track 3: Troupe Gammage – Crepuscular
Current BGM is ending… {84.9s / 1054.9s}

Loading track 1: Brandon Abley – Challenge an Ill Fate to Victory
Current BGM is ending… {107.8s / 108.8s}
Loading track 2: Brandon Abley – Johnny Depp
Skipping track
Loading track 3: Troupe Gammage – Crepuscular
Current BGM is ending… {103.1s / 1054.9s}

Obviously, something’s amiss there.

Anyway, I’m going to try and do some more debugging of this issue and see if I can get it to trigger with shorter streams so that it’s easier to reproduce and test. I just figured I’d post my current progress just in case it gives you any ideas for where to look in FMod for any possible bugs or quirks.

[b:15s74zhj]Edit:[/b:15s74zhj] Here’s some preliminary results from a little additional investigation:
Adding end-1 sync point to track /bgm/Brandon Abley – Johnny Depp.ogg @ 271326ms, sound ID 8686064
Adding end-1 sync point to track /bgm/Brandon Abley – Challenge an Ill Fate to Victory.ogg @ 107826ms, sound ID 8749488
Sync point “end-1” @ 107825ms in sound 8749488
Sync point “end” @ 108815ms in sound 8749488
Adding end-1 sync point to track /bgm/Troupe Gammage – Crepuscular.ogg @ 1053955ms, sound ID 8975840
Sync point “end-1” @ 107825ms in sound 8749488
Adding end-1 sync point to track /bgm/Troupe Gammage – Jade Pendant.ogg @ 219699ms, sound ID 9003792
Sync point “end” @ 108815ms in sound 8749488

It looks like somehow the sync point from the original track is still being fired. I’m not sure how that’s possible – I guess it could still be playing at a volume of 0 due to some sort of bug, but I’m pretty sure that the track is being stopped. I’m going to look into this on my end a bit more.

[b:15s74zhj]Edit #2:[/b:15s74zhj] Okay, you can rule this one out as an FMod bug. The routine responsible for stopping the channel was misbehaving, so once the tracks faded out they kept playing, and the sync points kept triggering. My bad! :)

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.