|
Ok, I have rewritten SpkrThreadWnt to use directx (I created a
SpkrThreadWntDx and each are wrapped with #ifdef). My echo path delay
was 230ms, and now it is 77ms. I am sure I can cut more with the
MicThread. I was able to get rid of the bursty audio and drop the SpkrQueue to 3 frames (with a Skip of 1) and the N_OUT_PRIME from dmaTask.h to 1 from 8. Unfortunately I have created a big mess with the rest of the media threads. Ocasionally I am getting blocked in the SpkrThread. DirectSound goes right ahead and plays the circular buffer and passes my write cursor. I have added code to move the write cursor back in front of the play cursor, but I am missing a number of chances to fire the flow graph. My audio is now piling up in the jitter buffers and I have even more delay than ever. I believe this is fixable. Right now I am thinking I will have it count the number of frames it has to advance the write cursor and double fire the flow graph until it catches up. This seems like an ugly hack unless it is a rare occurance. I need to figure out where I am blocking. For all I know it is the debugger. This post was mostly to show that the echo path delay can be reduced with directx, but I don't have a working solution yet. Any debugging pointers would be apreciated as well. Charlie Charlie Hedlin wrote: I considered going this route, but I think we are only likely to gain 100ms or so, and I might be able to gain even more with DirectSound. I will post with test results this afternoon. |
_______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
