stuttering music in demos
category: general [glöplog]
I just read in the comments about R.E.D./rgba that some people have problems with music playback in demos (stuttering and sync). And I must say that I also have problems since I switched to XP.
I have a Soundblaster Audigy card, so I doubt that it´s a problem of the soundcard (and I had no problems with it under 98). But I already noticed stuttering in some demos (though rarely), I can remember ASD/Dreamchild. And sometimes my own things stutter or get out of sync, but I cannot reproduce this in a second run. Also if I don´t use FMOD, it seems as if thread notifications tend to be delayed a lot sometimes under XP.
Is it a driver problem? Do we have to change some parameters in FMOD? Is it a problem of XP?
I have a Soundblaster Audigy card, so I doubt that it´s a problem of the soundcard (and I had no problems with it under 98). But I already noticed stuttering in some demos (though rarely), I can remember ASD/Dreamchild. And sometimes my own things stutter or get out of sync, but I cannot reproduce this in a second run. Also if I don´t use FMOD, it seems as if thread notifications tend to be delayed a lot sometimes under XP.
Is it a driver problem? Do we have to change some parameters in FMOD? Is it a problem of XP?
the problem is the pc
The driver can be responsible, what I've heard creative's soundcard drivers isn't what one can hope they would be.
I've had the same problem (with fmod) on some machines, and I don't know why either. Larger buffers might help you.
Since I don't want my productions to run out of sync I made a resync-routine, if the sound system is too far out of sync then my timer (which uses high-resolution timers in win32) will adjust itself to the sound playback. seems to work fine so far, I've tried to mess up the sync and it always manages to resync correctly =)
Since I don't want my productions to run out of sync I made a resync-routine, if the sound system is too far out of sync then my timer (which uses high-resolution timers in win32) will adjust itself to the sound playback. seems to work fine so far, I've tried to mess up the sync and it always manages to resync correctly =)
Fox: Why use a separate timer requiring resync instead of using the
sample accurate timer from the audio hardware? (Do you need better
precision than 1/44100s) ?
sample accurate timer from the audio hardware? (Do you need better
precision than 1/44100s) ?
Knos: Because the sound card timer isn't really "accurate" under Windows... there are enough drivers that love totally screwing up in that department, and Creative is definitely among them (I needed a few ugly hacks for fr08 to run smoothly on SBLive cards).
Argh :]
i noticed since i put a sblive card in, a lot of stuff crashes. Anyone recommend some half-working drivers for it? I'm not bothered about all the fancy features, i just want decent stereo :)
the kx project drivers work quite well. They're hard to handle if you're not a geek, but I never had problems with them.
http://kxproject.lugosoft.com/index.php?skip=1
http://kxproject.lugosoft.com/index.php?skip=1
i use the kx project drivers for my emu a.p.s-card (yep, same chip as the live!, but with waaay better D/A-converters, amongst other things :), and demos using fmod always sound like stuttering crap, which is really annoying. people should use softsynths for intros and ogg vorbis (read: libvorbis) for demos anways, so stop using fmod please..
(ps! i tried to switch to my onboard c-media "soundcard" (yuck!) and fmod-demos plays the same way there as under my emu a.p.s-card).
(ps! i tried to switch to my onboard c-media "soundcard" (yuck!) and fmod-demos plays the same way there as under my emu a.p.s-card).
They're hard to handle if you're not a geek, but I never had problems with them.
well gee, figures :)
well gee, figures :)
kb: cheers, i'll give those a try. Shouldn't have too many problems with them i think as part of my job is sorting out driver issues :)
knos: kb said one reason, I also tried syncing to the sound system's timer and the result was that the demo didn't run as smooth as with the high resolution timers. pehaps it's the accuracy or whatever. I just know that it doesn't work.
and even though I could install the kxproject-drivers I still need to make an engine that will work on all pc's, not just mine.
gloom: I agree. but what's the problem with fmod? I mean, it's a commercial sound library and I guess firelight is working a lot on it but still it doesn't work. I just wonder why..
ogg vorbis rocks =)
and even though I could install the kxproject-drivers I still need to make an engine that will work on all pc's, not just mine.
gloom: I agree. but what's the problem with fmod? I mean, it's a commercial sound library and I guess firelight is working a lot on it but still it doesn't work. I just wonder why..
ogg vorbis rocks =)
/me prefers bass.dll
i got stutter problems on some demos but it was nothing that changing desktop refresh rate to 60 or 70 hz didnt fix.. just thinking some ppl might be suffering from the same *ahm* features.
Fox, kb's explanation would explain the lack of smoothness. I never realized crappy drivers like that were out there, none of my soundcards exhibit the problem .. (gus pnp and rme digi96)
I know this thread has been long forgotten but what the heck..
This comes from the fmod api help file, section troubleshooting about stuttering sound.
---
More commonly known as buffer underrun/overrun, this can be 1 or a combination of factors
Bad soundcard drivers
This may be solved by upgrading your soundcard drivers. (Note it is recommended you get the latest drivers anyway)
CPU issues
Machine to slow, or whatever your are trying to do with FMOD is too cpu intensive! (ie playing 100 mp3's at once will most likely bring FMOD to its knees, or maybe a user stream callback or DSP callback is spending too much time executing).
Mixer buffersize is set too small
You can increase stability to combat these issues, by increasing FMOD's internal mixing buffer size. This will lead to greater stability but also larger latency on issuing commands to hearing the result.
Call FSOUND_SetBufferSize to alter this value (in milliseconds). It must only be called before calling FSOUND_Init, it will fail otherwise.
Please don't set this value to huge numbers like 2000 or 10000. It won't help increase stability and will consume larger amounts of CPU time and RAM.
First try a value of 100, then 150, then 200, and no more.
Stream buffersize is set too small
If you are using the stream API, you might be streaming off a slow media, such as CDROM or over network, or even a fragmented harddisk, and fmod needs more time to fill its streaming backbuffer.
For streaming buffers, fmod defaults to a 400ms stream buffersize. This is seperate to the mixer buffersize described above and not related.
Changing this value does not alter latency. Streams are pre-buffered and always start instantly no matter what the buffersize.
Call FSOUND_Stream_SetBufferSize to alter this value (in milliseconds). It must only be before opening a stream to take effect.
Setting this value to large values will cause larger cpu spikes (if a compressed format) and more memory usage.
Values around 1000 to 2000 max are recommended. Larger values are not.
Video Card Drivers
Yes video card drivers can affect sound output.
Always make sure you have the latest 3d/videocard drivers, and that your users are aware of this as well.
It has been noted that a bad VIDEO card driver can cause break ups and instability in sound output, as they are badly written and cause the bus to be taken over by the video card, not letting any sound data to be transferred to the soundcard.
This has been noted on S3 Virge and Voodoo 1 drivers so far, so always remember first to have the LATEST video driver, and make sure you note this in your documentation as well upon distribution.
Frame-rate is too high!
Yes this can also affect the sound output, for the same reasons as described above. Excessive calls of the video driver can force the sound driver to not be serviced. It has been found that introducing a frame-rate limiter will solve this problem.
Output type
FSOUND_OUTPUT_DSOUND will provide more solid output than FSOUND_OUTPUT_WINMM in anything except NT.
This is a problem with Windows Multimedia Services not being as realtime as it should be.
Under NT FSOUND_OUTPUT_WINMM is more stable, as DirectSound in NT is just emulated by using WINMM itself and is actually slower and has longer latency!.
NOTE: Please don't feel the need to use FSOUND_SetOutput if you don't need to. FMOD autodetects the best output mode based on the operating system.
I hope this provides some help..
This comes from the fmod api help file, section troubleshooting about stuttering sound.
---
More commonly known as buffer underrun/overrun, this can be 1 or a combination of factors
Bad soundcard drivers
This may be solved by upgrading your soundcard drivers. (Note it is recommended you get the latest drivers anyway)
CPU issues
Machine to slow, or whatever your are trying to do with FMOD is too cpu intensive! (ie playing 100 mp3's at once will most likely bring FMOD to its knees, or maybe a user stream callback or DSP callback is spending too much time executing).
Mixer buffersize is set too small
You can increase stability to combat these issues, by increasing FMOD's internal mixing buffer size. This will lead to greater stability but also larger latency on issuing commands to hearing the result.
Call FSOUND_SetBufferSize to alter this value (in milliseconds). It must only be called before calling FSOUND_Init, it will fail otherwise.
Please don't set this value to huge numbers like 2000 or 10000. It won't help increase stability and will consume larger amounts of CPU time and RAM.
First try a value of 100, then 150, then 200, and no more.
Stream buffersize is set too small
If you are using the stream API, you might be streaming off a slow media, such as CDROM or over network, or even a fragmented harddisk, and fmod needs more time to fill its streaming backbuffer.
For streaming buffers, fmod defaults to a 400ms stream buffersize. This is seperate to the mixer buffersize described above and not related.
Changing this value does not alter latency. Streams are pre-buffered and always start instantly no matter what the buffersize.
Call FSOUND_Stream_SetBufferSize to alter this value (in milliseconds). It must only be before opening a stream to take effect.
Setting this value to large values will cause larger cpu spikes (if a compressed format) and more memory usage.
Values around 1000 to 2000 max are recommended. Larger values are not.
Video Card Drivers
Yes video card drivers can affect sound output.
Always make sure you have the latest 3d/videocard drivers, and that your users are aware of this as well.
It has been noted that a bad VIDEO card driver can cause break ups and instability in sound output, as they are badly written and cause the bus to be taken over by the video card, not letting any sound data to be transferred to the soundcard.
This has been noted on S3 Virge and Voodoo 1 drivers so far, so always remember first to have the LATEST video driver, and make sure you note this in your documentation as well upon distribution.
Frame-rate is too high!
Yes this can also affect the sound output, for the same reasons as described above. Excessive calls of the video driver can force the sound driver to not be serviced. It has been found that introducing a frame-rate limiter will solve this problem.
Output type
FSOUND_OUTPUT_DSOUND will provide more solid output than FSOUND_OUTPUT_WINMM in anything except NT.
This is a problem with Windows Multimedia Services not being as realtime as it should be.
Under NT FSOUND_OUTPUT_WINMM is more stable, as DirectSound in NT is just emulated by using WINMM itself and is actually slower and has longer latency!.
NOTE: Please don't feel the need to use FSOUND_SetOutput if you don't need to. FMOD autodetects the best output mode based on the operating system.
I hope this provides some help..
You can make it behave just like winamp or a softsynth or whatever you want in regards to buffering, just use FSOUND_HW2D and FSOUND_Stream_SetBufferSize(1000) or something. Then it will buffer as far ahead as you want.
The faq above says it all, but it is usually the drivers fault, or the app's fault for hogging the cpu too much and starving the mixer thread.
Trying to provide <50ms realtime audio is a real problem on windows, you can see any audio program has 'buffersize' settings, where the tradeoff is stability vs latency.
The problem is people don't play with the buffersize depending on the situation (is it a game that needs low latency response? or a demo where you can prebuffer seconds of data and use huge buffers?)
You can do both, but people dont bother to play with that stuff, they usually leave it at the default settings, which is trying to get somewhere between latency and stability.
On 99% of machines with a well coded mainloop and good drivers / OS, it will NOT skip/stutter.
The faq above says it all, but it is usually the drivers fault, or the app's fault for hogging the cpu too much and starving the mixer thread.
Trying to provide <50ms realtime audio is a real problem on windows, you can see any audio program has 'buffersize' settings, where the tradeoff is stability vs latency.
The problem is people don't play with the buffersize depending on the situation (is it a game that needs low latency response? or a demo where you can prebuffer seconds of data and use huge buffers?)
You can do both, but people dont bother to play with that stuff, they usually leave it at the default settings, which is trying to get somewhere between latency and stability.
On 99% of machines with a well coded mainloop and good drivers / OS, it will NOT skip/stutter.
i've noticed that both bass and fmod give me the following problem; sometimes, when using some GetPosition or GetTime call, sometimes the returned value in a later frame is lower than one in the previous frame, seriously screwing up timing for some methods. bass does it much worse than fmod, though, so i doubt it's "only" a driver issue. any more experienced coders having any fill on this? my 'solution' was simply only updating the 'curtime' variable when the returned time was at least the previously returned one. ugly, but worked. kind of.
One should add for clarification that with "NT", aMUSIC means Windows NT 3.5 and 4.0 . All newer Windows versions (Me, 2000, XP, Srv2003) are utilizing the WDM driver model where WinMM as well as DirectSound are only two different APIs accessing the built-in Kernel Mixer.
The irony here is that most WDM sound card drivers themselves can support latencies down to 1.5ms (and perhaps even lower, only Windows' scheduler won't sleep with you then), but the kmixer/sysaudio services prevent that as they have that, uh, "laid back" attitude towards working.
The irony here is that most WDM sound card drivers themselves can support latencies down to 1.5ms (and perhaps even lower, only Windows' scheduler won't sleep with you then), but the kmixer/sysaudio services prevent that as they have that, uh, "laid back" attitude towards working.
sir RICHARD kbab:
considering the fmod code for the time value is
mix X ms of data
time += X;
it is impossible for it to go backwards, unless the file looped, and it never mixes negative numbers of samples :).
Maybe you should log the timestamps yourself and see. I would expect something weird in your code maybe, i cant tell from here.
considering the fmod code for the time value is
mix X ms of data
time += X;
it is impossible for it to go backwards, unless the file looped, and it never mixes negative numbers of samples :).
Maybe you should log the timestamps yourself and see. I would expect something weird in your code maybe, i cant tell from here.
hmm. some snippets (ugly partycode, so don't look at it too long):
this is what i used for "beat detection" (BEATLEN is a constant of how many seconds one beat lasts):
(within the renderloop)
it worked ok in debug, but when running the release version, beatcount would freak and be increased way too often. then, when i turned the first line above into
the problems disappeared. sure, the way i timed stuff might not be ideal (remember, partyhack), but i can't think of any other reason than fmod sometimes giving away lower values than before, considering the latter code fixed the problem...
this is what i used for "beat detection" (BEATLEN is a constant of how many seconds one beat lasts):
(within the renderloop)
Code:
curtime = FSOUND_Stream_GetTime(apple) * 0.001f;
//curtime = BASS_ChannelBytes2Seconds(apple,BASS_ChannelGetPosition(apple));
inbeat = fmod(curtime,BEATLEN);
float lt = lasttime;
lasttime = curtime;
if(inbeat<(fmod(lt,BEATLEN))) {
beatcount++;
//more stuff
}
it worked ok in debug, but when running the release version, beatcount would freak and be increased way too often. then, when i turned the first line above into
Code:
{
float moo = FSOUND_Stream_GetTime(apple) * 0.001f;
if(moo>lasttime) curtime = moo;
}
the problems disappeared. sure, the way i timed stuff might not be ideal (remember, partyhack), but i can't think of any other reason than fmod sometimes giving away lower values than before, considering the latter code fixed the problem...
(my guess about the difference between the debug/release runs being that the release run probably had a higher framerate, giving the timing problem a bigger change to pop up)
eh, yes; i've had the same shit with bass (the actual "time" popping back slightly every now and then); i think it has something to do with the mp3 format, but i won't speculate any more since i havent done any real research.
i think i just used a high-precision timer initiated using a player position poll right after starting the tune in tpb02/03 instead. worked fine (assuming that things don't get screwed up too much, but one could do a poll every now and then to check if things are still o-o-o-o-o-o-o.k.)
after that i had the luxury of having a mod ;)
i think i just used a high-precision timer initiated using a player position poll right after starting the tune in tpb02/03 instead. worked fine (assuming that things don't get screwed up too much, but one could do a poll every now and then to check if things are still o-o-o-o-o-o-o.k.)
after that i had the luxury of having a mod ;)
i indeed had the problem way heavier with BASS. playing an ogg file though, might that matter.