0
0

I have been using FMOD 3.73 and 3.74 for a while now, and I was looking at trying FMOD EX out. I have a few .IT files that wouldn’t play for me under FMOD 3.x, and I was hoping that the extra effects added to .IT playback within FMOD EX would allow me to play them under that library instead.

Unfortunately, I can’t seem to get any XM/IT files to play successfully under FMOD EX. I’m using the pre-compiled 4.00.37 Linux version of the library, which I downloaded via fmod.org. Using the example programs as a base, I tried loading several XM and IT files as streaming Sound objects via createStream() (using the “playstream” sample program, and then later the “useplugins” sample program). The file loads, and a call to getFormat() shows that the file type is successfully determined.

But, when I actually play the Sound, I either don’t hear anything (IT) or I hear quiet clicking noises at regular intervals (XM). I’m confused as to why this might be happening, since I can fire up the “simple” test application from FMOD 3.74 and play the same files with no trouble at all. I have found from reading through the forums that FMOD EX uses pretty much the same module playback code that it did in the 3.x series, so I suspect that I’m not setting something up correctly.

Is the “playstream” sample application basically ready-to-go for playing tracked music? Can I literally just change the loaded sound from “../media/wave.mp3” to a tracked music format and have it work? It appears that the tracked music file is loaded correctly when I do this very thing within the “useplugins” sample app (just to make sure that XM/IT codec support is there), so I suspect it should be playing the tracked file without any other fiddling. Using the default sound loaded into the test apps (like “wave.mp3”) works just fine.

Other information that might prove useful is that I’m running under a basic Fedora Core 4 distro and am using the OSS driver for output. I’ve run the sample apps as root, and /dev/dsp is free for their use, so it shouldn’t be a setup issue. It doesn’t appear to be an initialization issue.

Any ideas? Where would it be best to focus my troubleshooting?

Andrew

  • You must to post comments
0
0

Thanks Andrew, we’ll put out a new release ASAP to fix that problem.

Cheers,

  • You must to post comments
0
0

Ok, 4.00.37 has been updated so re-download it to get the fix.

Cheers,

  • You must to post comments
0
0

I just gave 4.00.37 another try and the tracked music playback is now working. I did notice that the playback has a few crackles and pops in it, but I’ll play with my playback and stream creation flags to see if any flag in particular is contributing to that problem. On the plus side, the .it files that I could not get to play under 3.74 are playing under FMOD EX. I guess it was the filters within the .it files that were holding me up after all!

Thank you for your quick response on this.

Andrew

  • You must to post comments
0
0

[quote="brett":2i1b7mkz]what sort of machine do you have? FMOD mod playback is fully declicked. The only issues you may have are possibly buffer underrun. This would only happen if you have a slow cpu.[/quote:2i1b7mkz]

I’m experiencing this on my 3.2 GHz Linux laptop that has a hefty chunk of RAM, so I doubt it’s a processing power issue. The audio chipset shouldn’t be a big deal, since I’m doing all mixing in software, but I’m using the snd-atiixp module (an AC97 chipset) for audio playback. I thought it might be an overflow bug, but lowering volumes and using a single quiet instrument is still demonstrating the behavior. I also tried flipping among several signed/unsigned 8/16 bit formats for my audio samples without much luck.

During my experimentation, I also discovered a segfault bug within the pre-compiled libfmodex.so. gdb tells me that the crash occurs in CodecIT::updateRow() when playing back an .IT file that played with no problems under both 3.73 and 3.74. I can’t really tell you much more than that, since there aren’t any debugging symbols in the library.

I do have a license for FMOD and have built and deployed apps using the 3.7x FMOD libs, and I was curious as to whether the source for FMOD EX is available yet. The FTP space showed the same files that have been there for some time, so I wanted to request the source so that I might build it myself with different compile options to see if I can isolate what might be causing the clicking.

At the very least, I’ll e-mail you with a test .IT file and some sample code so that you can see the crashing bug in action. I’ll also provide you with one of the .IT files that is demonstrating the popping during playback. You’ve got far more experience in dealing with this than I do, so I suspect you’ll be able to isolate the problem far faster than I could!

Andrew

  • You must to post comments
0
0

I think I’ve determined a possible cause for the popping I have been seeing in my XM/IT playback. I am only hearing the popping when playing a tracked music format and only when using the OSS output driver. MP3s play fine through the OSS driver. Tracked music plays fine through the wavwriter or ALSA output plugins.

