Altering default DirectSound audio renderer buffer size

Question

I've implemented a custom "sample grabber" filter for DirectShow. I grab samples with my host app, perform an FFT on it, and display the results via Direct3D.

The problem is there is nearly a 1 second delay between my visual result and when I hear the audio (the data is visualized before I hear it).

I've looked into it and the reason is that the default audio renderer has an internal one second buffer, as stated by this guy. He states that implementing either IAMBufferNegotiation or IAMPushSource should solve the problem. I have tried both and neither seem to make a difference.

I was curious if anyone else has had the same problem, and I want to make sure there is no other (easy) solution before I write my own audio renderer.

ALL input is appreciated!

• Roman Ryltsov: IAMBufferNegotiation does reduce the delay, you perhaps did it wrong. This covers capture delay, and on playback side there is basically no overhead at all since it is expected that you preload data, and you control effective rendering time by properly time stamping the data.

Answer 1

Instead of changing the audio renderer filter's internal buffer size, you have to synchronize your drawing (rendering the result) with sample time stamps of the buffer that you calculated the FFT. You can use IReferenceClock::AdviseTime for the synchronization.

• drunkmonkey: If I do that, I would have to sit on almost one seconds' worth of floats. I don't feel comfortable doing that, as it could be a lot of memory depending on the system configuration (well, more memory than should be necessary).
• msh: @drunkmonkey: if you reduce audio renderer memory too much, you can drop samples while playing and that cause some distortions like clipping.