PDA

View Full Version : Single x64 machine system performance report [with explanations]


Vatroslav
04-02-2008, 05:56 PM
Well, as I promised, the single x64 machine system performance report is here, finally. I have been waiting for this to happen for months, and now that it's finally done and ready for putting out in the public, I can't tell you how excited I am.

I know a lot of you (especially those of you who are planning on a x64 upgrade in the near future) were waiting for this anxiously and I apologize again for not delivering sooner. It's just that I have been so busy with different things lately I couldn't work faster than I did and the whole project (everything from the re-writing of an existing piece of mine to the entry, the editing, the tests and the preparation for posting) took longer than I thought it will.

But I finally did it, and here it is, to whom it may concern.

This thread is basically a follow-up on some of my posts (http://www.soundsonline-forums.com/showthread.php?t=12360&page=3) with my initial findings on the single x64 machine system on The 64bit/32bit debate (http://www.soundsonline-forums.com/showthread.php?t=12360) thread and some basic x64 facts with descriptions of my experiences setting the whole thing up, so if you haven't read it already, it would be a good thing if you would before immersing in all this.

Enjoy. :)

...

Vatroslav
04-02-2008, 05:57 PM
Well, as we all know, the sample-based proaudio community is at the brink of a major switch from 32bit memory addressing systems to complete 64bit architectures.

Whether it is a network of 64bit computers or one x64 server-class machine, the advantages of 64bit address space will enable us to do what we have been dreaming of ever since the early days of the jump from hardware samplers, synthesizers and 700MB cages to 2.7GB software of virtual instruments and streaming sound file libraries in x32 enviroments.

As it has been told many times before, the x64 superset has been around for quite some time now, but what held most of the x64 aspirants back was the absence of the 64bit driver support from most of the internal peripheral device vendors.

The server may have been supporting x64 instruction sets since day one, but the slow progress in 64bit driver releases and the instability of the early versions made most potential users sit out the harsh times.

On the software side of things, even though many have been saying that the true x64 heaven will come only with the release of native 64bit applications, MS' increadible WOW64 subsystem programming and excellent compiling of most of the existing 32bit music creation applications by their manufacturers has enabled us to break the sabotaging limits of the x32 mathemathics much sooner than some the early predictions have been claiming we will.

Having planned on a single x64 machine system for over four years now, I have been one of those people warily waiting for the harsh times to pass by.

Around two years ago, I talked to a fellow composer who decided to take the role of the x64 pioneer.

When I first met with him after he finally managed to get the system up and running and after spending some time with it, I needed less than a minute of his rampaging oration to come to a decision to leave the x64 upgrade on hold.

For whichever reason, he barely got the system to work at all, and when he finally did, it was so buggy and unstable he regreted the day he decided to go to music school.

From what I remember, he went back to his two x32 computer network and used the new one as a third slave, whatever he could get from it, that is.

Long story short - that was $3000 he never saw again.

I was discouraged to say the least and thought it's more likely I will turn into a x64 machine myself than buy one anytime soon.

And then, about eight months ago, I met a guy who claimed to work on a single x64 system with 8GB on an ABIT board and a Quad and has a hard time remembering what it feels like to have a wait time between the moment his mind thinks of an articulation and the moment that articulation sounds off.

The word "bounce" hasn't gotten out of his mouth for months either. Nor did "freeze", "unloading", "clicks", "pops", "crackles", "dropouts", "memory warnings", "crashes".

Effects chains weren't a problem anymore. Dozens of audio tracks loaded either.

Loadtimes simply did not exist. The template is loaded upon the system boot and remains the only wait time he will have until the workday is over.

Driver latency was lower than ever before. Input latency as well. He could play along whatever was going on in the piece and with no discernable audio lag, even with key instruments.

Polyphony was never even discussed. His pieces hardly ever go over 300 simultaneous voices, but at the time even that number at 256 which is his working latency made my jaw drop.

And all this with only three player instances.

I was sceptic, as you may assume.

So I invited myself over to his studio to hear this with my own ears.

I was proven everything I was told, and then some. He was streaming 250 average voices moderato at 100 bpm with ~20 mid-phrase short articulation switches at even intervals from four 7200s with four signal interceptions, eight waveforms and an active input and was still left with loads of memory space and some processing headroom.

First of all, less than year and a half since the world record in the number of swearings in a single sentence has been broken, here's a guy who hasn't had a single issue with a x64 setup, and on top of that he has everything I've been dreaming of for three years running as smooth as any system I've ever seen or worked on, including the highly optimized ones in the composing and mastering facilities I've been to.

I asked him for some advice and got a half-hour tutorial which set me off preparing for what I finally ventured in a month ago.

In the meantime, I met dozens of other guys (either sound engineers or composers) doing the same thing with no issues at all and it was clear that time has done its thing and that the new audio era is no longer just wishful thinking but a reality today.

The key word here is, of course, Windows XP x64 SP2. However, as this is a subject discussed more times than Vista programmers could probably ever dreamed it would be, I will leave it at that as there is more than enough said regarding this issue on this forum and others. :)

One of the most useful set of advices was given to me by one of the composers on 16GB, 8 drives and Dual DualCore 285 Opterons who even with everything he could ever imagine having in a mix loaded and ready to go still has more memory room and transfer bandwidth than he could ever use (counting effects too).

So three months ago I decided to put an end to the lurking from the dark and join the x64 guinea pig movement, wherever it may lead me.

...

Vatroslav
04-02-2008, 05:58 PM
As we all know, the key to a stable single machine system are the right hardware choices and and all of the intercompatibilities of all of the software/hardware components and specifications that have to be kept in mind when planning on a build from scratch.

The good news is, we are lucky enough to live in the age when all of the internal hardware components support x64 operations, so when you go into a store to buy anything that that goes in the box, the question "Is it 64bit?" in not necessary anymore.

However, as has been said times before, this does not go for external non-plug&play hardware peripherals. Some will work perfectly in a x64 system, some might not. Checking with every hardware manufacturer whether there is x64 driver support for the product of your desire is a must-do before making any purchasing decisions.

Regarding externals, what I personally was most concerned about before startin with all this was what's going to happen to my Yamaha S90 synthesizer.

Yamaha luckily had x64 drivers for their hardware, but they were very new and in the early versions, if I remember right, so I could only hope the synth will be able to communicate MIDI at x64 instruction sets.

When the system was finally put together and up and running, I was surprised to learn that S90 doesn't need any drivers to work with Win XP x64 at all.

Just as any other external peripheral I have hooked up to the box.

So after months of surfing, asking around, talking to audio and IT experts, listening to other audio professionals' experiences, browsing through dealer sites, specs examinations, test report considerations, technical and financial calculations, development speculations and predictions and all of the other research and planning I needed to do before I start my stride down the computer shop alley, I came to the conclusion that, for me, the following specs would be turn out to be the best deal:

...

Vatroslav
04-02-2008, 05:59 PM
Motherboard

ABIT IN9 32 MAX (http://www.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_NAME=IN9+32X-MAX+Wi-Fi&fMTYPE=LGA775)

When it first came out a year and a half ago, the nForce 680i SLI chipset was awarded the title of a dream coming true for every gamer and PC enthusiast that ever grabbed a joystick. I remember reading reports on some MOBO manufacturers being so impressed with the design they threw the offers as-is.

Having planned on an Intel chipset for a long time, I was sceptic to video-oriented platforms for audio production, but as some of the early benches I read suggested 680i is not that behind some of itscompetition when it comes to digital audio processing, I became less hesitant towards maybe investing in something I thought I never will.

What I was particularly impressed with at the time was the increadible FSB and memory controller as well as the peak interconnect bandwidth that were the top of what you could find a year ago (and was just until recently 790i came out).

However, I was still very hesitant towards going with something aimed at linking three graphic cards more than anything else and having planned on an RME audio interface and knowing it works best with Intel chipsets, the idea was still very far-fetched, but reading and hearing some of those guys on single 8 or 16GB beting heavily on gaming chipsets for their x64 audio powermachines, I gave them the benefit of the doubt and went along with their suggestions.

One of the main reasons why, apart from the fast clocking and the increadible connectivity on the southbridge, was a completely new northbridge and a revised memory controller with asynchronous run ability, significantly improving the overall server-side box performance in comparison to older nForce sets.

Also, the solid state capacitors make the whole thing cooler, more resistant and more stable.

Now, the problem is ABIT is not an advised MOBO brand from the DAW builders. They say it often acted very unstable in the past.

I can say I've been using ABIT's MOBOs for ten years and never had a single glitch happen.

However, at the time of my search for an ideal board, there was only one supporting all of the standards I needed in the system and at the same time providing enough RAM room for future upgrades and lots of headroom in the performance, and that was ABIT IN9 32 MAX.

With 4 DIMM slots supporting up to theoretical 32GB of DDR2 at 800MHz, it was exactly what I was looking for (the headroom is more important here than the off chance of going higher than 8GBs one day), and with all of the connectivity (3 USB and 2 FW headers internal, 4 USB and 2 eSATA headers external, which would mean you could attach up to four additional SATA drives to external ins via port multipliers and still have SATA I performance level and hook up to 7 USB drives without an additional external hub for small streams - add to that 2 FW channels and you can theoretically have a second drive array at approximately the same total bandwidth as the internal one), not wasting precious board space with unnecessary channels and on discount at the time, this was the one that went to the checkout.

However, it was only late in the game that I found out that the original BIOS of the board was in desperate need for a flash, not just for o'clockers or gamers but others user profiles as well as it often knew to make instability problems.

To all of you that don't know what flashing is or have naver done it - keep it that way. BIOS flashing should only be done when there's an obvious need for one and with the system on a UPS. If the power goes out during the flashing process, the only way to get the board working again is to plug the BIOS back in live which involves rubber gloves and lots of balls. ;)

Now, for those of you who have read those initial x64 postings of mine on the ohter thread, none of my problems described there had anything to do with bad BIOS. They were all down to a low-end RAM brand which was the sole cause of all of the hardware problems from day one.

Also, I have to mention that the IN9 32 MAX is likely one of the best board designs I've seen, which was another reason I went with this one. When setting up a system like this one, the design is about as important as it can get (not just for cooling reasons but simplicity and general space issues as well).

I can say I've never had an easier time assembling to a MOBO, even though it's not an EATX or WTX.

Also, it is very important to update to the latest chipset and other MOBO drivers and disable the built-in audio interface together with the OS sounds if not needed.

There are tons of other motherboard-related issues that can arise with audio systems, but that's a whole other topic. :)

Vatroslav
04-02-2008, 05:59 PM
CPU

Intel Core2Quad 2.4GHz, 1066MHz, 8MB, or Q6600, as the folks call it.

I guess after everything that's been said about it, this little fella got to the top of the wishlists of the majority of the audio industry and even though the topic has been covered many times, some facts are still worth mentioning.

First of all, four point of processing or four cores do not equate even math. You will not get a 100% improvement upgrading from a Dual Core system at 2.4 to a Quad at 2.4. There are multiple reasons for this, but we'll go through the two most important ones.

1) Current Quads on the market are not true QuadCore CPUs. Meaning they only have two cache registers, just as DualCore processors.

In other words, the intake of the data will be larger than it is on a DualCore system, but the output will still be subdued to two cache areas to read from. You will get better overall performance, but not by even math.

This is why many audio pre-optimized off-the-shelf systems have such an accent put on the overclocking of the front side bus as the enlargement of the final transmission proves to be more useful than additional processing point under a smaller number of temp storages.

2) Multithreading.

Even though current multiprocessor computer architectures allow so called SMP (symmetric multiprocessing or "multithreading"), all of the current versions of the Windows platform were primarely written as single-threaded applications and even though they support multithreadng operations, the system is still not optimized enough and does not handle multiple thread processing from a single app that well.

ASMP apps (asymmetric) will obviously see no benefit from SMP architectures and will distribute the processes in a different way (again, not necessarily meaning twice as slow).

But on something like Linux, you would see an overall improvement of SMP app's performances over ASMPs, regardless of the type of the instruction sets of the application.

This is why you will have better performance on multicore or multiprocessor systems on Windows using standalone modes of players than you will with plug-in modes (even with a highly optimized SMP DAW like Sonar).

We can hope future versions of Wins improve on the thread splits.

...

Vatroslav
04-02-2008, 06:00 PM
RAM

As I already mentioned, and as you could have read from the other thread, I had major issues using KingMax RAM and had to switch to another brand altogether (TakeMS 2GB 800MHz (http://www.takems.com/products.php?categ=mem&prod=DDR2-800)) to make the system work at all.

From what I can tell, not all brands make their kits to work at high memory capacities and it might also be that KingMax can't even work at more than 4GB.

The problems that I had with 4 2GB kits plugged in at the same time included the Win XP x64 installation not being able to start (got around this by unplugging three of the kits and leaving only the one in DIMM 1 slot plugged in - this might also have to do with dual channel mode operations - haven't thought of that until after I changed the RAM completely), random BSOD crashes, regular cold boot crashes and the system not being able to boot at all after the installation of the audio interface drivers and also some POST errors requiring different BIOS tweaking tricks.

So, the conclusion is - do NOT space on RAM brands.

Dual Channel RAM will require to be paired right, meaning you will need to plug in according to the colors of the DIMM slots.

In other words - install the x64 OS using only one RAM kit in DIMM 1 slot (you want to do this, there are problems with installing x64 OS with more than one mem module filled).

Then plug in the second kit in the slot with the same color. Then reboot to update.

Turn off the machine and do the same with the remaining two kits. One by one with boots between the two.

Aslo, do not experiment with different brands and different capacities working with one another at the same time. Use the same brand and the same size and preferably stay with an even number of kits inside (2, 4, 8, etc.).

Memory busing clocks do matter, but not that much, not in streaming audio world, unless you start getting very close to the physical memory limit and lots of data incoming/outgoing being processed simultaneously.

In the case of non-server class architecture, 8GB will be more working memory space than any single CPU currently out there will be able to handle, but that's something we'll get to later.

Also, if the MOBO has jittery DIMM clocks, it might not be a bad idea to lower the bus clocks on the kits as it will probably make everything more stable. I haven't had that issue with my ABIT, but I wouldn't hesitate to do it if I did.

Vatroslav
04-02-2008, 06:01 PM
HARD DRIVES

Well, I've said a lot about my drive structure in the System drive / sample drives configuration & management (http://www.soundsonline-forums.com/showthread.php?t=12606) thread already, but I will repeat some basics.

The whole idea behind a x64 system is to have one single machine replace a network and work at basically the same performance level.

However, even the best single x64 machine system will make absolutely no sense without a drive architecture that will be able to serve the enormous amount of incoming data requests from the same single board.

Hard drives are a crucial element of any single x64 system and without a multidrive structure any attempt at getting any serious work done will sooner or later turn out to be futile.

My current drive setup is Seagate Barracuda 7200.10 250GB 16MB (http://www.seagate.com/ww/v/index.jsp?locale=en-US&name=Barracuda_7200.10_SATA_250.2_GB&vgnextoid=a62099f4fa74c010VgnVCM100000dd04090aRCRD&vgnextchannel=a32a2f290c5fb010VgnVCM100000dd04090a RCRD&reqPage=Model) system drive and 5 Western Digital Caviar SE16 320GB 16MB (http://www.wdc.com/en/products/Products.asp?DriveID=299) dedicated sample drives.

I have had only god experiences with Barracudas in the past, I love the .10 series models and WD has proven to be the best option when it comes to heavy streaming and low heating.

Also, 320GB is the lowest I decided to go for low platter data occupation and minimum area cover time for the head. If I had the money, I'd go for GP 750GB for every sample drive.

All of them are 7200 rpm and the seek time on the sample ones are shorter than those of the system drive. Even though this may not be of much importance with sequential data retrieval which is what continuous drive streaming is, you want all of the values in time units to be as short as possible.

Also, Native Command Queing reportedly does not deliver any visible read improvement and it might lower the sequential read performance which is why it is advisable to stay away from it with sample drives (that's why Western Digital did not implement NCQ in their Caviar series).

However, the crucial element (as with any hardware device, especially internal) of a drive in a multidrive structure is, again, its cache register. I have chosen a drive with 16MB cache which is what most mid-end drives offer nowadays (there are 32MB drives, but they are usually very pricey because of the large storage capacity).

As much as SATA II standard is a must, with a 7200 drive you will have a hard time ever reaching its bandwidth, but headroom is, of course, always very welcome.

With small reads, something like a port multiplier might be a good idea, but both drives on the channel will, of course, be locked within the same channel bandwidth.

Th biggest security risk with the drives are their temperatures and the danger of overheating (which is why, beside the price, I didn't go with 10 000 rpm Raptors for samples) and I'm sorry to say I haven't done my homework here yet as I haven't invested in a heatsink and the three drives on the back of the casing are heating up pretty much and I still haven't had time to measure their temperature and see what's going on.

The ideal machine placement guaranteeing system health would mean a separate compartment (whether a room, a closet or a just small compartment) with temperature control via air conditioning and no casing at all, but that's a whole other unrelated topic.

The high temperatures are the most common cause to drive underperformance and failures and it is critical to make sure there is enough continuous cold air flow hitting all of the drives in the box.

As I mentioned on the drive thread, I always ghost my system drive and I would advise everyone to do the same.

...

Vatroslav
04-02-2008, 06:02 PM
VIDEO INTERFACE

Unless you will be using complex video formats to score to picture, graphics card is the least important component in an audio machine system to worry about.

I needed a Dual DVI card for a two-monitor setup, so I listened to DAW builders advising GeForce 7300 series and took nVidia GeForce 7300 Club 3D (http://www.ciao.co.uk/Club_3D_GeForce_7300_GS__6463691) as the cheapest Dual DVI graphics card I could find.

BTW - some motherboards are known to have jittery PCI-E clocks, so the idea to lower might apply here too.

The same goes for those with PCI-E soundcards, there were some cases I heard about, regardless of the lane count.

...

Vatroslav
04-02-2008, 06:03 PM
AUDIO INTERFACE

Like I said, I chose RME 9632 a long time ago and that's all I'm going to say about that company.

Something to keep in mind when it comes to PCI audio interface solutions is to have the soundcard not share the IRQ with the other PCI devices plugged-in if any. The PCI slot closest to the PCI-E slot does not have to share IRQ with the rest of PCI devices.

Generally, PCI IRQ configuration is very important with multiple PCI devices hooked up next to the soundcard as it might help avoiding unwanted system phenomenas. :)

BEWARE - in order to have multiple standalone K2 instances running audio on the same ASIO audio driver properly without major workaround efforts, you need an audio interface with multiple analog channels programming. That is why this particular audio interface (RME 9632) will never be able to execute even a completely other audio app riding the same ASIO driver with a K2 instance at the same time (like a sequencer - my Cubase simply can not output audio with K2 open at the same time on the same ASIO), let alone multiple standalone K2 instances.

Possible workarounds for this (apart from the one already described - using one K2 instance in standalone mode and the others as plug-ins i na LaaTido'd host) are to either try to connect the built-in audio card in your MOBO with your soundcard physically to try to override the reserved channels, to get a so-called expansion card for additional audio channels from the audio card manufacturer, or to get a second soundcard (or switch to the built-in soundcard altogether - if that one can do what the purchased one can't).

Usually (with a card with multiple analog channels and different ASIO management scheme), all you would need to do is just copy the .exe icon of K2 (not the shortcut on the desktop but the actual .exe in the installation directory in Program Files), in most cases that would be enough and you wouldn't need to do any additional tweaking (the already mentioned shortcut dumping, audio channels arranging, multi saving, etc.), but with audio interfaces with only two analog channels, whatever you do, you will not be able to override NI's channel reservation programming and therefore never be able to run multiple standalone K2 instances on the same driver.

This could, of course, be solved if freeware drivers such as ASIO4ALL were written to allow multiple applications to run on it or if they could run standalones next to other standalones on other ASIO drivers, but, unfortunately, the mentioned freeware does not have such capabilities in the current version.

Again, all this hassle is due to K2 audio channels programming which reserves certain audio channels by default, thus creating artefacts in sample audio playback such as crackles, pops and clicks, or no audio at all (especially if the audio channels arrangement is not done properly - that is, from the top downwards in the order of instances' opening - 1&2, then 3&4, 5&6, and so on).

(A big thank you to kejkz, mhuang, bybox, Manuel, Cleverson and Kravar for helping me figure this thing out. )

...

bobbyem
04-02-2008, 06:03 PM
Your hard core! Dual hard core!

Printing....

Vatroslav
04-02-2008, 06:04 PM
PSU

It's interesting how often people go off spending thousands of dollars on the most expensive system they can put together and then get a $50 power supply unit to power it up.

The PSU is the bloodstream of the entire system and having enough power going to every device connected from a stable unit needs to be the postulate of any x64 sytem built.

An underpowered system might not just cause various inexplicable issues like freezes or crashes but hurt the components' health just as well.

It is commonly known that the longevity of a chipset largely depends on the quality of the power it is fed with. This is another reason for having a good PSU and a UPS.

My choice was Everest Fortron 800W (http://www.pc-look.com/boutik/Prod_Fortron_Power-Supply-12-cm-Fan-Modular-Cables-Everest-800-800W__14916_en.html).

You always need to calculate the minimum power supply for your setup and go at least 20% beyond. You can use a power supply calculator like these two:

Snoop (http://web.aanet.com.au/SnooP/psucalc.php)
eXtreme (http://extreme.outervision.com/psucalculator.jsp)

(The latter is regularly updated. There are others, but most of them are outdated. There are computer shops ofering PSU calculations on their websites).

UPS is still on my buy list and you can find more info on uninterruptible power supply systems in this (http://www.soundsonline-forums.com/showthread.php?t=9662&highlight=UPS) thread.

...

Vatroslav
04-02-2008, 06:05 PM
CASING

After careful considerations, I decided to go with Kandalf9003WBS (http://www.thermaltake.com/product/Chassis/fulltower/kandalf/va9003bws.asp).

Beside the size of the casing (to have as much free room as possible), my main concern was, of course, the cooling of the enclosure. I also need six internal 3.5" bays and the whole thing generally as adjustable as possible, so I went with the five-fan full tower solution to have the airflow as configurable as it can be and with Thermaltake being the most popular brand around here and having heard nothing but good word about the fans that come with Kandalf, I decided to go with that one.

Now, from this point of view, I may have been better off with something like Antec's sound isolation management as it turned out I went from a loud machine to louder (because the door of the compartment in the desk has to be open for the air to come in and now the fans spin faster than they would normally and the surrouding sides accumulate even more noise), but I have already thought of how to deal with that.

I haven't yet tested turning off the side intake fan and that's something I will have to get around doing soon because I'm wondering if it's messing with the front -> back horizontal flow and making those drives in the back heat up more than they should. On the other hand, it sure does help cool the CPU and the chipset, especially since the latter is on passive (for zero noise - what an irony).

I took off Kandalf's front side doors (the question as to what purpose those serve I still have trouble answering) for both simplicity of life and the casing to fit inside the compartment at all.

Finally, I made sure all of the cabling inside is grouped together to create minimum airflow interference (another must-do for every box clogged with cables).

Well, that's it for the hardware.

And now to what we're all here for ... :)

...

Vatroslav
04-02-2008, 06:06 PM
As we all know, there are many different daw bench tests going around giving different performance reports, most of them very detailed and thorough, and, in all honesty, very representative of the overall power of test system in question.

However, very few of those will not fail to provide the key element - the music.

With every DAW bench, all of the paramaters are important and must not be overlooked or ommited to note, but inspite of all the numbers, descriptions and values presented, the reader can simply not get the true picture of the music in question until he actually hears it.

Some of the test I read somewhere went so deep as to actually describe every single exchange of every single instrument articulation within a phrase, but for some reason still did not provide the actual music for those interested to listen to themselves.

I believe even though all of those tests are very good and are always an interesting read, without the actual music, they prove very little. One can specify every single technical element involved in the test, but until he submits the actual musical profile along with the numbers, we can not know if the statistics are tricky or not.

Very rarely is this subject covered in DAW discussions and I think it deserves a couple of words.

The performance of every DAW (hardware and software in this case) is, obviously, directly dependent on the artistic side of things it is suppose to support.

However, in the world of digital electronics, music does not function within any sort of pattern or scheme or any kind of data predictability, which is what often might seem like from some generalizations going around in the DAW community. The reality is, a chamber composer might need more computing power than someone pushing an 80-piece assembly.

The reason, of course, is the overall musical profile within any unit of measure (be it a phrase, a piece, a score or an entire portfolio).

So, as weird as this may sound to those new to the DAW dimension of the reality, building a new machine from scratch means rational hardware choices within a given musical need, not just software ones.

This all might seem very obvious even to DAW beginners, but from the tests that are about to follow you may see why I'm writing this.

The whole artistic element of the modern music production is starting to fade away and with the x64 era here, I think it is necessary to bring it back to surfice as most of the hardware choices will heavily rely on what one will be doing on a single machine.

Beside the artistic side, there is also the workflow making its tribute to the x64 momentum as well. It might be a small one, but it should not be neglected in the calculations process.

The are different kinds of approaches to both entry and editing phase of the mockuping process and different methods require different quantities of resources at hand.

There are composers with big articulation templates and very frequent average patch switching rates. Then there are those with significantly smaller sound templates but significantly more messaging done to the outgoing signal and clearly more overall processing. And then there are those who always stick to what comes in the box and make increadible music nonetheless.

Big investments in music production are always smart. Thinking ahead can only make you happy in the long run. Sparing when you might need more down the road will only make you spend more money than you should have.

Many will tell you that in this day and age upgrading decisions should be based on the warranty period of the motherboard and the longevity of the standards at the center of the infrastructure at the time of the purchase as once any of those parts come to their end it might mean either used computer parts shop and a lot of good hope or a new system altogether.

But if you get constant positive feedback about your work with 2.5GB total data and no artefacts and your CPU never going over 80% at whatever working latency you have (probably 256 minimum in this case currently) and have no plans to make any sort of artistic changes in your music, then it' not just a question of whether you need a x64 system right now but whether you need a hardware upgrade at all.

...

Vatroslav
04-02-2008, 06:07 PM
So, that said, I made my upgrade decisions primarely based on continuous analysis of what I do orchestrationally. Going through both the scores I did in the past that were never MIDI'd and those that were sparingly. Trying to figure out the patches that would have been used, writing fictive templates for every one of those never-mockuped pieces,thinking about the average frequency of the articulation changes and the processing applied, and generally doing my best to calculate the general hit on the system and comparing it to those experienced with my old x32, Sempron 1.6, 1GB and a single 7200 drive for 24bit sound libraries.

Based on all that research, I came to the optimal hardware configuration and added a 30 % headroom all around.

There are, of course, two ways to do this. One is to make some blind judgements based on general approximations of the bandwidth and clocking (which is most usually do preparing an upgrade) and usually be left with either too much system headroom or none at all. The second one usually means ending up with insufficient resources and being left with an almost useless upgrade while the former means being lucky or well-informed by the advice givers.

The second one means careful study of all of the average rates and sizes involved in your composing process and making very neat calculations. It's all still approximation, but a lot more precise than those off the top of the head. It will mean going through the sizes and behaviors of different settings (counting every single sound file size in your previous projects, for instance), stream settings, voice memory, all of the clocks, busses, total and per channel bandwidth and all of the other significant segments of the components forming the future system, it will all be a lot of nitty-gritty work, but chances are you will end up with a more stable and economic system with fewer unpleasant discoveries that might arise with time.

Now, before we get to the very tests, let's go step by step.

A lot of folks are often talking about the initial speed of the system in the boot process. I've read self-praise of "my x64 booting in split seconds" and then "it takes more than my previous x32",so it was interesting for me to test my machine's the cold boot times as well.

Now, total boot time of the whole system (that is BIOS, OS and apps) can heavily depend on different settings and tweaks you apply (not just to the OS and apps, but BIOS as well), so I left everything at default and went to see what my stop watch says.

COLD BOOT times were:

ON: 0.00 - 12.65
BIOS WELCOME: 12.65 - 20.47
POST: 20.47 - 28.17
WBS:: 28.17 - 41.51
OS WELCOME: 41.51 - 43.07
DESKTOP: 43.07 -

FULL UP: 54.03


HOT BOOT times were:

ON: 0.00 - 10.54
BIOS WELCOME: 10.54 - 18.64
POST:18.64 - 26.50
WBS:26.50 - 39.43
OS WELCOME: 39.43 - 40.99
DESKTOP: 40.99 -

FULL UP: 48.99

So, system boots slightly faster hot, especially with the app load and MOBO's uGuru utility which gets up much faster.

Now, again, all this is with everything on default, with the exception of the start-up manager tweakings, OS services manual disabling and appearance load off.

Common practices for making boot times shorter without taking any chanes would in this case be emptying the Prefetch subfolder in the Windows system directory which would significantly shorter the WBS times (but you'd have to do it before every shut down or re-boot, there are some apps out there that do this for you, but they have to be up) and ending the BIOS WELCOME immediately after it shows up with the TAB key.

Of course, there are other things that influence the total boot time (the time that takes the BIOS to inspect all of the devices connected, for instance) which will obviously take more on a system with lots internal peripheral attachments used unlike those that use very little.

The shut down and turn off times were around 8 seconds cold and more hot depending on the number of apps recently exited.

Cubase SX2 (the DAW I use now on XP x64) load time without the plug-in scan step is around 4 seconds cold on blank startup and K 2.2.1 (the version I use) empty cold takes around 3.

And now, finally, to the tests. :)

...

Vatroslav
04-02-2008, 06:08 PM
Before I go any further, I need to put out the two basic project settings.

Those are 24bit depth and 44.1kHz samplerate.

All of these test would pop completely different results with a larger number of samples or with a lower depth, but since EWQLSO is downsampled from the original 88.2 SR to 44.1 and since higher wouldn't make much difference with samples and the audio section of ym system anyway, I always stay at the original corresponding settings. This subject is a large field to cover, so let's leave it at that. :)

Normally, an end-to-end DAW test would mean a new, fresh music piece written specifically for the purpose of testing, even to at the price of disregarding some of the laws of musical logic, all to make the stress-test the only objective of the task.

However, I decided not to take that path as, first of all, I would have a hard time writing like that, and second, I wanted to test real-world orchestration that makes musical sense and not something that will never happen in music.

So, I decided to use one of my more orchestrationally complex pieces from a score performed by a 120-piece assembly that I conducted around two years ago because of two main reasons: first, the Decca and the image used was strikingly similar to the tree and the mix of the recording session of EWQLSO from what I can hear, and second, the piece is filled with nightmare performance elements for every mockuper out there, like tuttis, runs, glisses, reptitions, etc., and all at a pretty fast pace (allegro moderato at 120 bpm throughout), and also loads of different articulations and performance methods needed to make the MIDI sound as close to the real thing as possible, many of those patches interchanging without any predictable concurrency and at high frequency, often mid-phrase and sometimes even mid-bar, and lots of different dynamics curves requiring manual tweaking and therefore additional messaging.

And the final reason was that it's a piece requiring a standard symphony arrangement so I was able to do what I wanted and use only one lib - EWQL's most popular product - Symphonic Orchestra Platinum Pro XP.

Since this is their forum, I will use EWQL's sounds only with every new x64 test I will conduct.

So, with a piece so latency, poliphony, memory and processing hungry, I thought it serves as a perfect tool to try to throw the entire system to its knees and see how soon it will happen.

Now, since the track is pretty complex musically, I scanned the score to make sure all of you who can read notes aren't left in doubt about what's going on at which moment, and even though it is your usual chickenscratch manuscript, I think you won't have a lot of problems getting the picture.

You can view the score in .pdf here (http://www.fileden.com/files/2008/3/29/1842143/Sonje%20Chase%20%5Bhandwritten%5D.pdf) (or download by right-click and choosing "Save As ...") or download it here (http://rapidshare.com/files/103302280/Sonje_Chase__handwritten_.pdf.html) or see page by page here:

Page 1 (http://img440.imageshack.us/my.php?image=50389715qj6.jpg)
Page 2 (http://img136.imageshack.us/my.php?image=61659514mn4.jpg)
Page 3 (http://img440.imageshack.us/my.php?image=35216740st7.jpg)
Page 4 (http://img153.imageshack.us/my.php?image=70394980ma2.jpg)
Page 5 (http://img178.imageshack.us/my.php?image=85199854ff2.jpg)
Page 6 (http://img444.imageshack.us/my.php?image=54067574zf6.jpg)
Page 7 (http://img444.imageshack.us/my.php?image=12317695kw7.jpg)
Page 8 (http://img442.imageshack.us/my.php?image=64134711yy7.jpg)
Page 9 (http://img153.imageshack.us/my.php?image=87433591my0.jpg)
Page 10 (http://img440.imageshack.us/my.php?image=10bx4.jpg)
Page 11 (http://img136.imageshack.us/my.php?image=11px2.jpg)
Page 12 (http://img440.imageshack.us/my.php?image=12mf6.jpg)
Page 13 (http://img153.imageshack.us/my.php?image=13tm3.jpg)
Page 14 (http://img178.imageshack.us/my.php?image=14yy8.jpg)

And, no, I'm not a Sibelius representative, these are just 6-years old leftovers from some of the empty templates I printed from a demo of Sibelius at the time and they were the only empty staves I could get my hands on on Sunday evening when I started re-writing. :)

Also, as you can see, the timeline written is off by one second if I'm not mistaking, I'm really sorry for that, but I wrote the original timing with the two-bar precount but bounced to audio from bar 2. I'm really sorry.

But then again, for those who can read notes it won't matter anyway. :)

Oh and, yeah, and if anyone wants to actually hear the piece, you can here (http://www.soundsonline-forums.com/showthread.php?p=118424#post118424).

...

Vatroslav
04-02-2008, 06:10 PM
Now, I want to emphasize this is a piece I wrote in only two days on a friend's piano two years ago (when I was 23) and that I could have made some changes now to make it better, but deliberately decided not to do it.

I know some of you will say it could have been more sample and voices hungry and in a way isn't really that representative of a system's power, but I still wanted to keep the musicality at the logic level and stayed away from any additional orchestration.

As you will hear, the biggest hit drivewise is definitely on the strings drive, particularly taking into account that both harps are sitting on the same drive drive with the rest of the strings (which should be avoided) and doing custom-made glisses (controller-performed) all the time since there are no minor glissandos recorded in SO.

The track is originally 7 minutes long, so I cut it by half since from I know experience that something like three and a half minutes at allegro are more than enough to experience artefacts at more than 25 events average and re-wrote those three and a half minutes to make transitions clear (don't worry, I hold the copyright to this one ;)).

As you can see from the score, there are some things I took out because whatever I did to them it just couldn't sound right, which is just another example of two worlds apart between MIDI and real orchestra.

Another important thing to stress is that I made patch choices correspond to the original mixing of the mics which was somewhat unusual with that score, and that is that we hardly ever mixed two different proximities for one instrument or a section. There were some exceptions, but only a few, and only when we need power that wasn't there with the pickup originally.

Now, to those new to handwritten scores, this is more or less how it's usually done, depending on the orchestrator, of course. I orchestrate all my scores without any help so you can say I'm the boss of me, but that's not how it is most of the time and the composer, apart from hearing orchestrator's work in his head reading the added notes, hears the added instrumentation for the first time either in the mockup or, before the VSTi nirvana, when the orchestra started playing it for the first time.

To those not new to orchestration, I know your eyes are rolling seeing some things in this, but cut me some slack, this isn't going to the copyist, and even if it did, you'd still see some unique codes in there as I always fully enjoy the transposition function in notation software and always write all of the winds and brass in C. To the old school this is like talking backwards, but since I'm from the digital era, I have no problems having everything tuned in C, even though everyone wa always making me transpose in my head. (Man, I hope they don't see this. :))

And yeah, there are a lot of dynamics missing, but I know most of them by heart, so I didn't want to waste time.

Oh and, yeah, I usually code perfect glissandi with an arrow, not a ^ or ˇ sign, but with an eight-bar page split there wasn't enough room for that.

And another thing - I know it would have been great if I specified which phrases / notes are assigned which patches, but it would be A LOT of work and, again, those of you who can read notes will probably be able to hear which patch kicks in where.

And another reason why it isn't important enough to devote hours of work to it is that most files in the same group sound samples (long, short, modfx etc.) of the same sound proximity have roughly the same sizes, so it would make more of an interesting read than be of much statistical value.

...

Vatroslav
04-02-2008, 06:10 PM
So the list of the used articulations is as follows:

PICCOLO

S PFL STAC
S PFL TRILL H
F PFL 8va UP

FLUTE

S 3FL SUS
F 3FL STAC x3
F 3FL EXP DIM

OBOE

S 3OB STAX RR x3
S 3OB EXP
S 3OB TRILL H

ENGRISH HORN

S EHN STAC RR x3

CLARINET

S 3CL LEGATO
S 3CL STAC RR x3

BASS CLARINET

S BCL MARCATO
S BCL STAC RR x3

BASSOON

S BSN STAC RR x3

CONTRABASSOON

S CTB STAC RR x3
S CTB LEGATO

FRENCH HORN

S 6FH FLUTTER CRES FST
S 6FH SHAKE
S 6FH SUS ADVENTURE
S 6FH REPETITIONS
S 6FH STAC LONG RR x3
S 6FH SUS FORTE PIANO
S 6FH STAC SHORT
S 6FH RIPS S
S 6FH 2sec CRES
S 6FH SUS 5 LAY
F 6FH STAC LONG RR x3

TRUMPET

S 4TP SFZ
S 4TP STAC RR x3
S 4TP CREC
S 4TP SUS

TROMBONE

S 4TB FORTE PIANO
S 4TB MARC S ACCENT
S 4TB STAC RR x3
S 4TB MARC
S 4TB 1sec CRES
S 4TB 2sec CRES
F 4TB 2sec CRES
S 4TB SUS

TUBA

S STU STACC RR x3

TIMPANI

S TIMP ROLL DXF MOD
S TIMP HITS LR

UNPITCHED PERCUSSION

S 20 CYMBAL
S 22 CYMBAL
S VARIOUS METALS
F TRIANGLE

HARP

F HARP PLUCK ROLL
F HARP PLUCK SHORT

VIOLIN

F 11V TREMOLO F
F 11V MARC
F 11V 5th SLIDE UP HARD
F 11V BUTTER LEG FORTE
F 11V MART UP DN
F 11V MED SHRT 3-WAY RR
F 11V QUICK UP DN MARC x6
F 11V SUS VIB SOFT
F 11V RUN SIMULATOR
F 11V STAC RR x2
F 11V TRILL H
F 18V MART UP DN MARC MED
F 18V SUS VIB

VIOLA

F VAS TRILL HT
F VAS MART UP DN MARC
F VAS MARC SHRT
F VAS SUS SOFT

CELLO

F VCS TREM
F VCS MARC RR
F VCS MART UP DN
F VCS PORT SHRT
F VCS SUS VIB
F VCS QUICK UP DN x6
F VCS TRILL H
F VCS CREC
F VCS MARC RR x6

BASS

F CBS QUICK UP DN x6
F CBS SUS VIB
F CBS SLAPS
F CBS PORT
F CBS CREC
F CBS MART UP DN

88 MIDI channels with 81 different patches loaded.

64 patches in K2 standalone, 16 patches in K2 plug-in instance 1 and 8 patches in K2 plug-in instance 2 (castanets for metronome + some patches loaded twice for CC reasons).

As you can see, with the exception of Timpani, I used no keyswitch or modfx patches on purpose, just to see how much memory regular patches can take up in all three instances (and the piece didn't really ask for that kind of programming).

I've explained why I use one K2 instance standalone and others plug-in in The 32bit/64bit debate.

However, you can disregard my workaround described there. In the meantime I've found out most guys on different soundcards use the icon copying/multi saving trick explained by Michael Huang just under my posts there, only most of them use pre-written script codes that execute the copying and arrange the audio channels and MIDI ports in all of the instances opened automatically.

It is important to notate though that the audio channels should be set according to the launch order, meaning that you have to start from the top (audio channels 1+2) and go downwards from there. If you don't, chances are you have no outgoing audio.

Still, if you want, you can use another set of instances as plug-ins, but it will make both the host application and the system less stable and with multiple plug-in instances it will be a huge hit on the host and you might expect unwanted happenings.

Also, if you run your DAW on the same ASIO driver, you will also need to configure its audio channels according to those used by K2 instance(s). You need to close the ones use by K2 instance(s) and open those that are not in order to get audio out of the DAW.

One of those happened to me and I was lucky enough to have had experience with similar problems in the past so I knew what to do, otherwise the only thing left for me to do would be to sit and laugh/cry.

What happened was at the very end of the workday I triedto load the fifth patch in the second plug-in instance and suddenly had a freeze of Cubase. There was no other way out but to crash Cubase and re-load.

The problem was, it couldn't re-load. It always froze at the end of the project load while it was loading the instrument at which it froze when first trying to load it.

I even tried opening Cubase directly from the project icon, but to no avail. It still froze at the same place every time.

I had the project back up, of course, but only up until that day.

So I remember a similar thing happen to me about a year ago with Nuendo version 3 that automatically copies the project under a new name as a freeze in most cases means corrupted data, which is what happened to me during the load.

However, SX2 doesn't have automatic post-freeze project copy process programmed into it, o I tried to to do it manually and - it open the project fine.

I was SAVED.

Well, went a bit of topic, but try to keep this in mind, not just those of you on Cubendo but any other DAW as well.

Note: From the looks of it, this will NOT work with K2. I'll get to that later, but I experience a freeze with that one too when I pushed it a bit and copying and renaming the multi did not do any good. I couldn't open it.

And now, finally, the tests. :)

...

Vatroslav
04-02-2008, 06:11 PM
As we all know, the performance of the system during the entry stage of the mockuping process depends mostly on the latency. Just to be clear, here I'm talking about input latency, that is playing the instruments along all of the already entered MIDI events on the MIDI controller.

This is how it went with this piece:

I started loading sample files in K2 standalone and deicded to use plug-in instances only when I'm out of MIDI channels in standalone.

The starting K2 settings were:

Channel Buffer Size: 132 kB
Reserved Channel Buffers: 1024 (default - I never change this)
DFD memory: 54 MB / 304 simultaneous voices max.
CPU Throttle: 95% (maximum performance - anything above kills voices until the performance is restored - 5% headroom for security and stability, even though more would be preferred)
Multiprocessor Support On (of course)

The orchestra is split between drives by sections:

Strings - drive 1
Woodwinds - drive 2
Brass - drive 3
Percussion - drive 4

I started from the bottom (the basses) and worked my way up at 128 samples / 3ms latency and default number of DFD voices K2 setting, everything set very low on purpose.

Even with all of the runs, glissandi and other performance elements at fast passages in the strings, I did not experience any artefacts either listening or inputing notes.

However, once I got to the harps, things weren't that dandy anymore. Having needed to perform my own glissandi and having them present almost continuously, I obviously had to raise the number of simultaneous channel voices by more than 400% (I set both harps to the same pluck roll patch deliberately - it's not how it's suppose to be done), but still had dropouts (dropped voices/notes) already with the first tutti at bar 8.

The pop-up window you will see in this case is:

http://i26.tinypic.com/2lbom.jpg

Like I already said, I deliberately left harp articulations on the same drive as the rest of the strings - obviously not a preferred organization with pieces with major custom glissandi activity (just a thought, this is not related to these types of dropouts).

So, obviously, I had to raise the number of DFD memory / voices. I raised them to from 54 MB / 304 simultaneous voices to 91.84 MB / 404 simultaneous voices and never needed to to make any changes again.

Once that was done, the dropouts stopped happening and the inputing continued fine, all the way until I got to the 3rd French Horn. With the 8th bar tutti I experienced my first CPU peak and a new set of voice dropouts and the appearance of the known even paced clicks until the voices are restored.

The explanation for this is that raising the amount of memory assigned to DFD / number of voices is the only solution to voice dropouts as there is simply not enough memory to provide room for all of the files needed at a certain musical moment.

However, more simultaneous voices means more data needed to be processed at the same time thus requiring higher CPU activity.

Unfortunately, as it is pretty hard to screenshot and play at the same time, I didn't take any shots of this (unlike the later tests that will follow), but as soon as it raised the voices to 404 there was simply no way to avoid CPU spikes however many times I loop-ran the first eight bars trying to put enough data in the cache registers (the moment I turned off both harp glissanding, the problem went away, but I did not want to work like that for pure tests reasons).

The reason for this is of course - low latency set.

With a different type of music cue, CPU spikes wouldn't happen.

However, having such high and fast rates of data exchange for the audio interface to process with such a small amount of samples in the buffer will result is CPU overkill and major voices dropouts that will need some time to recover.

The solution to this is, naturally, to raise the number of buffer samples. However, ever raising will result in higher time values meaning more lag between the time of the key being pressed on the MIDI controller and the time the resulting audio get processed and comes through the output.

Most mockupers can take 256 samples / 6 ms latency as the lag is not audible to them.

However, there are some who make much compromise with 256 and they can discern the audio being a tad late.

Those that can't work at 256 will have a hard time on a single x64 machine system. They will either need increadible CPU horsepower or try to adjust to longer round trip times than preferred.

Also, driver latency audibility level often differes depending on the instrument played. With key or percussion instruments chances are it will be more obvious to the performer. With emotion strings patches at slow passages, obviously, it probably won't matter that much.

Another reason is that the orchestra hardly ever performs pefectly in beat with the conductor's gestures, apart from the beat nazis who insist on everthing being right on the wave (not including yours truly :)), so those performers with orchestra experience will not have a problem laging behind the click track a bit.

On the other hand, something like 512 / and especially 1024 / will render you able to push practically anything you can ever imagine on a single machine. If you don't have a problem with significant audio lags, you won't have too much trouble using a single x64 machine for your system However, I'm pretty sure there are very few of you that can say that for themselves. :)

BTW, I need to stress that K2 standalone was running on ASIO4ALL. This is the first and the last time I used standalone and plug-in simultaneously, in my future tests I will only use multiple standalone instance on the same Hammerfall ASIO, so it will be interesting to see if I'll have any actual performance improvement on stress.

So to get back to the chronology of the events, once I raised the ASIO driver latency to 256, all was back to normal and there were again no more dropouts whatever was happening in the music.

Also, I stayed at 132kB channel buffer from start to end and never experienced a single click or pop. So, clearly a 132 exceeds the 7200 throughput under SATA II bandwidth even with around 300 voices per drive, just like I suspected it will (it might do even more, haven't gotten to those tests with this piece).

This is great news for everyone not even considering 10 000 rpm.

I wrapped the entry stage with the same settings and was never bothered with 6ms lag, but, again, that's just me.

The CPU never had more than enough headroom whatever I did and my only freeze was the one mentioned above, when the entry was practically done (just another proof of the advantages of standalone over plug-in).

And so, the track in done and we finally at the most interesting part of the test - hardware benching at different settings.

Vatroslav
04-02-2008, 06:12 PM
So, the piece works at:

256 samples / 6ms processing ASIO driver latency
132 kB channel buffer size with 132 MB total DFD memory required
91.84 MB DFD memory / 404 maximum simultaneous voices

So now let's see what happens at lower settings when the piece is completely done and no active inputing going on.

Now, a couple of important things need to be mentioned:

First of all, this whole piece was done without any sort of MIDI singal interception, that is effects on inserts, sends or any sort of grouping whatsoever.

Yes, I know, it would make a lot more sense to have done the opposite, but I deliberately decided to stay with minimum messaging for this test to see what I could do without any third-party processing and additional load on the system.

Also, as mentioned, I tried to stay with EWQL products only.

Second, the CCs were applied exactly as much as I would if this was not a test. I could have gone a long way slapping different CCs to every MIDI channel, but, again, I refused to do whatever clashed with musical sense in any way.

So, apart from the 7 double patches equaling in 14 different channels with active CC-ing, there were another 5 patches receiving control codes totaling in 19 MIDI channels with CC activity.

Now, obviously, this would be a lot of work notating every point in the piece where the CCs are active, but from the looks of it, I'd say there's about eight to ten average CC activities per MIDI channel totaling in around 160 CC events in the piece.

Third, as you will be able to see from the screenshot below, many MIDI tracks in the project have had sequencer automation applied to them along with the CCs. They weren't that frequent and it also wasn't done for sole test reason but musical results.

There was, of course, no loaded or running audio, all of the release trails were on and on default settings, no K2 parameters were automated, and the only other running application druing the test beside SX2 and K2 was MS Paint for printscreen pasting.

Now, what I need to stress is that the K2 standalone instance is the one I will be talking about here as the other two instances in plug-in mode had a neglectable hit on the system and didn't influenced the overall performance almost within the margin of graphic presentation error.

The first plug-in instance took 118 MB of sample memory, the second one 93 MB, both averaged at ~20 simultaneous note events and maxed at 40 only at one point in the piece, with only ~70kB average voice memory used (maxing at ~117kB at bar 64), and both hardly ever occupied more than 5% of CPU cycles together active and 0% idle (assuming we take K2 readings for granted).

Also, the way I loaded the files accidently made those two take mostly the files that are not at constant activity, and when they active, it's for a short period of time (usually half a bar).

Therefore, in the tests that are about to follow I will only concentrate on the standalone instance that holds the majority of the sound files and the ones used most in the track.

To those interested, this is usually my project view when the track is done:

http://img211.imageshack.us/img211/9828/dawprojectedittr0.jpg :)

...

Vatroslav
04-02-2008, 06:13 PM
So, let's go over the original working K2 standalone config again and add some other important data that hasn't been mentioned yet:

132 kB Channel Buffer Size (the amount of data per MIDI channel for streaming)
132 MB Total DFD Memory Required (self-explanatory, I guess)
1024 Reserved Channel Buffers (the rule of thumb is twice the size of the DFD memory plus some headroom, so it's best not to tamper with the default value, but you can do it if you're up to those kinds of tests)
91.84 MB DFD Memory / 404 Voices (the maximum size of the DFD memory assigned and the maximum poliphony / number of simultaneous sounds that can be loaded and processed)
~25-30 average and 60 max. (bar 93) simultaneous Note Events Used (the number of simultaneous MIDI events / notes active - differs from the numbers of voices)
~350 kB Voice Memory Used and 720 kB max. (how much memory is actually used my voices)
CPU at ~12% Idle (the amount of occupation of the processing cycles by all of the data loaded in K2 while there is no play activity)
ONLY 620 MB Total Sample Memory (with all 64 patches loaded - of course, this is with DFD)

Idle state at 256 sample / 6ms latency:

http://i30.tinypic.com/4ptnc8.jpg

Now, while we're at it, here are K 2.2.1's cold (clear cache) and hot (non-cleared cache, after exiting K2 standalone instance) load times with that 64-patch standalone multi with all of the settings above:

COLD

1.15.81

HOT

13.40

Now, before we go any further, it is important to notice a couple of things:

As my entire template even with almost 90 patches does not go higher than 650MB of total sample memory at DFD, this will be more of a multidrive, soundcard and CPU set of tests than of the performance of the system at 64bit addressing. We'll come to some of those basic tests later.

Right now we'll focus on seeing how much hit the processor can take at different sample buffer settings and what 7200 drives can do at different DFD channel buffers.

It's very important to say though that there are many kinds of tests that can be performed once the project is done and ready for benching. Every hardware or software component could be submitted to stress whether it is running in a x32 or a x64 enviroment, but we'll only focus on the performances with default data sources (data always coming from the same drive locations).

I am deliberately not going into hard drive tets here as a single x64 machine system is senseless without a multidrive structure, that is multiple dedicated drives to hold sample lib splits. On the other hand, it would be interesting to see, for instance, how much I could get from fewer drives with the music piece, but that is a very large set of tests that I may conduct some other time. :)

What is important to accent again regarding the drive side of things is that one must make sure the desired drive head bandwidth to serve the incoming data requests does not tend to exceed the capacity of the transfer bandwidth (howevermany rounds the spindle is doing), otherwise you will again be nowhere with your drive setup as the reads will not be in crepency with the bus. In the case of streaming audio drives, bandwidth bottlenecks are always welcome. :)

And so, now, off to the tests.

First we'll look at what is happening at original latency settings and go through all of the happenings in the three and a half minutes of different music events taking part in the piece.

Now, instead of doing runs at different settings and making some general eye judgements, I conducted the tests passage by passage according to the musical figures in the track.

If you look at the score, you will see those figures being marked by a double vertical line at the top and the bottom of the sheet and timestamped. This is usually called "hitpoints".

Now, there are more hitpoints in the score than there are passages that will be separately tested here, but I did iclude most of them. I made the decision to do the tests this way for two reasons:

1. I want detailed tests showing system state at different data rates at similar intervals for optimum representation - around 15 second time sample average.

2. In the case of this particular piece, a new figure in most cases means a new orchestration moment altogether and thus a whole new set of information events taking place in the processing.

However, the results of the CPU performance readouts may not be representative at all if not done in a proper way. That is, running the piece from the start every time I need to move to the next figure to screenshot and take notes.

So, in other words, even though I only need to test figure 14, I have to go back to bar 1 and wait until the cursor get to bar 94. This goes back to the cache registers story.

The same principle applies to all the other tests conducted.

The sample files RAM occupation level affects the performance only at idle state, not active, so that's not one of the relevant factors.

So, here we go ... Let's see the stats of the system performance at:

...

Vatroslav
04-02-2008, 06:14 PM
256 samples / 6ms latency

(The timeline is the one you can see in the media player, not the one written in the score)

Figure 1: Bar 3 (0:02-0:05)

CPU average: ~20%
CPU peak: 35%

http://img218.imageshack.us/img218/2494/shriekedittb1.jpg

Figure 2: Bars 4 - 9 (0:05 - 0:18)

CPU average: ~30%
CPU peak: 45%

http://img167.imageshack.us/img167/7514/4do10edityj9.jpg

Figure 3: Bars 9 - 15 (0:18 - 0:29)

CPU average: ~20%
CPU peak: 40%

http://img262.imageshack.us/img262/492/9do15top40editpe0.jpg

Figure 4: Bars 15 - 21 (0:18 - 0:41)

CPU average: ~30%
CPU peak: 40%

http://img524.imageshack.us/img524/9416/15do21top40editof4.jpg

Figure 5: Bars 21 - 27 (0:41 - 0:52)

CPU average: ~35%
CPU peak: 40%

http://img241.imageshack.us/img241/5053/21do27top40editko3.jpg

Figure 6: Bars 17 - 37 (0:52 - 1:08)

CPU average: ~35%
CPU peak: 50%

http://img528.imageshack.us/img528/3199/27do37top50edityq8.jpg

Figure 7: Bars 37 - 44 (1:08 - 1:22)

CPU average: ~15%
CPU peak: 20%

http://img136.imageshack.us/img136/7362/37do44top20editki0.jpg

Figure 8: Bars 44 - 54 (1:22 - 1:40)

CPU average: ~35%
CPU peak: 50%

http://img527.imageshack.us/img527/841/44do54top50editkj6.jpg

Figure 9: Bars 54 - 62 (1:40 - 1:57)

CPU average: ~30%
CPU peak: 50% (at the very end)

http://img241.imageshack.us/img241/6682/54do62top50attheendeditjg9.jpg

Figure 10: Bars 62 - 67 (1:57 - 2:07)

CPU average: ~40%
CPU peak: 45%

http://img396.imageshack.us/img396/585/62do67top45editqy7.jpg

Figure 11: Bars 67 - 73 (2:07 - 2:19)

CPU average: ~40%
CPU peak: 50%

http://img524.imageshack.us/img524/6530/67do73top50edittp5.jpg

Figure 12: Bars 73 - 80 (2:19 - 2:34)

CPU average: ~20%
CPU peak: 25%

http://img168.imageshack.us/img168/6884/73do80top25editba1.jpg

Figure 13: Bars 80 - 94 (2:34 - 3:00)

CPU average: ~40%
CPU peak: 50%

http://img219.imageshack.us/img219/9757/80do94top50editlx1.jpg

Figure 14: Bars 94 - 102 (3:00 - 3:16)

CPU average: ~15%
CPU peak: 35%

http://img396.imageshack.us/img396/82/94do102top35editve6.jpg

Figure 15: Bars 102 - 106 (3:16 - 3:24)

CPU average: ~25%
CPU peak: 30%

http://img261.imageshack.us/img261/6342/102do105top30editkc9.jpg

Figure 16: Bars 106 and 107 (3:24 - 3:28)

CPU average: ~25%
CPU peak: 30%

http://img241.imageshack.us/img241/2663/106do107top30editmi8.jpg

So, as you can see, at 256 samples / 6ms driver latency, the CPU doesn't peak higher 50% even at the most massive orchestral moments at K2 standalone instance. Add to that the other two plug-in instances averaging at 5% CPU performance and peaking at 10% only at two points in the piece and we can freely say that 256 is the working setup for 400 simultaneous DFD voices for Q6600 with minimum 40% headroom for additional data.

Now to what many of you are anxiously waiting to see ...

Let's see what happens when we try to go as low as we can.

First, a very common latency setting in many DAWs:

...

Vatroslav
04-02-2008, 06:15 PM
128 samples / 3ms latency

Mathematically, this would mean twice as power hungry template in comparison to the previous settings, but as you will see, it's obviously not like that.

Having already tried 128 / 6ms at the very beginning of the entry stage (I didn't want to make any confusion, so I omitted to mention this earlier), I knew there are going to be problems and that there's very little chance this can be processed at such a low setting with a single Quad, but I went and tried nevertheless.

To hear exactly what's happening, I bounced every run (I know it's additional processing, but I wanted for you to hear it), so you can hear all of the overloads for yourself.

(Because these are only presentation examples, I lowered the bitrate all the way down to 128 kb/s so those of you interested in hearing this waste minimum bandwidth and that it loads as fast as possible - something like 64 would be too low ... Also, I'm on free hotlinking with low space, bandwidth and transfer rates ;)).

http://i31.tinypic.com/1427wk1.jpg

Also, knowing there will be problems, I raised the CPU throttle to 100%.

1st run:

No go. CPU at 95% already at bar 15, dropouts.

Total overload at bar 22, full dropout.

Restore only at bar 32.

Dropouts continuing throughout the track.

http://www.fileden.com/files/2008/3/29/1842143/1st%20run_00.mp3

2nd run:

Major improvement, but still not good enough. Dropout at bar 94.

http://www.fileden.com/files/2008/3/29/1842143/2nd%20run_01.mp3

3rd run:

Major dropouts again at bar 28. Restore at 33.

Another major dropout at bar 93.

http://www.fileden.com/files/2008/3/29/1842143/3rd%20run_00.mp3

4th run:

Total dropout again at bar 15. Restore at bar 18.

Another major dropout just a couple of bars later.

Continuing dropouts throughout the track.

Worse one yet.

Obviously no cache can make up for the lack of processing power, but let's not give up yet.

http://www.fileden.com/files/2008/3/29/1842143/4th%20run_00.mp3

5th run:

Dropouts again at bar 15. Doomed bar.

And at 28 again.

And continuing throughout. Total drops.

It's getting worse and worse.

http://www.fileden.com/files/2008/3/29/1842143/5th%20run_00.mp3

6th run:

Guess what? Bar 15 again.

And continuing throughout.

http://www.fileden.com/files/2008/3/29/1842143/6th%20run_02.mp3

Obvisouly, there's no point in continuing with this. 128 is simply too low for 400 voices (clearly even less) and Q6600 and no matter what I do I can't run three and a half minutes without at least one overload.

So let's try lowering the voices to my inital input setting of 304 voices. We will definitely have dropouts and other artefacts, but let's see if we get CPU overloads as well.

7th run 304 voices:

Yup, CPU overload at bar 28. Some clicks here and there that preceeded the overload as well.

Another overload at bar 62 and 67.

And another one after that.

So, not even one fourth lower poliphony can make up for the lack of computing resources.

http://www.fileden.com/files/2008/3/29/1842143/7th%20run%20304%20voices_01.mp3

At this point, there was really no more purpose in continuing benching at 128. It is clearly impossible to run even 300 simultaneous voices at 128 on a single Q6600.

(There's wasn't really any point in providing the average CPU loads considering constant overloads, that's why I didn't go the distance of screenshoting the stats at every figure.)

So, the conclusion would be that 128 samples / 6ms latency for 400 and even 300 voices would be a working setup for inputing MIDI events to a finished project phrase by phrase (finished project means no more inputing, of course, but still, for the sake of argument), but for continuous uninterrupted entry to a full project start to finish it is an overkill for Q6600.

But since such a thing will never happen, my guess is at 400 voices you would be able to input for a short period of time more often than not without artefacts, especially after a couple of runs of the phrase. This is good news to those that feel uncomfortable inputing at higher latency values.

Of course, it is impossible to predict the behavior of the system inputwise since when talking about inputing it depends primarely on what is being played, but also on the events already entered, patch choices and the appearance of MIDI events in general, but if you perform parts one small phrase or even motif one by one, it is highly unlikely you will encounter troubles that often. But, again, it's impossible to know. There are so many factors it can depend on as little as where you killed the RTs.

Either way, for smooth runs at such high performance processing you would clearly need at least a Dual Quad architecture to be sure to have the same headroom you get with a single Quad at 256.

So, now let's try raising the latency by 1ms increments and see when we get to a working ASIO configuration for K2 at 400 DFD voices and 404 DFD voices again.

Vatroslav
04-02-2008, 06:17 PM
176 samples / 4ms latency

http://i26.tinypic.com/2qn0eb4.jpg

1st run:

Some clicks early on in the piece. Dropouts again at bar 15.

But that's about it. So far so good.

http://www.fileden.com/files/2008/3/29/1842143/176%201st%20run%20404%20voices_00.mp3

2nd run:

Short dropout at bar 32. Instant restore.

Nothing more.

http://www.fileden.com/files/2008/3/29/1842143/176%202nd%20run%20404_00.mp3

3rd run:

BINGO! No dropouts!

Let's see if I was just lucky.

http://www.fileden.com/files/2008/3/29/1842143/176%203rd%20run%20404_00.mp3

4th run:

No, I wasn't. Smooth run start to finish. Yay! :)

http://www.fileden.com/files/2008/3/29/1842143/176%204th%20run%20404_00.mp3

So, obviously, caches have adapted to the track properties well enough to run the whole piece without a single dropout from now on.

Judging by that, it is very likely that at 176 / 6ms it would be possible to input events to a finished 404 voices track for a long time without artefacts. To a builing project, it would be possible to do it start to finish for quite some time on Q6600.

So, now let's look at the CPU hits figure by figure from the 4th run onward.

Idle:

http://img260.imageshack.us/img260/880/176idleediteg6.jpg

Figure 1: Bars 3 - 9 (0:02-0:18)

CPU average: ~25%
CPU peak: 50%

http://img253.imageshack.us/img253/7158/3do9top50editlu2.jpg

Figure 3: Bars 9 - 15 (0:18 - 0:29)

CPU average: ~25%
CPU peak: 5%

http://img266.imageshack.us/img266/3909/9do15top55editie6.jpg

Figure 4: Bars 15 - 21 (0:18 - 0:41)

CPU average: ~40%
CPU peak: 50%

http://img364.imageshack.us/img364/2115/15do21top50editti9.jpg

Figure 5: Bars 21 - 27 (0:41 - 0:52)

CPU average: ~45%
CPU peak: 65%

http://img508.imageshack.us/img508/9463/21do27top60editqe3.jpg

Figure 6: Bars 27 - 37 (0:52 - 1:08)

CPU average: ~35%
CPU peak: 55%

http://img530.imageshack.us/img530/8430/27do37top55editqz3.jpg

Figure 7: Bars 37 - 44 (1:08 - 1:22)

CPU average: ~25%
CPU peak: 30%

http://img440.imageshack.us/img440/5011/37do44top30editzr0.jpg

Figure 8: Bars 44 - 54 (1:22 - 1:40)

CPU average: ~35%
CPU peak: 60%

http://img522.imageshack.us/img522/4998/44do54top60editth7.jpg

Figure 9: Bars 54 - 62 (1:40 - 1:57)

CPU average: ~35%
CPU peak: 60% (at the very end)

http://img135.imageshack.us/img135/6695/54do62top60editjb8.jpg

Figure 10: Bars 62 - 67 (1:57 - 2:07)

CPU average: ~45%
CPU peak: 60%

http://img212.imageshack.us/img212/6900/62do67top60editel8.jpg

Figure 11: Bars 67 - 73 (2:07 - 2:19)

CPU average: ~50%
CPU peak: 65%

http://img508.imageshack.us/img508/2066/67do73top65editeo6.jpg

Figure 12: Bars 73 - 80 (2:19 - 2:34)

CPU average: ~20%
CPU peak: 35%

http://img80.imageshack.us/img80/310/73do80top35editae4.jpg

Figure 13: Bars 80 - 94 (2:34 - 3:00)

CPU average: ~50%
CPU peak: 65%

http://img440.imageshack.us/img440/1377/80do94top65editwj2.jpg

Figure 14: Bars 94 - 102 (3:00 - 3:16)

CPU average: ~25%
CPU peak: 35%

http://img509.imageshack.us/img509/9300/94do102top30editzw7.jpg

Figure 15: Bars 102 - 106 (3:16 - 3:24)

CPU average: ~25%
CPU peak: 30%

http://img99.imageshack.us/img99/807/102do105top30editnd9.jpg


Figure 16: Bars 106 and 107 (3:24 - 3:28)

CPU average: ~25%
CPU peak: 30%

http://img153.imageshack.us/img153/3048/106do107top30editwm7.jpg

Now, you may have noticed that some figures do roughly the same if not smaller CPU cylcles occupation than 80 buffer samples more (256) and this is very likely do to the different ways data is stored in the caches with different runs.

What's important is that it's usually within the redout margin of error, and, as you can see, it usually happens with "quieter" passages when there are fewer samples streams than during the tuttis or fast passages.

So, basically, that's it. That's the latency test. 4ms is the lowest you can go with an orchestration such as the one you can hear in this piece and on a setup like mine or within the level of specs.

Now let's test the drives and see what they can do.

...

Vatroslav
04-02-2008, 06:18 PM
60 kB Channel Buffer Size

Obviously, none of the drives have any problems streaming with 132 kB header (the amount of data loaded in the RAM opposed to that streaming from the hard drive realtime).

Now, as you can hear, the drive with the most pressure being put on it in this piece is the strings drive (especially considering the constant custom-built harp glissandi - it would make sense to try with them turned off too, but I decided not to do it - everything must be tested as it would be bounced to mixdown in a real session). That is why this will be more of a strings drive test than any other, but since all of the drives are exactly the same specwise, the results will be representative of the whole drive system.

So, let's see what happens when we cut the buffer size for each channel by a little more than half.

Of course, with loads of RAM and processing power, increasing channel buffer size isn't going to be that much of a hit on the system, but since we're testing everything, let's try to see what happens with very low off-disk buffering.

256 samples / 6ms and 404 DFD voices remain, of course.

REBOOT from last test

http://i29.tinypic.com/abs6tl.jpg

1st run:

Some cracks early on and a small dropout at bar 15 again.

Another little click at bar 93, but that's about it.

http://www.fileden.com/files/2008/3/29/1842143/60%20kB%201st%20run_00.mp3

Let's see if the second one will remedy all that.

2nd run:

BINGO! No artefacts!

Let's run it again to make sure.

http://www.fileden.com/files/2008/3/29/1842143/60%20kB%202nd%20run_00.mp3

3rd run:

Yep, no cliks, pops or dropouts anymore.

http://www.fileden.com/files/2008/3/29/1842143/60%20kB%203rd%20run_00.mp3

Great.

Now let's see what happen when we go all the way.

REBOOT (required for representative test results - re-loading K2 will not do, the caches need to clear completely - reboot will do, cold boot is not necessary for this)

Vatroslav
04-02-2008, 06:19 PM
24 kb Channel Buffer Size (minimum DFD channel buffer size allowed by K2)

http://img354.imageshack.us/img354/5075/24kbedituj1.jpg

1st run:

Clicks again early in the piece and dropouts at - you've guessed it - bar 15. :)

Some other clicks for the rest of the piece with and a hung horn note at the end for desert. :)

http://www.fileden.com/files/2008/3/29/1842143/24%20kB%201st%20run_00.mp3

Let's see what the cache does now:

2nd run:

Fewer clicks and a smaller dropout at bar 15, but problems still present.

http://www.fileden.com/files/2008/3/29/1842143/24%20kB%202nd%20run_00.mp3

3rd run:

Dropout again at bar 15.

http://www.fileden.com/files/2008/3/29/1842143/24%20kB%203rd%20run_00.mp3

So, since cache data exchanges in relation to header are much faster than the cache in the voices/CPU test, I decided to leave it at that as it is obvious I will never be able to see a completely clean run with 24 kB.

So, to conclude, 60 kB works here with 7200 with 16 MB cache while 24 kB is simply too low for the quantity of data streamed from my strings 7200 drive. Maybe things would be better with a bigger cache and a bigger platter, but I somehow doubt it. Rounds are likely the only ones that can fix this.

I'm specifically saying "here" as when it comes to channel buffers it is making any kind of general judgements is very thoughtless.

Total DFD memory tests and channel buffer tests are two different things. While you can come to some general conclusions with the number of simultaneous voices vs. CPU, with the size of the header files in the RAM it is virtually impossible to make any kind of predictions as to how it might perform in different musical cases.

The reason for this is that max voices and channel buffer are two different "steps", so to speak, in the data transfer sequence and disk sample retrieval can not rely on any forseeable processing mathematics.

In other words, 400 voices is always 400 voices while 60 kB streaming bandwidth might mean 59 kB or only 22, depending on as little as which sample you stream with what concurrency and the varying invasion of the incoming data read (buffers will obviously handle keyswitch patched differently than other groups).

There are also lots of other factors and variables that can influence drive performance that some of us talked about in some other threads here, from the level of total data platter occupation, the size of the platter, whether the magnetic write is vertical or not (like it is with high capacity drives), all the way to redundancy schemes and fragmentation of the disc in the drive.

Needless to say by now, I guess, the size of the drive cache plays a crucial role in drive stream performance. Along with the capacity of the platter and the spin speed, cache is the most important spacification of a sample drive. This is some of us suggest drives as big as possible as not only will the head on the spindle need minimum area cover time for requested data access, but will in most cases also come with cache sizes twice as big. To the majority of sample streaming conditions, cache might prove to be more important than the number of rounds per time unit (not to say that 10 000 rpm with 32 MB cache wouldn't be my drive of choice if I had the cooling and the green :)).

And finally, to sum up all of theese tests in an overview, I screenshot all of the bounces stacked together in the project view under the original 132 kB/404 voices/256 samples working configuration so you can see them as in a sort of comparison chart.

If you look closely and compare the runs with the original working mixdown on the top, you can see all of the places where the dropouts occur.

http://img361.imageshack.us/img361/6564/comparisonchartfixededipl6.th.jpg (http://img361.imageshack.us/my.php?image=comparisonchartfixededipl6.jpg)

So, that's the K2 settings tests.

Now we're finally off to the x64 RAM experiment.

...

Vatroslav
04-02-2008, 06:20 PM
As I've said already in the other thread, Native Instruments programming reserves some audio channels in every instance of their software players which requires some additional tweaking for multiple standalone instances to work on the same ASIO driver. This is irelevant for test that's about to follow, but thought I should repeat it one more time to explain why I haven't used multiple standalone instances in prior tests.

Now, as we could have seen, my entire piece was performed with less than 800 MB of total sample size with DFD. For some, this will undoubtedly be a pretty big surprise, especially considering the total number of MIDI channels included, but it really shouldn't be.

The main reason for this is that I used the patch-by-patch loading method, the good old "try before you buy", thus staying away from the massive loads that is keyswitch patching.

However, for some (usually those that have x64 system ambitions), this is exactly what they want to avoid. It is not just about getting rid of diffrenet RAM management steps bouncing, freezing or (un)loading, but about loading your entire template once and never again.

Now, x64 is not just about the amount of articulations loaded at any one time. Much of the total physical memory size is used for different kinds of signal processing as well and patching, but in this test we'll concentrate on the simple number of files and total memory ocupation from the loaded samples on XP x64 with 8GB of RAM.

With that piece I mockuped (not counting the 1GB reserved for the OS), with the entire sample template loaded, I was left with more than 7 GB empty memory space, which obviously puts a big questionmark over the sense of the whole x64 adressing.

But, again, the metjod of loading samples I emplored here is not what I want to do in the future (which is one of the reasons why I went x64 in the first place).

So, now I'm going to try pushing the RAM as far as I'll be able to and see were I get.

Now, what those of you that don't care too much about K2's numbers may be surprised to see is that even with something like four K2 instances you will still have a hard time getting to even 4GB of total sample memory if you only use single articulation patches - that is, no keyswitch instruments. K2 is limited to 64 programs whatever you do (sharing the channels between patches, for instance), so once you have 64 patches loaded, what you see is what you get.

However, keyswitches are a whole other story. In terms of simplicity, keyswitches can mean wonderful ergonomics (realtime articulation switching, K2's custom keyswitch feature, etc.), but economics as well. In the case of x64, it is an ideal way of consuming maximum RAM per every K2 instance and using up all the free physical memory at your hands. Or in other words - having basically the entire orchestral template with every articulation you might need up and ready to go with the first and only multi launch.

However, if you don't like keyswitches, but run extremely large templates, chances are you will need many K2 standalone instances and depening on your audio interface, at one point you might run into problems with insufficient number of free audio channels and will either have to use virtual audio cables with additional overhead (mostly latency) or go back to to the process of bouncing.

However, this is very unlikely to happen as if you run huge sound templates, you're probably already running keyswitches or have some other way of dealing with enormous numbers and have thought of possible audio channels issues in advance. Still, it' worth mentioning.

Another important thing to mention is that every K2 instance LaaTiDo'd in a x64 is reported to go all the way up to 3.5GB before poping memory problems. However, as you will see from my tests, you will have serious problems ever getting to 3.5GB even with every single MIDI channels holding a pre-programmed EWQLSO keyswitch, so there are really no worries regarding the memory limit per K2 instance, unless you plan on doing your own keyswitches with more than 20 different articulations per patch, or something like that. :)

So, here we go ... Let's see what happens with the first K2 instance when I try filling all 64 slots with the largest EWQLSO patches - the keyswitches.

...

Vatroslav
04-02-2008, 06:20 PM
INSTANCE 1

Okay, so I based my KS patch choices for the test according to what I would usually need for a piece like the one I posted here and started loading from the bottom of the orchestration upwards.

First port filled. So far so good, no issues.

http://img185.imageshack.us/img185/1318/instance1ramtestport1edee4.jpg

Second port filled. Still no problems.

http://img186.imageshack.us/img186/9950/instance1ramtestport2edwi4.jpg

Third port filled, no issues.

http://img139.imageshack.us/img139/9251/instance1ramtestport3edvz3.jpg

Port 4 - freeze at slot 7. Had to crash the whole program and start again.

http://img185.imageshack.us/img185/7278/instance1ramtestport4edzz9.jpg

Everything fine again until port 4 and around 2.3GB of loaded samples. Then - freeze. Pretty strange, especially having seen up to 3.3GB of loaded samples in a 2.2.1 instance.

Okay, so let's leave it at 2.3GB, start stuffing KSs in the second instance and see what happens.

http://img223.imageshack.us/img223/7914/instance1totaleditex0.jpg

...

Vatroslav
04-02-2008, 06:21 PM
INSTANCE 2

First port filled. No issues.

(Somewhere around this point I used up all of the S and F keyswitch patches and had to start with the remaining instruments that have no KS programming in EWQLSO to complete the template I would need).

Second port filled. Everything fine.

Third port filled. No problems yet.

Port 4 - freeze again, but already at 1.20GB.

http://i32.tinypic.com/250lcpj.jpg

Very strange. Let's try again, but let's stop on at Port 2.

To get to 1.20 already at the second port, we'll have to use keyswitches again. So to be sure nothing is divided between the channels in the cache, let's go with C position (that I never use).

Port 1 - no problems.

http://img383.imageshack.us/img383/2128/instance2ramtestport1edvx0.jpg

Port 2 - no problems at 1.30GB, so let's leave it at that not to have a freeze again.

http://i32.tinypic.com/2weao9f.jpg

http://i30.tinypic.com/24y2t11.jpg

Moving on to instance 3.

Vatroslav
04-02-2008, 06:22 PM
INSTANCE 3

(Continuing to load patches that I would usually use with this kind of track).

First port - went fine, no problems.

http://i30.tinypic.com/52mdxz.jpg

Second port - still good, no problems.

http://i28.tinypic.com/kd4uno.jpg

Third port (no KSs left to load) - still no issues.

http://i29.tinypic.com/2010ked.jpg

Port 4 - and finally got what's causing these issues.

First, somewhere around the fouth patch at Port 4, the following message popped up:

http://i26.tinypic.com/hwzn1f.jpg

Having seen this before on x64, I had virtual memory minimum crossing my mind, and - I was right. As I continued loading patches, at one point Virtual Memory Minimum Too Low ballon tip warning popped up and Windows started raising the paging file on its own for the running app to be able to continue loading the requested data.

Now, considering that this is an immense hit on the system however you slice it, this is hardly a memory leak and just the result of paging file values being set exactly where the load process problems started to occur.

Anyway, once Windows raised virtual memory enough to host all of the patches in the full K2 instance 3, there were no more problems and I filled all of the slots in Port 4.

http://i29.tinypic.com/11tsaxg.jpg

So the total sample memory with 64 channels filled in instance 3 was around 1.80.

http://i27.tinypic.com/2e5v7o3.jpg

So, to make sure this wasn't an "accident", I unloaded all of the instances, rebooted, raised the virtual memory values for the system drive manually, rebooted again and started loading the instances.

Now, a multidrive structure is perfect for good virtual memory managing as it allows you to set paging to any drive you desire (especially if we're talking about large drives with lots of free space), which is especially convenient if you have a drive not used for data streaming (something like audio files drive - 5th sample drive in my case, not used at all in this project).

However, all this applies to the limits of x32 eviroments. In x64 (especially XP x64 toping at 128GB of physical memory, unlike lighther versions of Vista toping much sooner on purpose ;)), virtual memory might not be needed at all. The thing is, I wanted to do all of these tests (latency, CPU, DFD and finally the RAM experiment) with paging memory management on.

However, with 8GB of memory space available, paging might not be needed at all. On the other hand, if it is turned on, total virtual address space in x64 world are 16TB compared to x32 where they are 4GB (the total physical memory limit by un-indexed enviroments).

The rule of thumb for x32 systems is to have virtual memory set to at least 2.5 times the size of the RAM, given that you have enough hard drive space to support it. x64 is another pair of socks, but the original XP x64 paging settings that come with the installation of XP x64 are clearly not functional for heavy loads, so some additional tweaking is need to make it work. (I thought the original programming of XP x64 sets virtual memory to higher values automatically, but obviously it doesn't, hence all of the issues).

And so, after tweaking virtual memory settings and rebooting, I started loading the three saved multis and - voila, no problems. All three multis load fine. The only problem I still have are somewhat slow openings of the instances' GUI when clicking back and forth between the three on the same monitor, but that's expected and it's not making any significant discomfort, at least not for me.

I even tried adding some additional instruments to the half-filled instance 2 and didn't run into any problems after tweaking the paging, so I quit doing it.

I could have screenshot all this, but it would look the same as all the pics above.

Vatroslav
04-02-2008, 06:23 PM
The important thing is the system takes the hit well and the idle CPU states per instance with all three instances loaded are:

INSTANCE 1

~20%

INSTANCE 2

~15%

INSTANCE 3

~35%

Clearly, there is very little headroom for anything that would happen once the play button is clicked, but that's a whole other set of tests. :)

BTW, the cold load times are (channel buffers don't matter that much when it comes to load times):

K2-1: 7:48
K2-2: 2:29
K2-2: 6:28

:eek:

Yeah, well, that's what happens with keyswitches. :)

The good news is, you do this once and never again until you turn off your computer.

Now, of course, what would make sense is to test the CPU at different latency settings with all three instances loaded like this, but, like I said, I had to leave that for some future set of experiments. These are just initial reports on the system hits by masive RAM loads and, well, so far so good.

Of course, it would make sense to try to fill the remaining memory space with other libs, but since this entire test is devoted to EWQLSO Platinum Pro XP, I didn't want to go any further as this just goes to show that, as increadible as this may sound, you can have the entire symphonic template from three different pickup points up and ready within ~6GB of RAM space and at pretty low idle processing values.

So, to sum up, with three K 2.2.1 instances (I'm deliberately writing the version number as this is the last light version of K2 - this doesn't matter here, but just so you know), 2.3GB total sample memory in instance 1, 1.3GB in instance 2 and 1.8GB in instance 3, I had 5.4GB of loaded samples and almost the entire EWQLSO library pre-loaded in my memory and still with around 1.5GB free space (the 1 remaining GB reserved by the OS for system files).

...

Vatroslav
04-02-2008, 06:24 PM
Conclusion

Well, x64 is here. There's is simply no more doubt about it and with Windows XP x64 SP2 it is about as stable as any system I have ever worked on.

After conducting all these tests, the obvious question that some of you have probably asked yourself is - if I can get an average 120-piece assembly with less than 1GB of total sample data, why would I need a x64 system at all?

Well, it's a very good question, but the answer can be twofold.

First of all, from everything that I have tried by now (installing all of the audio software at my disposal and trying to run it, running a massive template, tweaking different settings for different performance test purposes) I can peacefully proclaim Windows XP x64 SP2 as platform that will work just as good as its x32 younger brother.

So in the end, it doesn't really matter much if you are going for this version or in termsof stability and compatibility and it is obvious that the whole x64 horror stories hype still going around is either a bunch of unintentional misinforming or Vista-based reality (the latter is more probable).

If your usual template means massive messaging you wish to perform on a single machine system, you will obviously need a x64 powerhouse system. Whether it's a server-class architecture or a consumer-level assembly, you will need resources to make it click. If you're aiming at workflow and simplicity, you will need a x64 system.

With the new era of x64 multitimbral virtual players like PLAY, you need a x64 OS regardless of the amount of physical memory in your memory modules.

If none of the above applies to you, you may not need a x64 enviroment to work in (yet).

But again, at the end of the day, considering the obvious top-notch programming on both MS and application developers side, whether you are running your audio on XP x32 or XP x64 platform could not matter less compatibility wise, which is without doubt professional community's most important concern.

What you do need if you want high-performance computing in a x32 enviroment, on the other hand, are the drive structure and processing units that are able to support your musical ideas without a workflow compromise.

Which brings us to one of the most important conclusions we can make from all of the tests conducted - contrary to the popular word going around, the computing power on the side of the processing unit is a lot more important in a streaming audio system than it is given credit for. As a matter of fact, CPU power if likely the key to a working single x64 machine audio system.

If your goal is to stay in the MIDI world from the very first note of entry all the way to the final mixdown to audio on a single machine (whether x32 or x64), you will need processing power that will be able to execute under very low latency values.

On the other hand, if you have no problems with audio (input or event) seriously laging behind the visuals, it is highly unlikely you will experience a clash of system resources at any time, whatever your music might be doing.

Of course, all this is just speculations, but considering that computer music is just mathematics in terms of performance potentials, some general assumptions can be made.

Again, it is up to you to asses the requirements of your future system if there is one in your plans and the level of comfort at which you want to work at, but based on some of these tests, I think you are able to make some judgements regarding what you need for your music and what might work for you, and what will be an unnecessary investement.

So, that's it.

I will continue reporting my findings with some of my future works and posting results on this thread, and it would be great if I wouldn't be alone in this. That is, if those of you on single x64 machine systems would join in with your own experiences with different system configuration settings that you tried and describe the system behavior at different conditions and attach some screenshots and the music piece in question.

I will try testing other EWQL libs in future tests, alone and combined together, and we'll see what my system has to tell us.

Thanks to everyone who has had patience to read this, I hope it was helpful and sorry for and overlong thread. :)

If you have any questions or anything, feel free to PM me, IM me, e-mail, myspace me or whatever me anytime.

(BTW, to those of you wondering - this took five days and about 50 hours to write - yes, I am tired. :)).

MellotronGhost
04-02-2008, 06:35 PM
wow - hats off for such an in depth report!

now, let's do this again on a mac and logic when the play orchestra is out... :-)

Aetius33
04-04-2008, 08:20 PM
Good stuff....reassurance of my upgrading to a x64 system :)

Thanks dude

DW

ewkarl7777
04-04-2008, 09:50 PM
Thank you for taking the trouble to post all of this.

I will re-read this several times to make sure I understand all of the information.

persentio
04-05-2008, 04:59 AM
Thanks Vatro! Printed everything out to study!

Jamtheguitarman
04-05-2008, 12:22 PM
This is the best article ive ever read regarding the technicalities of sample-computing.

It should be published in all the computer music magazines.


Thanks very much. :)

nostaller
04-05-2008, 12:56 PM
yaeh man .... thats the kind of "dream Post" I could never have dreamed of ....
THANKS so MUch for the Work....

Cheers, Nostaller

nostaller
04-05-2008, 02:10 PM
yaeh man .... thats the kind of "dream Post" I could never have dreamed of ....
THANKS so MUch for the Work....

Cheers, Nostaller

PS: By the way - When did you have time to gain your COMPOSING AND TECHNICAL skills that far at only 25 ? ! ? ! ?

tys
04-05-2008, 05:06 PM
Dear Vatroslav

Amazing work - and congratulations with your new system :)

Especially your hardware considerations were very helpful.

Mathias

rainmain
04-06-2008, 12:53 AM
Dude, write a book. Seriously. Awesome.

Vatroslav
04-06-2008, 01:54 PM
Lol, thanks, guys, I'm glad it's helpful. :)

PS: By the way - When did you have time to gain your COMPOSING AND TECHNICAL skills that far at only 25 ? ! ? ! ?

A lot can be done in a second my friend. ;)

Dude, write a book. Seriously. Awesome.

Forum posts get printed faster. :)

BertW
04-07-2008, 02:51 PM
I'm curious about your virtual memory settings. I left the page file setting turned off. Are you saying you are having better results with virtual memory turned on?

RCRees
04-07-2008, 03:27 PM
WOW. I am impressed on SO MANY LEVELS! With EastWest going 64bit, I was pretty nervous about the future, but this helps ease the fear a little.

Thanks, Professor,

Rob

Vatroslav
04-08-2008, 03:39 PM
I'm curious about your virtual memory settings. I left the page file setting turned off. Are you saying you are having better results with virtual memory turned on?

No, I just forgot to turn off paging after the OS install. Obviously, it creates problems and with 8GB on x64 I really don't see the reason for virtual memory.

But I haven't yet tried filling multiple instances without paging, so can't say yet.

WOW. I am impressed on SO MANY LEVELS! With EastWest going 64bit, I was pretty nervous about the future, but this helps ease the fear a little.

Thanks, Professor,

Rob

Just a kid in a bedroom, my friend.

chalfant
04-10-2008, 07:23 PM
That was a massive undertaking and one that I hope many will appreciate, I know I certainly did. Thank you for all your hard work....

OneThrow
04-13-2008, 01:37 AM
Wow! That was seriously heavy! And it was great.

I take my hat off to you.

I am considering upgrading to 64 bit and this series of posts will help a lot. One read is not enough. Without doubt I will have to read it again to take it all in.

Much appreciated.

drum4umusic
04-13-2008, 09:24 AM
Yes, what an excellent review for those entering the 64 bit realm. I will certainly try out some of your conclusions. I really appreciate the effort and time you put into this.

Matt

Vatroslav
04-13-2008, 01:43 PM
No problem, guys, glad you're enjoying. :)

Nash
04-16-2008, 10:56 PM
Great Job professor!!!

I like it!!!

:D :D:D

TAFKAT
04-17-2008, 05:27 PM
Hey Vatroslav,

I just needed to drop in and tip my hat .. ;-)

I do need to read thru more thoroughly when I get some time, I just had a quick skim for now, but from what I have already read, the information is extremely detailed and of great assistance to those wanting to navigate to a x64 DAW environment ..

Awesome stuff Mate.., huge effort, and incredibly generous for you to share.. :-)

Peace

V:

johng
04-28-2008, 12:33 PM
Thank you, V. An enormous act of generosity to share this with all of us.

ChrisE
04-28-2008, 03:19 PM
Well I finally decided to take the plunge too and this thread has been a great help. I finally went with a Q6600 processor, 8GB of DDR2 800 RAM, a GeForce 7300, Windows XP 64, and a RME 9632 soundcard. I got a different motherboard, PSU, case, etc but I tried to keep the essentials the same.

Its all coming tomorrow *gulp* so wish me the best of luck trying to fit it altogether.

Thanks Vatroslav, it's great advise from people like yourself and Lex that keep me coming back to this forum (along with owning quite a few of their products). I hope you realise how much people appreciate threads like this.

Chris

Udo
04-28-2008, 04:59 PM
The following is not specifically related to win 32 vs 64, but more about XP vs Vista.

As I understand it, Win XP64 still suffers from the same audio related handicaps as Win XP32. These were addressed in Vista and from the test results I've seen, it appears that audio performance has improved significantly.

According to MS, the amount of code that ran in the kernel (coupled with buggy device drivers) prior to Vista, caused the audio stack to be one of the leading causes of Windows reliability problems.

The major audio related change in Vista is that the entire audio stack was moved out of the kernel and into user mode. Previously, the audio stack lived in a bunch of different kernel mode device drivers. In Vista, the only kernel mode drivers for audio are the actual audio drivers.

A default Vista installation has a larger footprint, although that can be reduced somewhat.

BTW, ....

......, considering the obvious top-notch programming on both MS and application developers side, .....
....thiat is very debatable!

teraslasch
05-07-2008, 02:37 PM
i have a question which is: u are currently using CUBASE 2, which is. 32bit. i am well aware that sonar 32 bit works great in xp64 , but not sonar 64 bit in xp 64, which is my greatest concern over switching to xp 64 . Because i want to take advantage of the play libraries i currently have, as well as use my other libraries with kontakt 2.

If i was using sonar 64 bit in xp 64,would i have lots of stability issues? I have been reading the cakewalk forums, and the people have been saying a big NO to xp 64 , because of sonar 64 in xp 64, and not 32 bit sonar in xp 64. and yet, this is my biggest concern. I was hoping that i could load a limit of 3+ gigs for kontakt 2 (and other NI vsts) , + my play libraries on top of that 3 gigs, with a quad core pc with 8gb ram ;). Is this possible? yes no? I hope someone can answer me with this. I don't mind selling off my tascam fw 1884 for an RME interface if that is what it takes to get my dream system working. thanks alot :D

nikolas
06-08-2008, 12:37 PM
Just wanted to bump this and ask the EW moderators to stick it on a forum, please!

Thanks Vatro, this is simply stunning!

EDIT: What do you know? It's sticky already! Damn my beautiful eyes! :p

peter5992
06-08-2008, 02:13 PM
Hi Vatroslav:

I'm running a little bit behind the other posters, but thanks a million for posting this indepth post - very helpful for me, since I am about to upgrade my own DAW (or rather, have it done by someone) from 32 bit windows xp pro to 64 bit xp pro - specifically with a view to the upcoming Play engine. I will forward him a link to this post.

Take care,

Peter

ps impressive music by the way - big sound.

Vatroslav
06-09-2008, 07:59 AM
Hey, guys, thanks a lot for all your kind words, I'm really glad the thread is helpful to you all. :)

I'm busy all the time, so I hardly ever visit here anymore, but it's great to see the performance report having so many views in only two months.

If you need any help, just drop me a line. ;)

bwherry
07-13-2008, 09:37 PM
Thanks Vatroslav! I just got my new Quad Core 8GB Win XP x64 machine up and running today. I went with many of the same things you did. ;) Many thanks. Now I just need EWQLSO Play Edition to arrive!

This machine will be a slave for my (older) Pro Tools LE host machine. The plan is MIDI out to slave via MIDIoverLAN, digital out back into PT. I'll post how it goes...

Thanks again and cheers!

Brian

DaddyWarbucks
08-05-2008, 11:22 AM
Wonderful piece and we are using your guidance to configure our new DAW. We are very confused about soundcards. Not sure what to make of this part of your post:

BEWARE - in order to have multiple standalone K2 instances running audio on the same ASIO audio driver properly without major workaround efforts, you need an audio interface with multiple analog channels programming. That is why this particular audio interface (RME 9632) will never be able to execute even a completely other audio app riding the same ASIO driver with a K2 instance at the same time (like a sequencer - my Cubase simply can not output audio with K2 open at the same time on the same ASIO), let alone multiple standalone K2 instances.

Possible workarounds for this (apart from the one already described - using one K2 instance in standalone mode and the others as plug-ins i na LaaTido'd host) are to either try to connect the built-in audio card in your MOBO with your soundcard physically to try to override the reserved channels, to get a so-called expansion card for additional audio channels from the audio card manufacturer, or to get a second soundcard (or switch to the built-in soundcard altogether - if that one can do what the purchased one can't).

Usually (with a card with multiple analog channels and different ASIO management scheme), all you would need to do is just copy the .exe icon of K2 (not the shortcut on the desktop but the actual .exe in the installation directory in Program Files), in most cases that would be enough and you wouldn't need to do any additional tweaking (the already mentioned shortcut dumping, audio channels arranging, multi saving, etc.), but with audio interfaces with only two analog channels, whatever you do, you will not be able to override NI's channel reservation programming and therefore never be able to run multiple standalone K2 instances on the same driver.

This could, of course, be solved if freeware drivers such as ASIO4ALL were written to allow multiple applications to run on it or if they could run standalones next to other standalones on other ASIO drivers, but, unfortunately, the mentioned freeware does not have such capabilities in the current version.

Again, all this hassle is due to K2 audio channels programming which reserves certain audio channels by default, thus creating artefacts in sample audio playback such as crackles, pops and clicks, or no audio at all (especially if the audio channels arrangement is not done properly - that is, from the top downwards in the order of instances' opening - 1&2, then 3&4, 5&6, and so on).

We plan to use Play/Symphonic Orchestra Plat XP with Sonar Home Studio XL 6.2. No live recording. What do you mean by "multiple analog channels programming"? Are you referring to the number of analog inputs or something else? Perhaps you could expand your explanation? Thanks.

Vatroslav
08-06-2008, 06:33 PM
Wonderful piece and we are using your guidance to configure our new DAW. We are very confused about soundcards. Not sure what to make of this part of your post:

BEWARE - in order to have multiple standalone K2 instances running audio on the same ASIO audio driver properly without major workaround efforts, you need an audio interface with multiple analog channels programming. That is why this particular audio interface (RME 9632) will never be able to execute even a completely other audio app riding the same ASIO driver with a K2 instance at the same time (like a sequencer - my Cubase simply can not output audio with K2 open at the same time on the same ASIO), let alone multiple standalone K2 instances.

Possible workarounds for this (apart from the one already described - using one K2 instance in standalone mode and the others as plug-ins i na LaaTido'd host) are to either try to connect the built-in audio card in your MOBO with your soundcard physically to try to override the reserved channels, to get a so-called expansion card for additional audio channels from the audio card manufacturer, or to get a second soundcard (or switch to the built-in soundcard altogether - if that one can do what the purchased one can't).

Usually (with a card with multiple analog channels and different ASIO management scheme), all you would need to do is just copy the .exe icon of K2 (not the shortcut on the desktop but the actual .exe in the installation directory in Program Files), in most cases that would be enough and you wouldn't need to do any additional tweaking (the already mentioned shortcut dumping, audio channels arranging, multi saving, etc.), but with audio interfaces with only two analog channels, whatever you do, you will not be able to override NI's channel reservation programming and therefore never be able to run multiple standalone K2 instances on the same driver.

This could, of course, be solved if freeware drivers such as ASIO4ALL were written to allow multiple applications to run on it or if they could run standalones next to other standalones on other ASIO drivers, but, unfortunately, the mentioned freeware does not have such capabilities in the current version.

Again, all this hassle is due to K2 audio channels programming which reserves certain audio channels by default, thus creating artefacts in sample audio playback such as crackles, pops and clicks, or no audio at all (especially if the audio channels arrangement is not done properly - that is, from the top downwards in the order of instances' opening - 1&2, then 3&4, 5&6, and so on).

We plan to use Play/Symphonic Orchestra Plat XP with Sonar Home Studio XL 6.2. No live recording. What do you mean by "multiple analog channels programming"? Are you referring to the number of analog inputs or something else? Perhaps you could expand your explanation? Thanks.

Hey, John,

I've already answered the e-mail that you sent me in the meantime, but I thought I might copy/paste a part of my reply to the thread as well:

Basically, it all sums up in one sentence - if you use a native, end-to-end 64bit system, you have no worries as to the software side of things. Native 64bit system means x64 OS, 64bit DAW (sequencer - Sonar in your case) and 64bit player (PLAY in your case - the 64bit version of PLAY, that is).

With a 64bit player like PLAY even if your sequencer is 32bit you need not worry about anything, with respect to the addressing space issues. If you want to have maximum processing efficieny of your system, you will use your 64bit player, PLAY in your case, in standalone mode and it won't matter whether your sequencer is 32bit or 64bit - that is, if it operates within native addressing or within Microsoft's WOW64 subsystem - the so-called "wrapper" that makes 32bit applications able to operate in a x64 enviroment, in this case Windows XP x64.

The main and only reason why you need not have any of your current worries is PLAY being a 64bit application - or rather having a 64bit version to go with the backup 32bit version for x32 systems - there are uses for that one as well - but only for x32 systems.

A 64bit player like PLAY means that, unlike 32bit players, one instance is not limited to the theoretical 3.5 GB of loaded sample data within itself in a x64 OS (2.7 GB in a x32 OS) as Win XP will reserve 1GB of physical memory whether it's Win x64 or x32, so in a x64 you will theoretically be able to preload 7GB of sample data in only one instance of PLAY. This is, again, due to PLAY being a 64bit application which means that it is mathematically, and ultimately physically, not limited to phyisical memory limits of a x32 enviroment math.

For different reasons, whether you will be using Sonar 32bit or 64bit, I would strongly suggest using PLAY in standalone mode - hardware and software reasons sparingly.

In terms of hardware, you will get much better processing performance, and in terms of software, the two apps (the sequencer and the player) will run independent of one another and you will have a much more stable system and both of the apps feeling much happier.

The only downside, if that's what we need to call it, to using a player in standalone mode on a single system is loopbacking - routing the outputing audio back into the sequencer for recording.

Unless your soundcard has so-called loopbacking capabilities which will enable your sequencer to capture the outputing audio that comes out of your player, you will either need to 1) physically route the audio back into the card using cables, 2) use the built-in card in your motherboard (I strongly suggest again it), 3) use an external audio recording device (such as a minidisc recorder, for instance, or any other digital - or even analog, if that's not a problem for you - recording device, whichever it may be) or 4) buy a second soundcard altogether.

With RME's Hammerfall series (which RME 9632 is a part of) as well as some others like some of the EMU's series, you will have no problem looping back - it is a one-click procedure and about as simple as it gets, even if the GUI of the card's mixer isn't the simplest thing in the world to find your way around.

The looback capability is one of the biggest advantages of RME's Hammerfall series when it comes to ITB (in-the-box) musicianship like sample-based computing, but when it comes to the rest, you can find cards with more use for sample mockups and save money.

So, basically, that's it. I hope all this is helpful. :)

jbone1313
10-23-2008, 02:08 PM
Unless your soundcard has so-called loopbacking capabilities which will enable your sequencer to capture the outputing audio that comes out of your player, you will either need to 1) physically route the audio back into the card using cables, 2) use the built-in card in your motherboard (I strongly suggest again it), 3) use an external audio recording device (such as a minidisc recorder, for instance, or any other digital - or even analog, if that's not a problem for you - recording device, whichever it may be) or 4) buy a second soundcard altogether.

With RME's Hammerfall series (which RME 9632 is a part of) as well as some others like some of the EMU's series, you will have no problem looping back - it is a one-click procedure and about as simple as it gets, even if the GUI of the card's mixer isn't the simplest thing in the world to find your way around.

The looback capability is one of the biggest advantages of RME's Hammerfall series when it comes to ITB (in-the-box) musicianship like sample-based computing, but when it comes to the rest, you can find cards with more use for sample mockups and save money.



Does anybody else get popping and crackling during their audio playback when doing loopback internally with the FireFace 400? If so, have you got a workaround?

The way I've been able to work around this is to loopback the audio with a physical cable with my RME FireFace 400. I use ASIO4ALL as PLAY's audio driver in this case, and the RME driver in my host.

It seems the problem occurs when I use the RME driver in both PLAY and my host.

Is it true that ASIO4ALL can only drive one app at a time?
Any insight would be appreciated.

jbone1313
10-25-2008, 11:07 AM
Does anybody else get popping and crackling during their audio playback when doing loopback internally with the FireFace 400? If so, have you got a workaround?

The way I've been able to work around this is to loopback the audio with a physical cable with my RME FireFace 400. I use ASIO4ALL as PLAY's audio driver in this case, and the RME driver in my host.

It seems the problem occurs when I use the RME driver in both PLAY and my host.

Is it true that ASIO4ALL can only drive one app at a time?
Any insight would be appreciated.


BTW: There is a good discussion about this on the RME Forum that I've just found. I've posted a reply there too.

http://www.rme-audio.de/forum/viewtopic.php?id=1189&p=1

David Adeyemi
02-01-2009, 10:59 AM
Thanks for the post Vatroslav. Very extensive. :cool:

Bessinnox
02-07-2009, 09:43 PM
flag I'll read later ? it's 5.43 A.M. and I can't read anymore.:D

vjs123
07-17-2009, 11:02 PM
what is the difference between dual core processor and quard2duo processor is there any performance variation

iiWii
07-22-2009, 05:05 PM
Wow. Can't believe how perfect the timing was for this thorough fleshing out of the 64bit thing. I'm piecing together a new system now- anybody got suggestions about a good motherboard with a proven track record of running XP 64 AND audio production? I'm using SONAR. Would appreciate any leads...

JamesBond007
09-25-2009, 09:46 AM
Hi,

Great article and got me thinking.

I am running an AMD Dual Core 6000+ and Macpro 2.66 Dual Core. My Play Platinum Orchestra runs great on my Mac but on my PC it is unusable.

I am running the AMD on home XP and thought that if I installed the XP64 System on my AMD, Play would run great as its not taking advantage of the dual cores under XP home. Also Play has the software to work on 64bit.
My soundcard, Motu 2408 also is 64 bit ready.

Do you think installing XP64 will make Play work better and is it worth all the effort to change systems.

Thanks,

JB