I tried adjusting the decodebuffersize in the FMOD_CREATESOUNDEXINFO struct when creating the stream in case the problem was a lack of CPU power. While decreasing the size of the buffer did make the popping worse (as I had expected it to), increasing the size of the buffer did not make any improvement in the playback. As a longshot, I tried both increasing and decreasing the stream buffer size with setStreamBufferSize(). It also made no difference.

Something else is dragging things down for the OSS driver. I’m actually using ALSA with OSS emulation, rather than OSS proper. I need to use the OSS interface, though, because the target platform for our software uses OSS. Since I don’t have the source for FMOD EX, I ran strace on it to see how /dev/dsp is being initialized. I also ran strace on sample apps built against 3.73 and 3.74 to see how those libraries are initializing /dev/dsp. Here’s what I found:

FMOD 3.73 opens /dev/dsp, closes it, then opens it for actual use:

// First open and close
open(“/dev/dsp”, O_WRONLY) = 3
ioctl(3, SNDCTL_DSP_SETFRAGMENT, 0xbfb5888c) = 0
ioctl(3, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, 0xbfb58898) = 0
ioctl(3, SOUND_PCM_READ_CHANNELS, 0xbfb58894) = 0
ioctl(3, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 0xbfb58890) = 0
ioctl(3, SNDCTL_DSP_GETBLKSIZE, 0xe459a4) = 0
write(3, “\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0″…, 4096) = 4096
(… many futex() calls)
ioctl(3, SNDCTL_DSP_RESET, 0) = 0
close(3) = 0

// Second open
open(“/dev/dsp”, O_WRONLY) = 3
ioctl(3, SNDCTL_DSP_SETFRAGMENT, 0xbfb5885c) = 0
ioctl(3, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, 0xbfb58868) = 0
ioctl(3, SOUND_PCM_READ_CHANNELS, 0xbfb58864) = 0
ioctl(3, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 0xbfb58860) = 0
ioctl(3, SNDCTL_DSP_GETBLKSIZE, 0xe459a4) = 0
write(3, “\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0″…, 4096) = 4096
( … application continues from here … )

FMOD 3.74 appears to do the same thing with the exception of the flags used on the open() call to /dev/dsp:

// First open
open(“/dev/dsp”, O_RDWR|O_NONBLOCK) = 3
// Second open and initialize
open(“/dev/dsp”, O_RDWR|O_NONBLOCK) = 3

FMOD EX just whips through the first open() and close() and gets right to business:

// First open
open(“/dev/dsp”, O_RDWR|O_NONBLOCK) = 3
ioctl(3, SNDCTL_DSP_RESET, 0) = 0
close(3) = 0
// Second open
open(“/dev/dsp”, O_RDWR) = 3
brk(0x9ab4000) = 0x9ab4000
futex(0x9a74120, FUTEX_WAKE, 1) = 0
futex(0x9a74120, FUTEX_WAKE, 1) = 0
ioctl(3, SNDCTL_DSP_SETFRAGMENT, 0xbfddd674) = 0
ioctl(3, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, 0xbfddd670) = 0
ioctl(3, SOUND_PCM_READ_CHANNELS, 0xbfddd66c) = 0
ioctl(3, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 0xbfddd668) = 0

Looking over this output, I noticed two things:

  1. FMOD 3.73 does not use the O_NONBLOCK flag when opening /dev/dsp.
  2. FMOD EX does not check the SNDCTL_DSP_GETBLKSIZE ioctl().

FMOD 3.7x plays back tracked music without popping on my development station (using OSS emulation via ALSA) and also plays back tracked music without popping on our embedded hardware (using actual OSS). FMOD 3.74 plays back tracked music without popping on my development station, but is pops while playing on our embedded hardware. FMOD EX playback pops on my development station, and I can’t put it on the embedded hardware because I need to build it from source to test it.

Any ideas?

Andrew

  • You must to post comments
0
0

Ten out of ten for sleuthing Andrew! 😀

I’ll get your theory tested and let you know how we go.

Cheers,

  • You must to post comments
0
0

Hi Andrew,

Would you be able to send one of the IT files you have that is popping during playback? None of the ones I have seem to do this.

Thanks :)

  • You must to post comments
Showing 7 results
Your Answer

Please first to submit.