[wdmaudiodev] Re: very low latency audio and a C# UI?

  • From: Tim Roberts <timr@xxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Thu, 26 Feb 2009 10:49:39 -0800

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.

Other related posts: