stuttering music in demos
category: general [glöplog]
firelight: is this really the whole code for the GetTime() function?
My own code also uses this as a foundation, but adds the difference between the last buffer write position and the current one (GetPlayPosition() of the DS buffe). It's THIS bit that goes wrong here, some times the play pos is a bit lower than it has been before.
As with sir r. kbab, the only solution was ignoring all backward play position changes that didn't indicate that the buffer was looping (that is: all changes smaller than half the buffer size, in all other cases you're screwed anyway ;)
My own code also uses this as a foundation, but adds the difference between the last buffer write position and the current one (GetPlayPosition() of the DS buffe). It's THIS bit that goes wrong here, some times the play pos is a bit lower than it has been before.
As with sir r. kbab, the only solution was ignoring all backward play position changes that didn't indicate that the buffer was looping (that is: all changes smaller than half the buffer size, in all other cases you're screwed anyway ;)
hm, terrible. thinking about how my adpcm_on_dvd streaming code would possibly fcuk up if that would happen :)
i also ran thru this "bug"-thingy, especially what I noticed that it was mostly appearing on SoundBlaster cards... (or well i at least hope that this was the reason the sound fucked up :)
the only really reliable timer under windows for music-sync, is really the position in the sound-buffer. it's no doubt about it, some soundcards tend to play stuff at a slightly wrong frequency (ie not 44100), leading to audio and visuals getting out of sync. resyncing another timer will lead to demo-skips, and is not a solid solution.
kb: yes, the value is lower when the buffer wraps ;)
...but i assume that wasn't what you meant. I have never had any troubles like that myself.
...but i assume that wasn't what you meant. I have never had any troubles like that myself.
kb: yeah, thats basically it, but i subtract the buffersize to 'latency adjust', (ie a 1000ms buffer is filled before you call play, but you dont want to display 1000 as the gettime value, it should say 0), but you know the deal with that :).
I know what you are doing there, you are getting an 'interpolated time', but fmod doesnt do that, it increments in steps of the mixbuffer chunk, so its not perfectly fine granularity.
sir richard kebab:
only thing i can see is the float/int conversion/truncation might be to blame, i just suggest you log the int values that come from fsound_stream_gettime and report if they ever go backwards, i am fairly confident they wont.
I know what you are doing there, you are getting an 'interpolated time', but fmod doesnt do that, it increments in steps of the mixbuffer chunk, so its not perfectly fine granularity.
sir richard kebab:
only thing i can see is the float/int conversion/truncation might be to blame, i just suggest you log the int values that come from fsound_stream_gettime and report if they ever go backwards, i am fairly confident they wont.
i'll try that when i have time, today or tomorrow.
(never used fmod in a demo) - i suspect bass does something different with those std. "timing" funcs - i'll test just accum'ing the buffer pos some day.
well, that might explain why fmod-based demos always stutter then. :)
IGraphBuilder::RenderFile()
