LIVE FIVE PERFORMANCE TEST - results here

[tumult]

No problems with setup. The MOTU drivers work great on Intel. MOTU makes really solid hardware, you can't go wrong with them.

Live 5 works down to a 32 sample buffer (1.43ms) for me. Below that, you start getting pops regardless of CPU usage. On the performance test, a 32 sample buffer uses 25% cpu. I usually run Live with a 128 sample buffer, which yields about 21% cpu usage on the performance test.

I wish I could give you some Live 6 benchmarks with MOTU hardware, but I'm not in the beta group.

[silicon1138]

ok, i've just been running the live 5 test on my macbook, but under windows under parallels. I could only get the latency down to about 33ms, but even so the live cpu mater was reading about 55%!
The pc audio buffer slider is very unstable and hard to set. I will do a full test in daylight and report back. My macbooks cpus were both showing 65% each.
And all this is with only 512ram. I've got another gig arriving this week, so i'll do more tests.
My jaw is on the floor considering this is under Parallels.

From what i've seen so far, parallels is really stunning. Windows feels very snappy.

I just tested my G5 dual 1.8 and it scored 64% using 500 latency setting!!!

[davide37]

1. 8% with multicore on, 12-13% with multicore off.
2. Self-build.
3. Windows XP SP1.
4. Intel Core 2 Duo E6400 2.13 GHz overclocked to 3.28 GHz (!).
5. 2 Gb dual channel DDR2 800Mhz.
6. Emu 1812 + Creamware Scope.
7. WD Raptor 150 Gb 10,000.

This is with Live 6.0b9. All in all, pretty cool! And I'd strongly recommend the Core 2 Duo as giving amazing bang for the bucks.

Regards,
David

[veggieryan]

1. 23%-25%
2. Toshiba Tecra M7 Tablet Hybrid with Intel 950 GMA graphics
3. Windows Vista Pre-RC1 build 5552
4. Intel Core Duo T2300E 1.66 GHZ!!!! yes only 1.66. vista is very quick. its like the windows 2003 kernel which was always faster for audio... only everything else just works whereas 2003 was picky.
5. 1.5 GB pc4200 ddr ram
6. 44.1k Echo Mona Laptop Carbus with new version 6.14 driver at 64 samples latency ableton reports as 2.79ms in / 3.06ms out (interestingly guitar rig standalone reports it as 1ms... either way its inaudible)
7. 60GB 5400rpm SATA laptop drive

This is just incredible. Vista is really coming together with a quickness. the jump from beta 2 to 5472 was HUGE.. the jump from 5472 to 5552 is equally impressive. install time was 25 minutes. All the drivers installed themselves perfectly.

Bear in mind that this is true 64 sample latency because it is carbus or pcmcia which is pci. Pci enjoys a direct connection to the computer which allows it to achieve lower latency at lower cpu costs. Firewire always adds an additional 64 samples beyond the 32 or 48 that Motu and Rme are showing you. Check your output latency.. see why its larger than the input? Thats the inescapable additional 64 sample buffer needed to keep the pops and crackles out of firewire at low latency.. even then you still get additional cpu overhead.


At 64 samples I am able to surf the web ctrl-tabbing through 100 tab-windows open in firefox and have a crapload of other programs running and there are no pops or clicks. In osx or xp this was not even remotely possible. This is the kind of performance I had always dreamed of, but never could achieve until vista.

Overall it appears that I am getting about 5-10% better performance with vista 5552 than with xp. plus everything else is so much sexier. oh, and ALL my software just works. which is SOOOO nice.

FROM THE HORSES MOUTH:(this applies to all firewire audio)
"Unlike most of RME's PCI-based audio hardware, which offers a minimum buffer size of 64 samples (1ms latency at 44.1kHz), the Fireface offers values as low as 48 samples, alongside larger buffer sizes of 64, 128, 1024, 2048, 4096 and 8192 samples. However, there is a small caveat here because in order to ensure the reliable transmission of audio data over Firewire, the Fireface makes use of what RME term a 'Safety Buffer', which is a 64-sample buffer that's accumulated to the existing driver buffer on playback"

This means that the actual minimum playback latency is 48+64=112 samples, and the minimum theoretical software-based monitoring latency through an ASIO application such as Nuendo is 48+64+48=160 samples. As an example, with 48 samples set as the buffer size on the Fireface, Nuendo reported 1.134ms as the Input Latency and 2.585ms as the Output Latency with delay compensation enabled. And while the Safety Buffer might sound like a disadvantage, 112 samples is still acceptable, and it does ensure the Fireface works reliably, especially at higher sample rates such as 192kHz.


Cheers!

[veggieryan]

I should mention there are only two things to disable to achieve this low latency performance. these are the only 2 that affect performance. Without disabling them you will have pops and clicks at 64 samples.
Other than that.... Vista is gorgeous.. no need to tweak anymore than this.. leave the rest as is and enjoy ultra low latency with no pops or clicks while running whatever other programs you want... jaw dropping. Bravo microsoft. You have redemmed yourselves!

from http://www.longhornblogs.com/chris123nt ... 16458.aspx

1. Disable UAC

UAC, otherwise known as UAP (User Account Control/User Account Protection) in previous builds is another one of those features that just seems to get in the way of doing your work. This feature is designed with the average user in mind who needs this kind of protection to keep themselves out of trouble. If you are reading this then chances are you know how to manage your own system. Here is how to disable UAP:

1. Press the Windows Key + R (winkey + R).
2. At the run prompt, type "msconfig" without the quotes.
3. Go to the Tools tab, scroll down and select "Disable UAP" and click the run button.
4. You should see a command prompt open and it will say "Command completed successfully".
5. Reboot and enjoy the freedom to control your system as you wish.

2. Disable DEP / NoExecute Protection

DEP, otherwise known as NoExecute, is a piece of technology in Windows that prevents processes from being altered in live memory. This lowers the frequency of certain attacks, but it can also have some adverse effects and cause certain things not to run.

Due to the way Windows Vista™’s boot editor has been created, it is now harder to disable DEP / No Execute Protection. After a little looking around, I figured it out. Here's how to do it:

1. Click Start, All Programs, Accessories, right click on “Command Prompt”, and click “Run as administrator”.
2. If asked for permission to run Windows Command Processor, click on Allow.
3. At the command prompt, type in “bcdedit.exe /set {current} nx AlwaysOff” (without the quotes).
4. You should receive a message saying “Operation Completed Successfully”.
5. Restart the computer, DEP / No Execute should now be disabled.

oh, and do the old right-click my computer - properties - advanced settings - performance - set for background...

enjoy.. it is AWESOME!!!!

[Vance]

Interesting... can anyone else confirm these Vista results with a similar-spec machine?

[CWoodOne]

Great changes on both the Mac and PC fronts these days... multicore, multiprocessor Live ROOLS

[longjohns]

so you'll have 2ms latency over firewire. the horror!

[veggieryan]

actually you will have 3.6ms minimum latency at 44.1k with additional cpu load, more timing errors and general flakiness. these are the facts to help people chose a soundcard wisely.

also, to get the performance with vista I just posted, be sure to use the old standard intel drives from intel.com for the 945 gm express chipset. don't use the new ones from microsoft as they are in thier first beta and more cpu intensive.

cheers!
ryan.

[word]

wow what is going on with the core duo yonah results? With the CPU basically working as a single core in Live 5 on a PC, the results are just about the same as my first generation centrino laptop (a Banias chip that scores around 28% on the performance test). Aside from the dual core is there no improvements over two and a half years? The pi calculation test has shown that a core solo 1.2 Ghz is equivalent to my 1.6 gHz centrino.

[word]

double post mistake, sorry

[Hyperion]

CPU Meter: 30 %
Desktop: Custom built
OS: Windows XP SP2
CPU: AMD Athlon 64 X2 3800+, 2 GHz
Ram/Speed: 2 GB/DDR400
Soundcard: PCI EMU 0404
Drive Speed: 7200rpm


Greetings,

JHS

[veggieryan]

another vista 5552 test...

1.CPU Meter: 21%-24%
2. Toshiba Tecra M4 tablet hybrid with nvidia gforce 6200
3. OS: Windows Vista pre-rc1 build 5552
4. CPU: Intel Centrino 1.73 GHZ dothan
5. Ram/Speed: 1 GB PC4200 ddr
6 Soundcard: Echo Mona Laptop Cardbus at 64 samples(crackles with multiple apps running in foreground.. fine with ableton by itself) 128 samples.. no crackles.. any number of programs running simultaneously.
7. Drive Speed: 5400 rpm

So, to me this means the core duo has some advantage for low latency even if live 5 is not dual processor optimized. I was not able to get rid of the pops and clicks at 64 samples while tabbing through windows in firefox like I was on my 1.66 core duo. Still, Vista shows superior performance to XP giving about 5-10% better scores and much more robust performance using multiple programs while running live a low latency.

Important: As with the duo tests, I am using the standard video drivers, not the new ones from windows update that are more cpu intensive.. in this case, an nvidia geforce 6200 with 64mb ram. It is interesting to me that the intel gma 950, in comparison, appears to have no effect on audio performance even at low latency even though it shares ram with the system....

Can someone test a high speed core duo laptop with a nice new video card on vista 5552? I am curious. How about a core2duo? soon come.. and I will be dropping one in my m7... just because i can...

cool,
ryan.

[tumult]

veggieryan: are you sure about that? I set my buffer at 32 samples in Live 5.2 on a Mac Pro and it really seems like 32 samples to me. I ran the some outputs back into the inputs and it did clock in at 2.88ms. I could be wrong, though. Do you have more info? I haven't heard of this before, and it does interest me.

[veggieryan]

yes tumult.
Great question.
If it were REALLY just 32 samples it would be 1.28 ms overall latency because 32 samples equals exactly 0.64 ms of latency.
your figure of 2.88ms total latency goes further to prove that there are exactly 64 samples ( or a few more since 2.88>2.56) added to the latency that the motu drivers are not showing. They correctly show the input and output latency adjusted for the additional samples but fail to show it in the sample box.. it should say 112 samples.. not 32 samples.
Even at 112 samples you probably wont hear or feel it. The point is that if you were using an rme pci card at 32 samples.. it would actually be 32 samples and the cpu load would be lower, the timing more exact and the reliability much greater. firewire introduces alot of conflicts.
Firewire is simply not designed for audio and is not the most ideal protocol for audio. THERE IS NO WAY AROUND THE 64 additional sample buffer. It is there to compensate for all the pops and clicks that would be there without it. This is needed as Firewire devices lack Direct Memory Access, DMA, that PCI devices have.

look here on RME's site
http://www.rme-audio.com/english/techin ... sts_01.htm