0
0

Hi,

I currently use DirectSound for all my audio output, but I’d like to switch to FMOD to support more platforms (and hopefully get less of a headache over DS “features”). However, I need to support 20 ms frame sizes for realtime generated audio with minimum output latency (for realtime voice chat).

I’ve looked at the usercreatedsound example, and changed it to be 16khz mono with createsoundexinfo.decodebuffersize = 320. I added a keystroke to change the sine function immediately, and it sounds like pressing the key results in an immediate change. Great.

Switching to FMOD_3D instead of FMOD_2D, the change is still immediate, but it’s now noisy and jittery.

Am I correct in assuming that there is no extra buffering between the call to pcmreadcallback and the buffer that’s being output? Is there a way to add some? I’d rather not increase the actual decodebuffersize to more than 20ms, as that means I’d also have to wait for (and buffer) more data from the net, effectively doubling the observed “buffering latency”.

  • You must to post comments
0
0

The 2D->3D change seems to be a DSound issue, as I have the same “problem” in my current implementation; DSound3D seems to want more data ready and has a much larger gap between the write and play cursors, and I’ve seen it restart sounds (move play/write cursor back to the start) for no apparant reason and without notification.

Anyway, the problem with having, in effect, only 2 buffers (one written and one played) is that you need to have BufferSize ammount of data ready at the time the buffer needs to be filled. For example, if I use a 200ms bufffer; Dsound just started playing buffer A, and so I’m asked to fill in buffer B. I need to have 200ms of data there, which means I’ll need to have prebuffered 200ms of data from the net. As the play cursor just started on buffer A, there’s 200ms of “buffer” there too, so I end up with a 400ms delay.

What I do currently is to divide the dsound buffer into frames, and make sure it has enough space for lots of frames (currently 50). There’s a userconfigurable outputdelay (in number of frames). Now, when directsound starts playing frame A and I get an event, I fill in the frames between “last filled frame” and A+OutputDelay. Usually this is just one frame, but if the notification came late or the system was busy elsewhere, it can be more.

If I have 10 20ms-frames “OutputDelay”, that means there’s approximately 200ms of ready data in the buffer for Dsound to play. As I only need to add 20ms each time, the total delay is 220ms vs 400ms for the two-buffer case. Any chance something similar could be implemented in FMOD?

  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.