Pausing audio renderer

[franknatoli]

If you are playing video and audio and wish to pause, you must pause the audio renderer else a ticking sound is heard while the playback underruns. But if you pause the audio renderer immediately after loading data into the buffers, the data in the buffers is not drained but waits until the audio renderer is unpaused. This has unpleasant effects. The video, which frame by frame is under the direct control of the program, is stopped on a known frame, but the audio, which is subject to an unknown amount of buffering within the audio renderer, first lags going into the pause, then has a burst of old data coming out of the pause.

The class has a protected method called "DrainBuffer", but that of course is inaccessible to code that externally instantiates the class.

How to flush the audio renderer data before pausing? Or how to know when to put pause in effect so as to not leave buffered data pending?

[Sergey_O_Intel1]

To say the truth I don't quite understand the issue. Synchronization is always driven by audio i.e. you get timestamp of current audio sample and make your decision whether to show the next video frame or not. Why should you drain the buffer? You should know nothing about it at all. You should just feed the render with audio samples and that's all. Once you pause the renderer you get the same timestamps.

Sorry if I didn't catch your question.

-Sergey

[franknatoli]

If you are performing ordinary playback, and choose to pause the playback, then resume at the point of pause, no problem.

But if you choose to reposition, e.g., rewind to start, or jump earlier or later in the playback stream, after resume you do NOT want to hear anything that might have been buffered at the time of pause. You want everything at the time of pause to be flushed, and start with a new stream atthe new point of playback.

The DirectSound renderer fails to provide such a flush mechanism.

The WinMM audio renderer, extracted from the v5.3 UMC, contains the well known Microsoft waveOutReset-when-CALLBACK-and-buffers-pending bug.

I had to write my own audio renderer to get the job done, just as I had to write my own MPEG-4 fragmented file splitter to get the job done.

[Sergey_O_Intel1]

Still don't understand the issue. Audio renderer knows nothing about your reposition. It just plays what you feed it with. It can only play or not play. And there's Reset method to clean its buffer. What else do you want? Or you want to say that Reset doesn't work?

[franknatoli]

Reset doesn't work for either the DirectSoundimplementation or the v5.3 WinMM implementation. Both hang because threads are unresponsive to the shutdown request.

simple_player does not exercise the reset function. How do you know that reset functions properly?

[Sergey_O_Intel1]

I think simple_player is not supposed to use reposition and that is why it does not use Render:Reset. Simple player is just a sample and as far as I understand it was implemented a number of years ago just to see anything on the screen and to hear anything in order to test UMC classes.

Concerning hangs maybe you're right and there's a bug somewhere. Nobody's been interested inrenderers for several years. Most people use filewriter render when they test their apps. And it's quite possible that all video and audio renderers except for filewriterwill disappear in the next releases.

BTW if you're interested in this code and know where the problem is why don't you fix it yourself? The code does not seem very complex. In case of reposition you should pause the render and reset its buffer.