0
0

Hello,

I’m playing multiple MP3 files loaded with createSound and compressedsample. When I am playing sounds and I setPosition (using TIMEUNIT_MS) a sound that is currently playing I hear little gaps in the other sounds. This occurs on an iPod Touch 1G with iPhone OS 3.0 and library version 00042607.

Are there any buffer settings I can tweak to eliminate this?

Thanks!

  • George
  • You must to post comments
0
0

iPod Touch 1G is one of the slower models, are you perhaps overloading the CPU? How many MP3s are you playing? are they stereo or mono?

You can check your CPU usage with System::getCPUUsage() or pass FMOD_INIT_ENABLE_PROFILE in with System::init() and connect with the Profiler.

You can tweak the DSP buffer size however this is only available with 4.27.05 and onwards.

  • You must to post comments
0
0

Hi Mathew,

I am playing stereo MP3 files, but it even occurs when I only play two:

  • Sound 1: Currently playing
  • Sound 2: Loaded up and ready to go

If I play sound 2 from 0, there will be no gap in sound 1.
If I pause sound 2 and play it, there will be no gap in sound 1
If I pause sound 2, seek within (using TIMEUNIT_MS or TIMEUNIT_PCM), there will be a gap in sound 1 when I unpause sound 2
If I am playing sound 2 and seek within it while playing, sound 1 will experience gaps.

So it looks like there are some calculations going on specific to seeking that are blocking playback. Could it be the time units I’m using?

  • George
  • You must to post comments
0
0

I’ve also tried setting position using TIMEUNIT_PCMBYTES and I still get the gaps.

  • You must to post comments
0
0

More additional data, via the profiler.

When two sounds are playing, I get about 30% avg CPU on "DSP". But when I seek, it jumps to about 50%.

  • George
  • You must to post comments
0
0

Well, this is interesting.

I upgraded to the latest dev version, 4.27.09 and without even changing the dspBufferSize, the problem no longer exists. Good job! Is there a different default buffer size with this new version? I installed 4.26.08 and still had the same problem, but it forced the buffer size to 1156. With the new version, I get this message:

[code:46669crf]FMOD: OutputCoreAudio::init : Maximum hardware read size: 4096 samples, Software buffer size: 1024 samples, Number of software buffers: 4.
[/code:46669crf]

How does these two compare?

Thanks!

  • George
  • You must to post comments
0
0

I’m glad the problem is resolved for you with the latest version.

I re-engineered how FMOD for iPhone interacts with the hardware in the dev branch. Before we were doing an on-demand mix, so the iPhone asks for 1156 samples, we mix it and return as fast as we can. However that is dangerous because if the mix takes too long the hardware starves. We now operate more like on Windows, we mix in chunks of dspbuffersize (1024 samples by default) into a ring buffer (4 buffers by default).

This new method is a lot more stable when under heavy DSP load, and the user can control the buffer size.

  • You must to post comments
0
0

Very cool. Great job! Even on the iPod Touch 1G, things are noticeably snappier! So does that mean if the iPhone still asks for 1156 samples, it just comes out of the ring buffer? Just a question.

  • You must to post comments
0
0

To keep the buffer management as clean as possible we request the iPhone hardware pull from our ring buffer in chunks of 1024 samples (dspbuffersize) however it can say no.

So it may in-fact pull 1156 samples, but the ring buffer accommodates that. We also ask the hardware what is the biggest chunk it will ever ask for (regardless of the operating conditions of the device) and we ensure the ring buffer is large enough for that. Currently this seems to be 4096 (from tests), so our default of 1024 x 4 fits nicely, however I have never seen the device ask for anywhere near that much in one go.

  • You must to post comments
Showing 8 results
Your Answer

Please first to submit.