[wdmaudiodev] Re: very low latency audio and a C# UI?
- From: "Voelkel, Andy" <andy.voelkel@xxxxxxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Thu, 26 Feb 2009 11:22:21 -0800
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.
Other related posts:
