On Thursday, March 03, 2011 06:55:56 pm Dr. Ed Morbius wrote: > I thought a bit about that when posting earlier. I still disagree WRT > dual-booting. And no, virtualization doesn't need twice the hardware by > a long shot (aggregated load averaging, shared componentry, and a host > of other savings). It needs twice the CPU and twice the RAM to work in a reliable manner for professional low-latency audio production. The DSP in Harrison Mixbus alone needs one whole CPU core pretty much dedicated to it alone; and that's just the DSP engine, and doesn't count the Ardour-based user interface; two cores is a minimum requirement to run Mixbus, as stated clearly on Harrison's website, and as verified independently by myself and others. Otherwise you get xruns, and xruns kill your quality. Not to mention the fact that the GTK GUI goes into erratic comas when you try to single-core it (even with a very fast core this is the case). Don't get me wrong; I have tried this with virtualization; it simply does not work at the latencies required when the track count gets higher. It just doesn't work; xruns will find their way into the audio. And that's on both the host and the guest; guest load can cause the host to xrun. They are after all still sharing the same bus or PCIe fabric, and high track counts at low latency already heavily stress the PCI bus and 1x PCIe lanes, for the audio interface and for the disks; do the bandwidth calculation for yourself for 32 tracks at 96kHz sampling at 24 bits from the audio interface and 32-bit floating point to the disk. And that's bidirectional. So if I'm running two instances of Mixbus, I need a minimum of four cores, and the memory balloon driver that's typically part of the guest's virtualization tools package can cause more problems that it's worth (I'm fighting this now with CentOS 4 (32-bit) under VMware ESX 3.5U5 on a server; I'm getting oom-killer hitting (typically it takes out clamscan, one of the antivirus engines I'm running on that server) after a couple of weeks of uptime, and after eight to twelve hours of oom-killer hitting, the root filesystem goes read-only and a hard reboot of the guest is required to recover; once I get some data on why, I'm going to file a bug report, since it started about two months ago after a long time of reliable uptime; perhaps a kernel or a glibc or a clamav (not in the CentOS repositories, third-party) update destabilized something, but I don't have enough data to be helpful yet). > Audio's pretty easy, as you could select between sources and output (or > input) accordingly. Low-latency audio isn't easy on Linux even on bare metal; I'm talking low-latency audio, where you're overdubbing material and need sub-50ms delay between inputs and outputs. I'm running a Tascam US-224 and a US-428 in the special raw USB mode and have achieved 11ms latencies, but that isn't easy. The preemptive kernel is required for this, and accurate timekeeping is required for this; you even have to turn off CPU frequency scaling to get it to work correctly as the latency goes down. And the audio latency has to be consistent; one reason pulseaudio is typically tossed out completely and JACK is the audio server of choice. And I'm not talking about a small number of ins and outs; with RME Hammerfall equipment and outboard converters you could easily have 32 or more tracks in and that many out running concurrently. You could have Ardour/Mixbus running 40 tracks with 8 or 16 or more recording while the others are playing in an overdub session, and latency must be hard-realtime controlled (otherwise the performers doing the overdub are going to strangle the engineer....). Since the DSP plugins are running in real-time as well, you end up with quite a load, and it has to be hard realtime when you get to that many tracks. CentOS is used quite heavily in these circumstances, incidentally, because of the history of reliability and solid version stability; the hard part becomes getting newer versions of software running. The other application I thought about last night is NTP stratum 1 and 2 disciplined clocks where the 1pps output from a GPS receiver is used along with the timecode coming down the serial. I have yet to find any virtualization solution that keeps well enough time to be an NTP server at all, much less stratum 1 or 2.