Hi Tim, Thanks. That helps, just to know it is possible. One of the things I don't know how to do create an "unmanaged threads". I was under the impression that threads themselves aren't managed or unmanaged, only code was. And therefore I don't know how to arrange it so that the gc knows that my low latency thread doesn't contain unmanaged code and thereform doesn't suspend it". Do you have any book or other reading recommendations that would enlighten me on such issues? - Andy ________________________________ From: wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Roberts Sent: Thursday, February 26, 2009 10:50 AM To: wdmaudiodev@xxxxxxxxxxxxx Subject: [wdmaudiodev] Re: very low latency audio and a C# UI? Voelkel, Andy wrote: I apologize for asking what is a bit off topic, but I am getting desperate. I have been trying to figure out how to write audio applications which implement DSP algorithms with very low latency but which can have a C# UI. I know various ways to satisfy each goal separately, but not together. The chief problem is that the only way that I know how to achieve extremely low latencies is by not having a garbage collector suspend my high priority audio thread, yet I do not know how add a C# UI to a program without introducing the potential for gc interruptions. I have searched the internet in vain for someone who has done this, and I have pondered all sorts of ugly workarounds, none of which are very attractive. Most involve having the UI run a separate process from the audio thread. There must be an interest within Microsoft to see this sort of thing work, so as to encourage applications that use as much C# as possible. Does anyone know where I could dig up the knowledge that would be necessary to see if this concept is feasible? For all I know, the right hacks with a mixture of managed and unmanaged C++ might make this idea possible. But I don't know where to obtain the detailed knowledge necessary, and I certainly don't want to become an expert at this sort of programming if it has no hope of paying off in the end. I write this here in the hope that someone involved in driver development might have had to consider issues such as this. I would be grateful for any help, Remember that the garbage collector only runs if there is garbage to be collected. If your C# app isn't generating and releasing a lot of objects, then there won't be garbage to collect. Unfortunately, it's tricky to write a managed app that doesn't cycle through a lot of objects. I suspect your long-term answer, as you said, is going to be to handle the time-critical stuff in unmanaged threads. That, for example, is how DirectShow .NET works. The .NET stuff is just a wrapper over the traditional C++ DirectShow implementation, which is where all of the "good stuff" happens. -- Tim Roberts, timr@xxxxxxxxx Providenza & Boekelheide, Inc. CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain information that is confidential and/or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the contents to another person, store or copy the information in any medium, or use any of the information contained in or attached to this transmission for any purpose. If you have received this transmission in error, please immediately notify the sender by reply email or at mailto:privacy@xxxxxxxxxxxxxxx, and destroy the original transmission and its attachments without reading or saving in any manner. For further information about Plantronics - the Company, its products, brands, partners, please visit our website www.plantronics.com.