The Audio Setup dialog panel allows you to setup the connection to the audio device.
On MacOS, 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.
The latency 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 from eg. a microphone is not possible then.
To use audio input and be able to record it, you need to use ASIO.
Note that changing the audio device settings outside MuLab while MuLab is running and not in the Audio Setup dialog mode is an unsupported case.
If you want to change anything about the audio device settings, inside or outside MuLab, make sure MuLab's Audio Setup dialog is open because when opening the Audio Setup dialog MuLab safely disables processing and when you're done with the Audio Setup dialog MuLab safely restarts processing.
Number Of Audio Processor Threads
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 graphical user interface (GUI) might become less responsive when the CPU is heavily occupied by processing audio.
The GUI 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 GUI is reacting quickly, then limit the 'Number Of Audio Processor Threads' to maximum - 1 so that always one real CPU core 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 plugins 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.
MuLab CPU meter vs System Process Monitor
When MuLab operates in multi-core mode, there are several audio threads (CPU cores) working at the same time.
These audio threads try to process all necessary audio (synths, samplers, effects, ...) as quick as possible.
But when plugin Y receives audio from plugin X then plugin Y cannot be processed before plugin X has been processed.
And so sometimes it's necessary to wait before processing a plugin until all of its upstream plugins have been processed.
The System Process Monitor calculates CPU usage whenever a CPU core is active.
Even when MuLab keeps a CPU core waiting to process audio, because upstream audio is not yet ready, then the System Process Monitor measures that as actual CPU usage.
When you add an extra parallel plugin it might be, depending on the modular routing, that some of the waiting time is simply replaced by processing time and hence the System Process Monitor will not increase the CPU usage.
Other audio software might choose to constantly switch on and off these audio threads depending on whether there is a need to wait for upstream plugins.
Constantly switching on and off the audio threads does take a bit of CPU too.
MuLab does not constantly switch on and off these audio threads and that's why the System Process Monitor might give different values for different audio software.
These different System Process Monitor figures do not say anything about the efficiency of the processing itself.
The 'waiting for an upstream plugin' is measured by System Process Monitor, but this CPU time is not wasted.
MuLab's own CPU meter works in a completely different way than the System Process Monitor.
It calculates the available time to process an audio block, then measures the actual time it took to process the audio block, and shows that as a percentage value.
That's the most relevant figure.