I am working on a class toolkit in C# to save having to reinvent the wheel all the time.
I am calling System::update from a timer event in my test apps UI every 100ms.
MP3 files loaded via System::createSound play back correctly, but if I load it via System::createStream the playback starts but there is stuttering in the output.
I also checked the C# playstream example and it also stutters during playback.
I am using version 4.07.09
Please read the win32 platform specific issues tutorial in the documentation. The only reason it would stutter is your program is strangling or halting the stream thread too much, the file system is too slow to keep up with the read requests from the streamer, or your pc is slow and needs a larger buffer size. It can only be one of these 3 options. Stream buffersize can help but if it is the first problem, then you need to fix the multitasking capability of your app.
Been through all the documentation and I can’t figure it.
My box is a 3Ghz P4 with HT
When I do my testing the box is idle, I also can rule out bottlenecks from the HDD since I regularly do DVD Burns at 8x with no issues.
I have set a 2Mb stream buffer as some major overkill to rule out buffer problems and my app is a simple WinForms app with no threads, and I am calling System.Update() in a timer event. I have set the timer to everything between 10ms and 250ms with no change in the output.
You can download a 15sec recording of the output from [url:1bw6zsyx]http://heffo.kicks-ass.net:3210/example.ogg[/url:1bw6zsyx]
Did you try decode buffersize? Did you try something other than your application such as the C based fmod examples? My original statements still stand. It could even be a rogue app on your machine that is eating cpu time, this is not a normal thing so the issue is on your side, you will just have to keep looking.
Anyway, try with this setup, just to see how it works:
m_system->setFileSystem(0, 0, 0, 0, 8192);
This will allocate 256KB of stream buffer (double buffering) and read data in 8KB blocks.
I’ve kept the default dsp buffer size of 1024 bytes, but increased the number of buffers from 4 to 7. This gives an average mixer latency of 145ms. I’m probably going to tweak this more to get less latency, but this works for now.
A bit on the side, but if you read from a dvd, you should probably increase the read size for the file system from 8KB to something that matches whatever the OS reads from the dvd in one read call to reduce the number of expensive seek calls.
- jornj answered 11 years ago
Thanks for the suggestions guys, I did managed to track it down. I have been bashing my head against the wall trying to track down the problem with my system (If Brett doesn’t think the problem is in FMOD then that’s good enough for me :D). This morning during a head-bashing session I suddenly remembered about a month ago EAX Reverb got stuck on when another app crashed (which also persists through reboots, got me buggered why!) and since I run my TV/DVD through my PC to my stereo system, my television was getting reverb applied which gets rather annoying.
When this happens I disable all acceleration, disable the soundcard, reboot, renable the soundcard, turn up the acceleration again and the reverb has cleared. It seems in this case, I forgot the last step in the process and didn’t turn up the hardware acceleration. Once I turned it up the stuttering went away. Seems the emulation driver in windows can’t keep up with FMOD 😆
Sorry for the run-around guys!
[quote="brett":1n02xud6]If you used setDSPBufferSize you wouldnt have had this problem it is already explained in the documentation about stuttering.[/quote:1n02xud6]
Before I realised I had hardware acceleration turned off, I used setDSPBufferSize. I tried both more buffers, larger buffers, and a combination of the two and it made no difference.
FMOD was mixing the data just fine, I would have expected that if it was FMOD doing the problem, the larger DSP buffer size would have caused the delay between the clicks and stutters to increase but there was no such increase.
I know windows has it’s own mixer (and associated buffers) and I am guessing that with hardware acceleration completely turned off, windows was doing all it’s own mixing instead of using the soundcard’s resources to do it, and windows wasn’t quite keeping up feeding it’s own buffer causing it to either overrun or wrap at a fixed interval before new data arrives from FMOD, causing the artifacts at a constant rate regardless of the buffering used in FMOD.
Please login first to submit.