The status bar provides information about your Mixbus’s status including current settings and realtime performance indicators. Right-click on the status bar to enable or disable the available displays.

  • File: Audio file format setting (from Session->Properties->Media)
  • TC: Time code format (from Session->Properties->Timecode)
  • Audio: Sample rate / Buffer latency (from Window->Audio/MIDI Settings)
  • Buffers: p (playback) and c (capture) – these numbers indicate the ability of your disk to keep up with Mixbus’s playback and recording buffers. If either number is reduced to zero, then Mixbus will stop playback and report an error to you.
  • DSP: Time required to process an audio block / duration of the audio block, compared to the available buffersize timing. This displays the worst-case maximum (not average).
  • X: Number of xruns : an xrun ( under -run or over -run ) is caused when Mixbus cannot keep up with your soundcard. ( see below )

Disk: Estimated remaining recording time, given the current settings and number of record-armed tracks.

Of these reports, the Xrun counter is the most important. If the xrun counter is increasing while you are recording or playing, it means that you have exceeded the capabilities of your system, and you are likely hearing clicks and pops.

The typical methods to minimize the CPU load are:

  • increase the “buffer size” in the Audio Setup dialog
  • optimize your system for audio performance; such as choosing “optimize for background tasks” in Windows.
  • use a lower sample rate, reduce the number of tracks
  • reduce the number of plugins in your session.
  • And of course using a faster computer, with more CPU cores, is desirable.

The CPU meter on your computer averages the cpu usage over a very long period (perhaps one second).
In digital audio, the timing is much more sensitive. When the soundcard passes us a buffer, then we have to wake up, process the audio buffer, and return it to the soundcard before the soundcard needs to play it out. If we don’t wake up in time, or we don’t get finished in time, then you hear a “click” caused by the (we call these xruns, short for over-run or under-run).

In the case of a 1024 buffer size, this has to be done within (1024/44100) 25ms, or about 1/40th of a second.

This is complicated by the fact that it’s the OS’s job to “wake us up” and tell us that the soundcard has some data for us. Some OS’s and drivers are better at this than others. But let’s say it takes 5ms before we are even alerted that some data is available. We now have 20ms left to process the audio. If it takes us 10ms to process the audio, then we are finished within 50% of the allotted time and that’s what we display in the meter. This is a very accurate indication of your computer’s ability to process audio.

This also explains why the selected buffersize is so critical to the DSP load. A 256-sample buffersize is about 6ms, so if your computer sometimes waits 5ms after receiving the soundcard interrupt before it “wakes us up”, we only have 1ms remaining to do our work.

For more information on factors impacting the performance of your computer please see this video:
CPU Performance vs. Real-Time Performance in Digital Audio Workstations


Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment