AndyJust to clarify - if your DSP code is C++, then what role for the C# components. Is the UI control only (routing/levels/etc) or is the UI a more active participant: does it actually have to process the audio stream in some way?
I'd package the DSP code into a C++ DLL and export a narrow API for the C# code to call. Your primary audio thread is created within the DLL and has a signalling/control mechanism based on shared events or somesuch. That is all pretty easy to organise. I think you could get read access to the audio stream without too much trouble as well - treat the C# audio sink as a slow output device to account for GC and interop overhead etc.
The blog here might be of interest: http://geekswithblogs.net/robp/archive/2008/08/13/speedy-c-part-3-understanding-memory-references-pinned-objects-and.aspx
HTH & keep us posted - I'm sure we'll have to face this issue before too long.
Jerry Voelkel, Andy wrote:
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