I still have the occasional problem with it. After I receive the notification event I check the play cursor to see how many frames went by. I will send you me code when I get home and see if you can tell me if you see anything I could do better.
Charlie ___ Sent with SnapperMail www.snappermail.com ...... Original Message ....... On Sat, 9 Sep 2006 16:38:21 +0900 "Kenichi Aramaki" <[EMAIL PROTECTED]> wrote: >Hi, > >Do you still have cursor overrun problem? >I also tried to rewrite the threads with DirectX which is not completed yet. >As I tested, I did not see blocking or cursor overrun in my test program. >I am going to rewrite speaker thread as a first step and I will post my code >if I accomplish it. > >Regards, >Kenichi Aramaki > > >2006/9/2, Charlie Hedlin <[EMAIL PROTECTED]>: >> 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. >> >> Charlie >> >> Alexander Chemeris wrote: >> >> H _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
