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: > > 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/
