What type of cross-process communication do you think would be quickest? I need to call a procedure in another process (that is also my own) to process a small array of floats, and return to the caller ASAP. I need this for routing of audio data (as you might have guessed). RPC should be blocking, and keep under 1ms latency. (so, the Win32 kernel will have to switch to the target thread immediately, not wait for next 16ms time-slice). Processing of that float-array takes just ~ 20k cycles usually.

I'm thinking of making this a small public open-source project to be used in any ASIO-enabled audio software; and thinking of making the app register itself as a virtual ASIO card. (no drivers involved, ASIO enumeration is done by searching for keys in the registry, and manually loading a specified dll there).

Let's assume the float-array and all procedure-call arguments are already nicely memory-mapped with CreateFileMapping/OpenFileMapping/MapViewOfFile. So, we just have to somehow switch to the target thread immediately RPC-style, then immediately after processing - switch back to the calling thread.



Posted on 2008-06-29 21:42:28 by Ultrano
COM server/client comes to mind. Or maybe a global mutex? But I don't think it's possible to force Windows to execute another process *immediately*. You would need 2 cores actually executing the spoken code and one sending the synchronization command to the other one. They have to be running at a given moment, because if they're not, the scheduler will start them in the next 'time-slice'. It would mean that you can't use any efficient wait states, but instead do loops until you get the signal to start the work. And even that doesn't guarantee low latencies because your application may be interrupted at any moment (it's a preemptive multitasking OS after all). So, acquiring incredibly low latencies should be done in some other way, I think. Why would you need so low latency, anyway? :) Switching to another process just to execute 20k cycles would be a huge waste of time in the scheduling part of the kernel. Maybe try acumulating the data to some larger amount? Dunno. Or maybe I don't understand what you want to accomplish ^^'
Posted on 2008-06-29 22:41:01 by ti_mo_n
Different music-studios/apps provide different instruments/sfx/inputs, so it would be interesting (plus very useful) to route audio inter-process.
Another idea of solving this might be to CreateProcess just one slave application, and call somehow the callback-function (that renders audio). Maybe like that a thread-switch can be avoided?

Musicians need < 1ms latency, a compromise cannot be made :) . And I don't want to hog-up 2 cores, if possible.
Posted on 2008-06-29 23:17:11 by Ultrano
Musicians need low latency, but MIDI doesnt.
You can synchronize the inputs through delayed buffers etc.
Do you think that the internet provides such latencies?
And yet musicians can play together without noticing the delay.
Posted on 2008-07-01 03:28:16 by Homer
At 20ms even untrained musicians notice. Trained ones grumble at 3ms. At 40ms it's horrible for everyone. At 100ms you can barely just change melody patterns.
Posted on 2008-07-01 16:44:53 by Ultrano