A newbie question.
I’m just starting to try FMOD. My problem concerns playing back an MP3 under NT.
I’m using the simple calls as described in “The Basics” section of the Tutorial: “FSOUND_Init(44100, 32, 0)”,
FSOUND_Stream_OpenFile, and FSOUND_Stream_Play. Everything else is defaulted.
When I run my app under NT, the playback of an MP3 has a “broken record” effect–snippets of the song repeat, as though the needle were stuck on a broken record. (I hope this analogy isn’t too archaic!)
The application is also drawing to the display as this happens, possibly with DirectDraw (although I cannot be sure).
Any suggestions for preventing this?
The NT box I’m running this on is at my job site. At home, where I do the development, I have Win95. I haven’t tried this particular app there yet, but won’t be surprised if I don’t see the problem there.
- Elly asked 16 years ago
Thanks for the information, Brett.
I wouldn’t mind trying to update the Waveout driver. Where would I find one?
Also, I was wondering if trying feeding callbacks from a TMemoryStream would work better. This raises the question: does the buffer size set by FSOUND_SetBufferSize refer to the buffer read from disk, or to a buffer used to supply data to the sound driver or card?
Thanks for the information, Brett!
I’ve both set the buffer size to 200ms, and explicitly set WINMM in NT and Direct Sound in Win95, and been successful.
I’m going to try removing the explicit driver setting to ensure that things still work okay.
I’m discovering that what I describe as “broken record” is the sound card repeating what’s in its buffer until more data is suppled; this corresponds to skips when I was using Eldos Sounds.
I’m not just a newbie to the software; I’m not familiar with a lot of the sound reproduction terminology. It this “latency?”
‘Latency’ is the delay between issuing a sound and hearing the sound.
What you are calling a “broken record” is caused by a ‘buffer underrun’. The routine writing the buffer is writing too slowly (or you can think of it as the routine reading the buffer is reading too quickly). Since audio buffers are circular by design, the reading routine just keeps going. You only hope that the writing routine can keep up.
A ‘buffer overrun’ would be the opposite case. The writing routine is writing too fast and overwriting audio before it was played. This would sound like a record “skipping”. Usually overruns are only an issue with burning technologies, as most audio programs are smart enough to stop writing audio is there is no more buffer space. I would think that most burners have a similar circular buffer and follow a similar process, except that timing is much more critical.
Usually when you let FMOD to choose the output by itself you get the right results. In WinNT try to have the WINMM parameter set. Check the help file on how to set the driver, and output. (Direct Sound output will certainly not sound good, since DirectX is not fully supported in NT)
[quote:it18z1d1]<< In WinNT try to have the WINMM parameter set. >>[/quote:it18z1d1]
Dear C U,
Thanks, but since I’m not setting this myself, supposedly WINMM is being selected for me. But I’ll give it a try unless I hear of something more definite.
- Anonymous answered 16 years ago
Please login first to submit.