0
0

<known factors>
Cannot be replicated outside the game engine.
Troublesome code moved in a separate test harness and it works flawlessly.
<known factors>

<hack/fix> (no longer works in 4.14.00)
remember position GetPosition
Stop Channel
Update
Create another Channel, start paused
Update
SetPosition of new channel to position got
Update
Unpause
Update
<hack/fix>
I hit a snag fast forwarding through a MIDI file (well a few MIDIs)
SetPosition hangs my program when I fast forward too much in a ( >2 minutes or so ) midi

An example toublesome midi
[url=http://host-a.net/icuurd12b42/FugueGM2.Mid:36l4lvy7]Download FugueGM2.Mid[/url:36l4lvy7]

The parts involved in my DLL

[code:36l4lvy7]
export double FMODInstanceSetPosition(double instance, double p)
{
if(!inited) {{FMODASSERT(FMOD_ERR_INITIALIZATION);}}
if(!(instance>0)){{FMODASSERT(FMOD_ERR_INVALID_HANDLE);}}
if(p<0) {{FMODASSERT(FMOD_ERR_INVALID_PARAM);}}
if(p>1) {{FMODASSERT(FMOD_ERR_INVALID_PARAM);}}
UINT l = 0;
FMOD_SOUND * sound = NULL;

FMODASSERT(FMOD_Channel_GetCurrentSound((FMOD_CHANNEL *) (DWORD) instance, &amp;sound));
if(sound==NULL) {{FMODASSERT(FMOD_ERR_INVALID_HANDLE);}}

FMODASSERT(FMOD_Sound_GetLength(sound, &amp;l, FMOD_TIMEUNIT_MS));
FMODASSERT(FMOD_Channel_SetPosition((FMOD_CHANNEL *) (DWORD) instance, (UINT)(p*l), FMOD_TIMEUNIT_MS));
return (double) 1;

}

export double FMODInstanceGetPosition(double instance)
{
if(!inited) {{FMODASSERT(FMOD_ERR_INITIALIZATION);}}
if(!(instance>0)){{FMODASSERT(FMOD_ERR_INVALID_HANDLE);}}

UINT p,l;
p = 0;
l = 0;
FMOD_SOUND * sound = NULL;

FMODASSERT(FMOD_Channel_GetCurrentSound((FMOD_CHANNEL *) (DWORD) instance, &amp;sound));
if(sound==NULL) {{FMODASSERT(FMOD_ERR_INVALID_HANDLE);}}

FMODASSERT(FMOD_Sound_GetLength(sound, &amp;l, FMOD_TIMEUNIT_MS));
FMODASSERT(FMOD_Channel_GetPosition((FMOD_CHANNEL *) (DWORD) instance, &amp;p, FMOD_TIMEUNIT_MS));
return (double) p/l;

}

export double FMODInstanceIsPlaying(double instance)
{
if(!inited) {{FMODASSERT(FMOD_ERR_INITIALIZATION);}}
if(!(instance>0)){{FMODASSERT(FMOD_ERR_INVALID_HANDLE);}}
FMOD_BOOL p = 0;
FMODASSERT(FMOD_Channel_IsPlaying((FMOD_CHANNEL *) (DWORD) instance,&p))
return (double) p;
}

export double FMODUpdate(void)
{
if(!inited) {{FMODASSERT(FMOD_ERR_INITIALIZATION);}}
FMODASSERT(FMOD_System_Update(mainsystem));
return (double) 1;
}
[/code:36l4lvy7]

The code in my program
At the end of the game loop
When up arrow is pressed

I use a value betwee 0 and 1 to set the position, where 0 is the start and 1 is the end of the sound…

I tried a few wma file (Thick As As brick for one)… Works great.
[code:36l4lvy7]
if(uparrow)
{
if(FMODInstanceIsPlaying(m_instance))
{
double p;
p = min(FMODInstanceGetPosition(m_instance)+.01,1);
FMODInstanceSetPosition(m_instance,p)
}
}
if(downarrow)
{
if(FMODInstanceIsPlaying(m_instance))
{
double p;
p = max(FMODInstanceGetPosition(m_instance)-.01,0);
FMODInstanceSetPosition(m_instance,p)
}
}
FMODUpdate();

[/code:36l4lvy7]

4.12.07

had same problem in 4.08

  • You must to post comments
0
0

Bump

OK, my hack stopped working in 4.14.00 so I am re-opening this issue with the following…

Can anyone explain the inner workings of SetPosition so I can figure a proper work around in my wrapper DLL?

Shot in the dark questions:
Does Setposition use windows message queue?
Does set position use (a) thread(s)?

Description of the problem
I have linked FMOD with my MIDI displayer and I can now more properly describe the problem as I see it on the screen.

While I fast forward through the MIDI using a small amount over a long period of time (from 0 to .25 on fugue) Getposition returns the proper position but when I stop, GetPosition returns the position I stop fast forwarding at. It stays at that final position. And the sound plays the same few notes at that position like a skipping record or simply stops if I forward to .5.
If I forward once by a large amount, GetPosition returns the last position then the new position alternatively. So if I jump from position .25 to .95, the MIDI skips back and forth from .25 to .95, playing a few notes at each position. (That was in the last version of FMOD, This version seems to allow large jumps but not if I start a new channel like my hack does. Very confusing)

After the system has gone berserk, I can stop the channel but cannot create a new channel using another sound (not sure if the new sound is added either).

I’ll see if I can play with it some more and try to extract as much beneficial information out of FMOD as I can over the next few days, but meanwhile, If any one has a clue or any idea no matter how impossible/improbable, it would help me a lot.

Side note
4.08 synched up very badly with my MIDI displayer, Gradually, the closer to the end, I got further and further behind FMOD. The music would end a half second to a second before getposition reported 1

I would get the length in millisecs and calculate from my GetPosition (returning 0 to 1) where to display the MIDI

Then, when I upgraded to 4.12, the display would synch up perfectly all the way through except for 2 MIDI files.

Now, using 4.14 I start up synched then I either get behind or ahead of FMOD while playing the same file… That is, I am synched up but not for long then I get behind very fast, then catch up then I get ahead then loose ground near the end…

Could the problem be remotely related?

  • You must to post comments
0
0

Okay I have had a play with seeking of MIDI files (including the file you have specified) and I haven’t run into any problems so far. I set up my test the same as yours and tried jumping in small increments of 1% or large of 50% or 90% and all the jumps worked. You will get a short stall when seeking forward over very large distances and also from seeking backwards small amounts when near the end of the file due to the way our MIDI system works.

As for your questions about SetPosition using separate threads or a message queue it uses neither.

Yes old versions of FMOD suffered from some inaccuracy or drift between how long the file should be and how long FMOD played it for. This was due to tempo changes not being considered when calculating the length of the sound. MIDI playback will not be sample accurate with your reading of the MIDI file anyway because our calculations of the length of the MIDI file probably differ.

We calculate the length of the MIDI file by running through the file (non-realtime) processing all the messages and adding up the play time. We do this in chunks of 10 ticks so we can account for any tempo changes that may occur through out the file. Maybe your viewer calculates length differently which would account for the drift.

As for the core issue with seeking, I am going to need a way to reproduce your seeking error before I can start working on a fix.

  • You must to post comments
0
0

[quote="mathew":2m0u78w0]Okay I have had a play with seeking of MIDI files (including the file you have specified) and I haven’t run into any problems so far. I set up my test the same as yours and tried jumping in small increments of 1% or large of 50% or 90% and all the jumps worked. You will get a short stall when seeking forward over very large distances and also from seeking backwards small amounts when near the end of the file due to the way our MIDI system works.

As for your questions about SetPosition using separate threads or a message queue it uses neither.

Yes old versions of FMOD suffered from some inaccuracy or drift between how long the file should be and how long FMOD played it for. This was due to tempo changes not being considered when calculating the length of the sound. MIDI playback will not be sample accurate with your reading of the MIDI file anyway because our calculations of the length of the MIDI file probably differ.

We calculate the length of the MIDI file by running through the file (non-realtime) processing all the messages and adding up the play time. We do this in chunks of 10 ticks so we can account for any tempo changes that may occur through out the file. Maybe your viewer calculates length differently which would account for the drift.

As for the core issue with seeking, I am going to need a way to reproduce your seeking error before I can start working on a fix.[/quote:2m0u78w0]

Ah, tempo change… That is likelly the reason for the discrepancy with the displayer… Makes sense. Though it is odd that with 4.10 they synched of perfectly… Not in 4.08 and no longer in 4.14. A lot more work needeed in my MIDI display.

Well, for debugging this, I made a C program that DOES NOT replicate the problem, so I know it’s not FMOD directly but some sort of interaction with the game engine that uses FMOD through my DLL. It really agravates me because that sort of bug is soo hard to catch (stack problem maybe) and I have no control over the engine.

But the game engine does it all the time. If you are interested in taking a peek, I can give you the exe to use as a test harness and the DLL source. You could run the entire setup with your debug version of FMOD and a debug version of my wrapper.

If you have the time, tell me and I’ll package everything up for you.

  • You must to post comments
0
0

Sounds like that is a good way forward, if you can package everything up and send it to support@fmod.org, I will take a look.

  • You must to post comments
0
0

Just to finish this topic off, this issue has now been resolved and a fix will be available in the next release.

  • You must to post comments
0
0

[quote="mathew":1ojjukej]Just to finish this topic off, this issue has now been resolved and a fix will be available in the next release.[/quote:1ojjukej]

New build 4.14.03 works!

Tank you so much!

  • You must to post comments
Showing 6 results
Your Answer

Please first to submit.