Is real-time signal processing possible under Windows?

We do it in on a Windows platform with our Data Acquisition software - Dewesoft X. Some of our customers are using input signal and output it in around 10ms on Windows PC systems.

Some of our DAQ devices have dual bus capability when one of the data buses is bypassing PC completely and send out data in real-time...

The only downside is you need to use our signal conditioning HW. If that is not an issue to you you can try.

Windows is not real time OS, so well, you don't have true realtime processing capabilities in Windows.

With Windows Vista, Microsoft offered a new API that among other thing targeted strict performance, where Exclusive-Mode Streams promised performance close to real-time. This is achieved with a few powerful things working together, including short and exclusive path to audio hardware from user mode components, specific multimedia scheduling. Let me quote Wiki on this:

For audio professionals, a new WaveRT port driver has been introduced that strives to achieve real-time performance by using the multimedia class scheduler and supports audio applications that reduce the latency of audio streams. As a result, user mode applications can completely govern streams of audio without any code execution in the kernel during runtime. WaveRT allows the user mode application direct access to the internal audio hardware buffers and sample position counters (data in the memory that is mapped to the audio hardware DMA engine). It allows applications to poll the current position in the DMA memory window that the hardware is accessing. WaveRT also supports the notion of a hardware generated clock notification event, similar to the ASIO API, so that applications need not poll for current position if they don't want to. WaveRT however works only with PCI, PCI Express or onboard audio devices; it does not work with USB or FireWire interfaces which are more widespread in the professional audio industry.

This new mode of operation opened exciting opportunities for low latency audio processing, such as reported by happy users:

I get perfect rock solid stable audio with 2ms buffers + 0.5ms latency, compared to semi-stable audio in 4ms buffers (+5ms output latency), with ASIO.

Depending on whether this real-time approximation is good for you, Windows might still be a good environment for the mentioned task.

Whether this is possible or not depends on your latency requirements, i.e. the total delay between input and output. A good starting point could be setting up a digital audio workstation using recording software such as ProTools, Sonar, Ableton, Cubase etc. These work with inexpensive (sort of) I/O hardware and come with low latency optimized drivers. Some of these have "plug in" interfaces that allow you to loop in your own signal processing. A popular format is VST from Steinberg which is supported by many hosts. It used to be open and free but may require a license now.

This http://www.kvraudio.com/wiki/ is a good resource for that sort of thing.

If you want to process in Matlab you may have to write your own drivers. I've seen that done with DLLs and also native JAVA interfaces. You can also hack something together with audioplayer() and audiorecorder() but these may require fairly high latency to deal with Windows interrupts and doing other stuff. In essence you setup a GUI control with a callback that's triggered to a time. In the call back you read all available inputs, process them, shove them into the output and hope for the best.

In general it helps to keep the Windows box as "clean" as possible, i.e. no network connection (while you process audio), no anti-virus software and run only the absolute minimum of start up items, software & services.

if you need to keep jitter (assuming that's what you mean by "wiggle" :) down to <1ms I'd say forget Windows. Does the absolute latency from input to output matter, or is it just the jitter?

You might manage it some of the time, but guaranteeing it is unlikely. What's the penalty for failing to meet the deadline? Will it blow up speakers? Drive a robot arm too hard against an end-stop? Or something more benign?

The fact that your output is USB is also not likely to help in the jitter stakes as there's lots of extra OS interaction there, and the topology of the bus will also hinder your potential latency - if your output is at the end of a string of a few hubs, for example.