The Audio Setup dialog panel allows you to setup the connection to the audio device.
On OSX, this is via a Core Audio device driver, on Windows this is via an ASIO or MME device driver.
On Windows best of all use the specific ASIO driver that comes with your sound device.
If no such driver exists then you could try Asio4All.
Please note that Asio4All is not a MuTools product, if you need support on Asio4All please go to the Asio4All website.
If Asio4All isn't working for you, then select Driver Type = MME Audio, Driver Name = Sound Mapper.
General note about choosing the best audio buffer size: The bigger the audio buffer size, the lower the chance you will hear unexpected clicks in the audio when using a lot of processing power. But at the same a bigger audio buffer size also causes a higher latency, that is the time between pressing a MIDI note or clicking play and the moment that the audio effectively comes out of the speakers. So using a smaller audio buffer size gives you a lower latency, but then make sure your CPU can handle it, otherwise clicks may appear in your audio because the CPU can't process it all quick enough.
In the Windows version, when using the MME audio system, the audio buffer size = number of blocks * block size. Note that 8 * 512 may give a different behaviour than 4 * 1024, this is system dependent and the only way to know is by experimentation. Though the default setting of 8 * 512 should be fine on most systems
Note that when using Windows MME, there only is audio output, no audio input, so recording audio is not possible then. To use audio input and be able to record it, you need to use ASIO.
About the Number Of Audio Processor Threads parameter:
The 'Number Of Audio Processor Threads' defines how many parallel threads will be used for audio processing.
This is only relevant on real multi-core/multi-processor systems.
Note that hyper-threaded cores are not real parallel multi-cores and should not be taken into account.
Also note that when you set this value to the maximum, then it might be that the user interface (UI) will become less responsive when you're generating/processing a lot of audio because the CPU has almost no time anymore to handle the UI.
The UI includes tasks like drawing to the screen, processing mouse-clicks and key presses, loading and saving projects and presets etc.
So if you want to make sure that the UI is reacting quickly, then limit the 'Number Of Audio Processor Threads' to maximum - 1 so that always one real CPU is available to process the UI. So it's a balance you can choose for yourself: More audio power or more UI power.
Also note that if you're using VST plug-ins that do multi-threading of their own then you have to take that into account when choosing the best value for the 'Number Of Audio Processor Threads' parameter. It's all about common sense: It makes no sense to launch more audio threads than there are real parallel CPUs, at the contrary it will result in a less performant system as too many audio threads will be 'fighting' for a limited number of real parallel CPUs.
Note about the CPU usage value in the system's process monitor: When MuLab operates in multi-core mode, there are several audio threads working at the same time.
E.g. if you have a quad core machine and have enabled 4 audio threads, then inserting a single rack/synth might result in a higher than expected CPU usage value because the other 3 audio threads are already taken into account too, while they're not yet really processing, but 'waiting' to take work, and the waiting is taken into account too.
But thing is that when inserting a 2nd rack parallel to the first one, then this does not necessarily increase the CPU usage value because the 2nd audio thread will simply switch from waiting to processing.
It may increase the CPU usage value if that 2nd rack takes more time to process than the first rack. The practical CPU usage value will depend on the most heavy of all parallel audio threads.