[Portaudio] underruns, fix
Wed, 20 Nov 2002 14:41:10 +1100
"Phil Burk" <firstname.lastname@example.org> wrote:
> > This sounds reasonable, but I think it might be good to completely
> > the way PA uses DSound - ie using polling. I have been receiving reports
> > that the V19 DSound version is performing considerably worse than the
> > version.
> I was told that using the MultiMedia timer and polling would give the
> latency., But it is certainly be worth investigating some alternatives.
I think Glenn's suggestion of rescheduling the timer to fire at the time
that the buffer is estimated to be finished is a good idea, and should
significantly improve latency when the system or the callback is using a
significant amount of CPU time. I had a look at the V19 code, and there are
going to be a couple of issues with adding dynamic timer rescheduling:
- it's not clear what should happen if the timer callback occurs just before
enough samples are available (ie is three a threshold at which it's better
to spin-wait rather than request another timer callback?
- when the client has specified paFramesPerBufferUnspecified, a periodic
timer might be ok - although because the buffer adapter may not copy data to
the DSound buffers until it has processed as much data is available, it
might be good to chunk the available data into blocks that are less than
half the total DSound buffer size so that some samples are available as
quickly as possible, otherwise underruns are more likely in high cpu-load
> One situation where DSound will perform worse than WMME is when the DSound
> device is emulated on top of WMME. I have seen latencies of 400 msec for
> DSound when using emulated devices.
Ah yes, I had forgotten about that. I'm not sure if that was what was going
on in this instance or not.