Hello, On 8/31/06, Charlie Hedlin <[EMAIL PROTECTED]> wrote: > My understanding is that the SpkrQ is only as large as it is because the > SpkrThread moves audio in bursts of 5-7 frames. I have done some tests that > support this. If I can reduce the number of frames that back up before the > SpkrThread processes them I should be able to shrink the SpkrQ. I tought about using 3-thread mode instead of 2-thread. I.e. use one separate thread to fire start frame events every 10ms. We already use high definition timer to fire this events when no audio device is active - I think we may totally separate it. Then, we could simply write audio data to the speaker device -- it will be buffered inside the driver (at least MSDN state so). I hope this will greatly reduce speaker-side delay. But I guess we still will have problems on the mic side. This is a poiny to more testing..
Regards, Alexander Chemeris. _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
