Hello, On 9/8/06, Charlie Hedlin <[EMAIL PROTECTED]> wrote: > Alexander Chemeris wrote: > On 9/8/06, Charlie Hedlin <[EMAIL PROTECTED]> wrote: >>> my new code is running at about 110ms. I dumped the whole priming the >>> buffer concept and dynamically adjust to the delay in the DirectSound >>> drivers. >> Did you rewrote mic thread too? Does this 110ms come from mic thread? > I rewrote the mic thread, but it had no measurable impact on the latency. > I believe it should use DirectX as well for consistency, but that is about > it. So, mic thread still use Windows Media. That is what I want to know. How this 110ms are distributed among mic/spkr/flowgraph/etc? Did you do particular measures?
> There are a number of inactive code blocks and unused variables I need to > clean up. I can send the patches as is if you are interested. I'm interested, but will not be able to review them before October. I'll go on the vacation next week. :) So feel free to post them to the tracker when you consider them stable. > There are definately events that happen in windows that cause the thread to > block and miss some frames. The main loop of the thread executes in far > less than 1ms most of the time, but sometimes it will get blocked for 30ms > at a time. I need to start up ethereal and messure the outputs. It seems Did you use rdtsc to measure such small delays? How Ethereal could help you here? > to happen when using WaitForSingleObject or WaitforMultipleObjects which is > used in the underlying message passing mechanism as well. It is also > possible that some unexpected delays could occur when accessing the SpkrQ or > MicQ objects, but these are both done with NOWAIT and shouldn't ever block. OsMsgQShared::recieve() and OsMsgQShared::send() should not block with NO_WAIT if code behave as I understand it. Do your thread runs as timecritical? > I should also move the mediathread timer into the WNT dma task instead of > SpeakerThreadWntDX.cpp. It won't make any functional difference, but it > would make the distinction easier to recognize. Yes, it will be good. > The delay using my new code seems to be in line with CouterPath's X-Lite > phone. Sounds inspiring.. :) Regards, Alexander Chemeris. _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
