If you have time to watch this (very good, but very long) video, you can learn more details: And that's a lot to ask of a general-purpose computer, because they weren't built for that kind of real-time consistency. But in a high-profile recording session, you wouldn't want even a single click to occur, and get captured in your recording. The clicks won't be heard in the final export. How bad is a "click", really? If you are mixing by yourself in your home studio, perhaps you don't care if the system clicks once or twice an hour. These problems can be very hard to troubleshoot. Or it could be something entirely internal to the computer motherboard: perhaps the video-card occasionally hogs the internal bus and doesn't let the soundcard alert the motherboard that it has a buffer. perhaps by an incoming email a bit of scheduled disk cleanup or a screensaver suddenly kicking in. Yet another complication is the fact that sometimes the computer can be interrupted. There's plenty of CPU power to get the work done if we are woken-up in time but if the OS is slow to wake us up, then the desktop CPU usage can look very low, but you are still encountering glitches. 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. This explains why the selected buffersize is so critical to the DSP load. This is a very accurate indication of your computer's ability to process audio. If we have a 20ms buffer size, and 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. Our DSP meter takes this timing into account. 2/3rds of the time was already wasted before Mixbus even had a chance to operate! But in the 64-sample buffersize, we only have 0.5ms left to work. In our 1024 example, this leaves us a heathy 24ms to work our DSP magic. Let's say that the computer always responds within 1ms that the soundcard is ready.
#Mixbus 32c users drivers#
Some OS's and drivers are better at this than others. 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.
Reduce the buffersize to 64, and the computer has to wake up every 1.5 milliseconds.
In the case of a 1024 buffer size, this has to be done within (1024/44100) 25ms, or about 1/40th of a second. If we don't wake up in time, or we don't get finished in time, then you hear a "click" caused by the lack of audio (we call these xruns, short for over-run or under-run). When the soundcard passes us a buffer, Mixbus has to be alerted by your OS, process the audio buffer, and return it to the soundcard before the soundcard needs to play it out.
This is a useful number to know if we are trying to finish a hard math problem, or if we are measuring battery usage.īut in digital audio, the timing is much more sensitive. This gives a general indication of how busy your CPU is. HOWEVER: even the most powerful cpu can have very poor realtime audio performance if it is not adequately "woken up" at regular intervals to service the incoming audio buffers from the soundcard.įirstly, you need to understand that the CPU meter on your computer averages the cpu usage over a very long period (perhaps one second). This means that if Mixbus is running smoothly, you won't accidentally overload your system if you enable all the channelstrip features while you are mixing.Ī modern i7-class processor has the capability to run 100s of tracks and lots of plugins in Mixbus. Note that, because of the way Mixbus works, it does not increase the cpu to enable all the EQs and compressors the DSP load for that processing is already pre-allocated when you run Mixbus. Nevertheless, an older 2GHz CPU should be able to handle dozens of tracks and several plugins, with reasonable settings. By default, Mixbus requires significantly more CPU resources than a typical DAW, because it is emulating the operation of an analog console.
0 kommentar(er)
