When will we reach 64-bit Nirvana?

[JonFairhurst]

Here it is, Q3 2007. We've had many, many generations of 64-bit chips from AMD and Intel - and motherboards that support them. We've had two generations of 64-bit operating systems from Microsoft. Hardware, driver and application developers have seen this coming for years.

So, why can't we load up 8GB of RAM with samples just yet - or can we?

Last week I bought my wife a laptop, and mentioned that her old desktop might be nice to convert to a sample engine. She wanted to know why I needed another dang computer. I explained the whole sample/RAM relationship and what it does to work flow - and our time.

I then realized that I don't want another computer with networking/audio cards/cables/KVMs/remote desktops. I want a single fast PC with fast drives and 8GB or more or RAM. That's my next upgrade.

As a kid on a long, sweaty drive might say, "are we there yet?"

Vista's audio support apparently isn't streamlined. I assume we need XP64. Then we need an audio card and drivers. Next is a mobo with lotsa RAM capacity. Any current CPU will do. But will GVI or K2 make use of the space? And which sequencer will play nice? And what about a VSTi host that can handle all that RAM? And what of all these stupid proprietary samplers? VI? Play? and on and on...

And ...will it be stable?

Anybody want such a setup?

Anybody got such a setup?

Having just completed a 48-hour film project, I'm fed up with the current RAM limits. I want my samples to have access to the better part of 8GB of RAM for Christmas!

[belbin]

Indeed, Jon. It is frustrating to see processing advance at such a rate while RAM usage seems to be progressing so slowly.

The only silver lining we currently have is the fact that scripting, convolution modelling and iMIDI have given developers the opportunity to reduce sample-pool size while simultaneously making libraries and sample-based VI's more playable and natural sounding. Generally, this results in extra taxation on one's CPU while reducing RAM requirements-or at least it keeps them the same while the sounds continue to improve. So in lieu of growing RAM capacity, we have a move toward shrinking libs that are still better than the old ones. The CPU part is fine, since, as I said, CPU's are getting faster all the time. But RAM nirvana will only come when we have great libs that are small, and enough RAM to load jillions of them.

I've seen a steady stream of discussions about vista and 64-bit since I joined here a couple of years ago, but I sure have not seen the pudding. I know that sampler-developers are working hard on 64-bit comatibility, because we all know that's where samplists want to be....but why is Microsoft saying they care about audio when it is obvious that they have forsaken it in favor of mass-market oriented features like animated desktops??

Personally, I'll keep my eye on on ways for libs and workflow to be continually streamlined until I see some indication that MS is going to give us something we can use. And even then, smaller will be better, since everone who buys libs buys a bunch. Drive size and speed doesn't seem to be advancing very quickly either, y'know :)

-Belbin

[jddamas]

Cobain's dead man!:wow:

:D

[belbin]

Cobain's dead man!:wow:

:D

???

-Belbin

[geronimo001]

???

-Belbin

The singer remember?

[belbin]

Of course. But what does he have to do with...oh nevermind. I get it. :o

Haha! Nevermind! I made a funny too! :D

-Belbin

[cmdratz]

Hi Jon,
I would keep an eye on WIVI for a while. I guess conservatively that their full set of brass and woodwinds may cut one's total instrument memory usage by 1/4, in an orchestral and choral scenario.

[dewdman42]

I think we are just around the corner from 64bit computing on a mass scale. The hardware is now available economically to address large memory. You can certainly run 64 bit XP or Vista. Sonar runs on that platform. But note that not all software apps have been made compatible with 64bit platforms or made to take advantage of it. So its still a bit of an early time to adopt. But i feel that we are just around the corner. At some point something will happen that is like a catalyst that will force software vendors to make their software 64bit compliant, and audio hardware will have to provide drivers, and eventually you won't even have much of a choice to use 32bit anymore, but i feel that is a few years off yet. But I think within 3-5 years, we'll be able to do everything on 64bit that we can do now. However, as of right now this minute, its still a bit early and only for the adventurous.

[JonFairhurst]

...But I think within 3-5 years, we'll be able to do everything on 64bit that we can do now...The thing that frustrates me is that I've already owned 64-bit hardware for 3-5 years. Nuts, huh?

I'm mindful that you wrote "we'll be able to do everything on 64bit." Clearly, my sights are lower, so there should be no need for a long wait. All I need is Sonar 6 (which I already own), an audio card wtih a 64-bit driver, a 64-bit compatible audio card (c'mon M-Audio, get with it! - I can always pick up an Echo Audio card...), and... a 64-bit sampler and possibly a host.

Here's an idea: couldn't a 64-bit VSTi host load 32-bit VSTis in multiple 2 GB spaces? The 32-bit programs would believe that they are in 32-bit land, but the host knows better. Hey, Plogue! Are you listening? Bidule64 with 32-bit VSTi compatibility would be awesome!

Anyway, it seems the sampler/host is the last hurdle.

Regarding modeling, rather than big sample pools, that's fine, but I rather like my Westgate Modular Woodwinds. I don't want to have to buy a new set of libs, just because of the 2GB limit - especially since we are on the verge of a RAM breakthrough.

Frankly, I want to buy libs based on sound, playability, plugging holes in my arsenal, and, of course, price/value. Also, my 2-1/2 year old PC needs upgrading to run lots of synth instruments and still have the guts left for convolution.

So, here's the deal. When a workable 64-bit 8GB+ solution is available, I'm ready to buy. Until then, I'm saving up. I'm going for the whole enchilada - or nothing. (Why buy halfway now when better stuff comes out every quarter?)

This is my own personal 32-bit boycott.

And, yes, developers. Windows XP 64 is fine with me. It's stupid that Vista is so lame with pro audio, but it is what it is...

[janila]

Here's an idea: couldn't a 64-bit VSTi host load 32-bit VSTis in multiple 2 GB spaces? The 32-bit programs would believe that they are in 32-bit land, but the host knows better. Hey, Plogue! Are you listening? Bidule64 with 32-bit VSTi compatibility would be awesome!The 32-bit address space is 4 gigs. Windows XP just takes half of it. That's the point of the 3GB switch, it changes the split to 3+1 instead of 2+2. 32-bit apps get the full 4 gigs in Vista64 if they happen to know what to do with it. I don't know if a 64-bit application can host 32-bit applications. The abilitity to run 32-bit applications in 64-bit Windows is a feature of the operating system and most likely doing that in an application is impossible or atleast too difficult to be reasonable.


So, here's the deal. When a workable 64-bit 8GB+ solution is available, I'm ready to buy. Until then, I'm saving up. I'm going for the whole enchilada - or nothing. (Why buy halfway now when better stuff comes out every quarter?)Buy something when you need something. That saves you a lot of trouble.


And, yes, developers. Windows XP 64 is fine with me. It's stupid that Vista is so lame with pro audio, but it is what it is...Vista64 works a lot better for me than Windows XP. It's not perfect but it works. XP kinda didn't.

[seclusion]

Mac Pro, 4 500 gig sata 2 drives, Logic 8 (looming), Leopard, all are almost ready to go. (I've used Leopard with Logic 7.2.3 no problems).
I doubt my Tascam 1884 is 64 bit on the Mac side yet, but it worked in Leopard.
But what about, Uad-1, Waves, NI and the rest to the plugs?
When I tried Sonar 6 x64 on XP pro x64. Everything ran smooth until I started loading plugins. Then it just fell apart. Mind you that was this time last year.
Now I'm back on Logic on a Mac and I'm staying away from the huge sample libraries for the time being. I just want to write!
Guess you could revive this thread next summer and see where we're at then.
Later
Brian

[loydb]

So, here's the deal. When a workable 64-bit 8GB+ solution is available, I'm ready to buy. Until then, I'm saving up. I'm going for the whole enchilada - or nothing. (Why buy halfway now when better stuff comes out every quarter?)


+1

I normally upgrade my desktop system every 12 months. I'm holding off on this one until I'm happy with the state of 64-bit as well.

[Steve_Karl]

<rant from an aging hippy>

64 bit Nirvana .... smells to me like it's at least 5 yrs. in the future if even ever.

Vista is reported as being patheticly slow compared to XP when it comes to low latency performance.

I don't feel it's even worth approaching at this point in time.

In my opinion M$FT is not interested and possibly even intentionally so.

Why would a corporate giant that is in bed with the likes of Sony and all other MAJOR media controllers be helpful to small individuals that want to produce music and video on a grand scale? Controlling the distribution of media is a much bigger deal than selling good machines and Operating Systems to a few geeks that need better performance.

------------

The real Nirvana ticket is going to be when someone writes an OS ( or tweaks a linux OS ) that is a self containd DAW package complete with sample librarys and player and midi / audio app.

Or, a few of the big ones get together and develope a creative 'cartel' that is designed to do the one package deal that can contain all, depending on what we want to add to it.
Add on packages as you see fit buying them from the original developer.

I feel like F$%^ MSFT and MAC for their bloated code and their petty outlook on life and how to control everyone elses.

(:samurai: rabble rouse rabble rouse !!! :samurai: )

For a moment imagine a meeting of Garritan, Kirk Hunter, The Westgate Folks, Bella D, the brothers that wrote Sibelius and ( insert your favorites here ) and a group of people comparable to the ones that developed and continue to develope Blender 3D. (F1)

There we have the makings of a Nirvana worth dreaming of.

Foot note 1: www.blender.org (http://www.blender.org)

</rant from an aging hippy>

[JonFairhurst]

Okay, here's another option: Solid State Hard Drives:

http://www.anandtech.com/storage/showdoc.aspx?i=3067&p=3

Sure, its only 32 GB, but the access time is 0.1 ms. Thats no surprise. You don't need to swing an armature from center to edge.

Given that, a sampler could be modified to store only, say 1KB, rather than 64KB sample heads. Thats like multiplying your RAM by a factor of 64!

Too bad the solid state drives are still so pricey, but that should change quickly...

[geronimo001]

Okay, here's another option: Solid State Hard Drives:

http://www.anandtech.com/storage/showdoc.aspx?i=3067&p=3

Sure, its only 32 GB, but the access time is 0.1 ms. Thats no surprise. You don't need to swing an armature from center to edge.

Given that, a sampler could be modified to store only, say 1KB, rather than 64KB sample heads. Thats like multiplying your RAM by a factor of 64!

Too bad the solid state drives are still so pricey, but that should change quickly...

Holy crap! o.1!!! The good news is my Pc has SCSI 360 built in!:D Eat this sucker!:D :D :D

How much is this thing?

hmmm... I'm confuse, are we talking about SCSI here or some newer technologies?

:|:

[Steve_Karl]

Okay, here's another option: Solid State Hard Drives:

http://www.anandtech.com/storage/showdoc.aspx?i=3067&p=3

Sure, its only 32 GB, but the access time is 0.1 ms. Thats no surprise. You don't need to swing an armature from center to edge.



Unfortuantely, compared to the nano second access time for ram it's not yet nearly worthy to be used as ram.

We've got more than a few yrs. here to go also, until it's large enough and fast enough to make a machine than has all storage in chip as opposed to on spinning platters.

[JonFairhurst]

Unfortuantely, compared to the nano second access time for ram it's not yet nearly worthy to be used as ram.Steve, it doesn't replace the RAM. You still need sample head storage in RAM for every note. The difference is that with low latency, the sample head can be tiny.

If the maximum latency of the hard drive is cut by a factor of 100 (say from 10 ms to 0.1 ms), then the length of the sample heads can be cut by a factor of 100 or so. That means we could store 100 times as many notes as we do today (if the sampler vendors were to make the sample head length variable.)

Let's hope the costs fall like a rock.

In the future we might be able to use a ton o' samples, as well as great CPU-intensive modeling and morphing.

Another day, another penny in the 64-bit (or solid state hard drive) piggy bank.

[JonFairhurst]

One problem with solid state HDDs is that they are much smaller than magnetic HDDs. The cost per MB is really high.

So... How about a three stage sample engine?

The samples start in RAM, but they're tiny. Something like 1k each. We can store tons of samples.

Next the samples play from the solid state HDD (hard disk drive). There's no 2GB limit. The sampler can own it all. These would be the traditional sample heads. (64k or 128k or whatever.) Because its not as fast as RAM, this should be setup as a one or more long term templates. You'd still have to load the RAM, but the solid state HDD would be ready to roll. It only changes when you change your template.

Another advantage: If the sample heads are 100 times smaller, your samples will load 100 times faster.

Finally, the samples play back from traditional HDDs. They're cheap, big and fast enough. Get a 10,000 or 15,000 RPM drive, if you really need polyphony.

However, this is not a mainstream solution. Vista needs to get its pro-audio support act together. And software vendors need to get with the 64-bit program - without getting distracted by new features.

There is no feature more important than being able to load more samples.

I wonder if the Mac version of GVI will access more RAM?...

[Steve_Karl]

Steve, it doesn't replace the RAM. You still need sample head storage in RAM for every note.

Yes. I was just thinking long term ~ideal~ solution with no moving parts.

Your plan makes sense.

[clonewar]

Mac OS X Tiger is 64 bit, but the apps can only run in a 32 bit address space. This means that the system can have lots of ram (Mac Pros support 16+ gigs) but the apps themselves are still limited to 4 gigs.

In VI Mag, Nick outlined a procedure for loading 7 gigs of samples on a Mac with 8 gigs of ram. Basically you run multiple instances of K2, VSL, whatever, in standalone mode outside of your DAW. You can route audio and midi virtually between the software using Soundflower and the IAC bus.

You can also do this on Windows x64, but the advantage that the Mac has (right now) is that you don't have to worry about which plugins or hardware isn't going to work, and most software doesn't support x64/Vista 64 yet.

I'm counting on K3 to be a native 64 bit app, since samplers have the biggest need for memory. I read that Giga 4 will be a 64 bit app. And EW's PLAY sampler (sample player) is native 64 bit. Sonar is already a 64 bit app. On top of that Nuendo 4 / Cubase 4.1 will be 64 bit apps, and are supposed to be released in the next couple of months.

If Apple really is waiting for Leopard to be released to announce Logic 8 (pure speculation) then it pretty much guarantees that L8 will be a 64 bit app also, as Leopard will allow apps to run in 64 bit address spaces.

So really, the future is kind-of here already if you're on a Mac, and shouldn't be that far off on Windows either...

[Nickie Fønshauge]

I'm counting on K3 to be a native 64 bit app, since samplers have the biggest need for memory. I read that Giga 4 will be a 64 bit app. And EW's PLAY sampler (sample player) is native 64 bit. Sonar is already a 64 bit app. On top of that Nuendo 4 / Cubase 4.1 will be 64 bit apps, and are supposed to be released in the next couple of months.
Yeah, if NI misses that train, they will soon find themselves surrounded by dinosaurs. What a shame that would be.

[dewdman42]

you guys are funny. Does nobody remember when XP first came out and a lot of people, particular those in the audio circles, were sticking with their tried and true Win2k? Eventually, the kinks in XP were ironed out and everyone fell that way. I was a late adopter myself, but in the end, when I finally transitioned over to XP, it was so much better, I could never look back.

Now, I'm personally going to be a late adopter of Vista also, but make no mistake, the kinks will get worked out and in a year or two we'll all be singing praises about Vista, never wanting to waste our time with the antiquated XP again, and many of us that have the hardware to support it will even be starting to play around with 64bit Vista. Me personally, if I bought a new machine, I would make sure the mobo is ready for 64bit, but I wouldn't invest in a lot of ram yet. Then I'd dual boot into 64bit windows to check it out and follow the progress.

The real holdback on 64bit is in the area of drivers and perhaps apps. MS does provide a utility that enables to you execute a "wrapped" 32bit app on 64bit windows. That will work fine for your average windows app, but I would never think of running audio software on that kind of setup. Of course you can always use Sonar64. But then what about VST's and such? I'm not really sure how Cakewalk addresses that issue. Clearly some of htem must work. I do not know if they address large ram yet or not. There are programming concerns related to this, so its not a garantee that just because you're running a program on a 64bit windows it will not automatically be able to handle the large ram, etc.. But...as more and more people move in this direction, then those software titles will be motivated to make sure their software is 64bit compliant. Beyond 5 years, I suspect Microsoft will drop 32bits and only support 64bits moving forward, so everyone that is making software for Windows should have this on their radar.

For us in audio, there are also driver concerns, you really need 64bit drivers. Some are available, some are not. But I think the audio world will actually be ahead of the rest of the world in terms of 64bit because we stand to benefit tremendously from increased RAM if nothing else.

[Steve_Karl]

Now, I'm personally going to be a late adopter of Vista also, but make no mistake, the kinks will get worked out and in a year or two

It's a whole new ball game with Vista.
When and if it ever becomes and upgrade ( as opposed to a downgrade in performance ) then we'll know about it.

I'm not going to hold my breath.

[kitekrazy]

It's a whole new ball game with Vista.
When and if it ever becomes and upgrade ( as opposed to a downgrade in performance ) then we'll know about it.

I'm not going to hold my breath.

It sure it is. Microsoft's anti piracy campaign is reflected more in Vista. Driver certification is a hassle. There is a lot out there in writing that many people are having problems with Vista.

I'm still keeping my eye on Linux. I wont switch to Mac because I build my own systems.

[Steve_Karl]

I'm still keeping my eye on Linux. I wont switch to Mac because I build my own systems.


Same here. If the Linux geeks get memory management up to snuff and someone writes 1 decent midi / audio app I'll be jumping the windows ship right then and there.

[Gamera]

When hosted in 64 bit Sonar, GVI will address 2GB of RAM per instance. I don't know about the other sample players.

- G

[JonFairhurst]

When hosted in 64 bit Sonar, GVI will address 2GB of RAM per instance. I don't know about the other sample players.

- GIs this true? Have you tried it? If so, cooool...

[MarkWherry]

I'm not sure 64-bit nirvana will exist any more than 32-bit nirvana. Working with 64-bit samplers on Window x64 just seems to bring up the same set of compromises between disks, memory, and processors. For example, the biggest advantage of a 64-bit sampler is to do away with disk streaming altogether, as this was simply a workaround for not having enough memory in the first place.

Disks really get in the way of things if you consider that a typical 7200rpm SATA drive will give you around 200 mono streams of audio, and most streaming samplers give you around three times the number of actual voices thanks to clever memory caching. So if you preloaded more instruments with the memory you have available in a 64-bit space, you still won't get more than about 600 voices per disk unless you start to cache more and more in memory, and then you might as well just load the whole instrument into memory. So, to have more polyphony with more preload memory, you'd have to buy more disks, although each additional disk won't give you a linear increase in polyphony, and this also means you have to balance the system load yourself in terms of which instruments play from which drive. (And RAIDs don't help because the seek time remains the same.)

While the idea of loading entire instruments into memory might seem wasteful, it's actually a really good idea as there's a good deal of optimisation that can be done if this is the case, especially for instruments with crossfading velocity layers where you no longer have to stream all layers simultaneously, as you have to with a disk. Also, it's worth noting that even if you load a large number of instruments into memory, there's no guarantee that your processor (or processors) will be able to provide enough polyphony for all the instruments you have loaded. For example, I have a four-core system with 8GB memory that's capable of around 1800 mono voices. But loading up long strings entirely in memory takes 6GB and usually peaks at around 1200 voices. So while there's a little bit of room left, generally I've found that there's a pretty easy relationship between instruments loaded and available polyphony.

So, not to be negative... But with sample libraries growing in complexity (and so size) all the time, I think that the one-computer solution is really unlikely unless you use very small instruments. A few years from now I suspect everyone will still have multiple computers, they'll just have 64-bit processors inside and a lot more memory! :-)

Mark.

[Steve_Karl]

Welcome to the forum Mark!

[howardv]

When hosted in 64 bit Sonar, GVI will address 2GB of RAM per instance. I don't know about the other sample players.

- G
I've been using GVI with 64-bit Sonar since last November and find that if I patch with LatTiDo, I can load a little over 3 gigs in one instance. But I only have 4 gigs total in my system. My guess is I'd probably get closer to 4 gigs if I had more ram to work with.

Howard

[JonFairhurst]

LatTiDo? I've searched it with one T and two, and I get "muchas páginas de Español". Got a link?

[Steve_Karl]

LatTiDo? I've searched it with one T and two, and I get "muchas páginas de Español". Got a link?

From the folks that gave us GigaTweak!

http://www.musikbanken.se/TechLaaTiDo.aspx

Laa ....

Thanks for the other good info Jon!

[howardv]

That's it. Sorry I messed up the name. In 64 bit sonar6, I use it to patch BitBridge.exe which seems to do the actual sample loading for 32-bit vsti's like gvi, k2, and jabb. If you used any of these standalone, then you'd need to patch the exe or dll doing the loading.

Howard

[Houston Haynes]

<rant from an aging hippy>

64 bit Nirvana .... smells to me like it's at least 5 yrs. in the future if even ever.

Vista is reported as being patheticly slow compared to XP when it comes to low latency performance.
</rant from an aging hippy>

Sorry - hate to steal your thunder, there...

VISTA performance (http://mtippach.proboards40.com/index.cgi?board=likelynotabugbutthereisaproblem&action=display&thread=1187205707)

Vista Performance Tests (http://rainrecording.co.uk/vista/performance)


There are two results that jump out at you from looking at the graph:

1. Vista outperforms XP without any trouble at all.

2. There's no performance advantage to Vista 64.

Please note that these results are for the quad-core system we tested with Cubase and the Fireface and should not be applied to every circumstance. Dual core, single core or systems of a different configuration may vary in performance results.


http://rainrecording.co.uk/images/vistawatch/vista-comparison-graph.jpg

[Gesticulator01]

The missing OS in the above graph is XP 64. That is the comparison I'd really like to see. Still its interesting that it outperforms XP32, according to their tests.

[Houston Haynes]

The reason why they don't see any performance advantages for V64 is because there's no software that's taking those advantages right now - at least in their tests... :)

[Steve_Karl]

Sorry - hate to steal your thunder, there...

VISTA performance (http://mtippach.proboards40.com/index.cgi?board=likelynotabugbutthereisaproblem&action=display&thread=1187205707)

Vista Performance Tests (http://rainrecording.co.uk/vista/performance)





It's not "my" thunder at all.

Sorry ... but I'm going to believe a few indipendent experienced builders than have personally done the testing, rather than a chart from an unknown source referencing "plugins" as a general term, and showing no definitions for the numbers associated with the chart.

[howardv]

Sonar64's been out quite a while and was made Vista compliant while V64 was still beta. And the concensus near as I can tell over on the Sonar forums is that it performs better on XP64 because the OS uses less RAM leaving the app more for itself. I use Vista64 at work and XP64 at home on nearly identical 4 gig ram machines and my impression is that Vista has more overhead and runs slower than my home machine. But I don't use Sonar64 at work so my own direct comparative experience is with 32bit apps doing things like encoding mp3's or dvd's on occasion on both. My impression is that no matter how you slice it, Vista's going to need more memory to break even with XP64. I have a feeling that it won't come into its own, even with more 64 bit apps, until more mobos can go beyond 8 gigs.

Howard

[Houston Haynes]

It's not "my" thunder at all.

Sorry ... but I'm going to believe a few indipendent experienced builders than have personally done the testing, rather than a chart from an unknown source referencing "plugins" as a general term, and showing no definitions for the numbers associated with the chart.

Dude - did you read the referenced article? Obviously not, by your comments. Rain Recording is no fly-by-night outfit. They also have re-posted one of Gary Garritan's articles for EQ Magazine on Vista and audio - you should read it, too.

[howardv]

Houston, their tests used an RME FF800 firmware driver v2.631 that had WDM buffer size issues under XP. They'd probably get wildly different results with the current v2.66 firmware. Not sure of the wisdom of drawing sweeping OS conclusions, however, from firewire saturation characteristics alone. I'm thinking about going to a Motu PCIe 424 for working with 32 or more tracks of 24/96 audio... you tried one of them by any chance? Only thing holding me back is I like RME and have been waiting for their HDSPe card to land.

Howard

[Houston Haynes]

Houston, their tests used an RME FF800 firmware driver v2.631 that had WDM buffer size issues under XP. They'd probably get wildly different results with the current v2.66 firmware. Not sure of the wisdom of drawing sweeping OS conclusions, however, from firewire saturation characteristics alone.
I'm not drawing any sweeping OS conclusions - I was countering a sweeping OS conclusion:



Vista is reported as being patheticly slow compared to XP when it comes to low latency performance.

I could care less what firmware/software/underwear version they're using, I'm just poking holes in someone's argument, which we all know is a great deal more fun (and easier) than making an assertion and proving it.

:D


I'm thinking about going to a Motu PCIe 424 for working with 32 or more tracks of 24/96 audio... you tried one of them by any chance? Only thing holding me back is I like RME and have been waiting for their HDSPe card to land.

Howard

I got tired of waiting for TASCAM to come up with a Vista driver for the FW-1884, so I just grabbed an in-line USB audio interface and the ASIO4ALL driver and went with it. It's interesting, I've gotten the same or better performance out of a USB audio device and generic driver (which actually uses the WDM stack) than what I saw from the FW-1884. There's a new ASIO4ALL driver out now that actually uses Vista's WaveRT layer, but I don't have the 32-bit OS on my machine. I'll either make a third partition on my main drive or I'll just wipe out my 64-bit install - not much there anyway - for now.

My point is that *anyone* can make any assertion so they can "set a table" and rant on in a discussion forum. But the truth is that there hasn't been enough work on pro audio drivers and applications for Vista yet - at least enough to be delivered into the field and tried out on the myriad hardware configurations that are out there. It's frustrating, because while Microsoft had public betas in the field for more than a year, most of the audio device and application manufacturers were dedicating a large portion of their resources to supporting MacIntel compatibility. But that's life in the world of business. Let's face it - by the state of the WaveRT driver at the time that Vista went RTM, it was pretty obvious that they weren't really serious about being pro-audio-ready in any case. MS was more interested in making sure you scanner/printer/web cam/mouse worked when you plugged it in.

So give it some time - how long have Mac users waited for MacIntel compatibility for pro audio apps and interfaces? It depended (and in some cases, still depends) on the vendor. It will be no different with Vista.

[Steve_Karl]

[quote=Houston Haynes]
I'm just poking holes in someone's argument, which we all know is a great deal more fun (and easier) than making an assertion and proving it.

At least you're honest about your motivation. :D

Now if we could just find a few actual real world success stories about Vista running with latency set at 1.5 MS and the same as, or more samples loaded, plugings, loaded, etc. we'd be accomplishing something.

One might think there would be actual end users sharing that information if it was happening.

[Houston Haynes]

At least you're honest about your motivation. :D

Now if we could just find a few actual real world success stories about Vista running with latency set at 1.5 MS and the same as, or more samples loaded, plugings, loaded, etc. we'd be accomplishing something.

One might think there would be actual end users sharing that information if it was happening.

I'm not motivated one way or the other, as far as this thread is concerned - I merely took exception to the blanket statements.

OTOH, to get 1.5 ms in and out will requires a pretty mature driver model. How many years did it take for these latencies to be achievable in XP - and were they ever achievable on a Mac?

The underpinnings of Vista are there to make such a thing possible (WaveRT and WASAPI) but my understanding is they've just recently gotten to the point of maturity that pro audio companies can really start leveraging them with a reasonably high degree of trust. Anyone that was at the Windows Vista Audio Summit last March will tell you that it took all of about one presentation to illustrate a gaping hole in the WaveRT API that made it essentially useless for pro audio (read: timing data). It seems that this might have been dealt with by now, but I think there's a pretty good reason why hardware driver support has been lagging.

And it gets more complicated - with MS now really clamping down on drivers and services that bypass their kernel. It all boils down to a slower, but in the end a more robust driver development model. That's why I think you'll see more companies just putting out class-compliant hardware that allows Windows to mount it and then use a generic user-mode ASIO driver (like ASIO4ALL) to handle the low-level stuff. Fortunately, MS saw fit to put the user mode layer very "close to the metal" and eliminated other things like user/kernel context switching that caused so many applications and drivers grief (i.e. Blue Screen Of Death). So the "primitives" are right - it's just a matter of companies putting the resources in place to get the drivers built and certified. After that, we'll probably see a few rounds of optimization - both in the drivers from companies, plus the API model from Microsoft. That's always the way it's been - and the way it will be for the foreseeable future.

[Steve_Karl]

OTOH, to get 1.5 ms in and out will requires a pretty mature driver model. How many years did it take for these latencies to be achievable in XP - and were they ever achievable on a Mac?


'dunno 'bout mac, but xp-sp1 was (and still is) 1.5ms right out of the box ~for me~ ... even with pretty old Gina24 drivers.

I really hope they get it happening.

[Houston Haynes]

'dunno 'bout mac, but xp-sp1 was (and still is) 1.5ms right out of the box ~for me~ ... even with pretty old Gina24 drivers.

I really hope they get it happening.


I guess you can check in when they release Vista SP1 then. ;)

[buzzripper]

I'm using x64 with great success right now. I run Cubase SX3 on XP Pro 32-bit on my main workstation, and Windows x64 w/6GB ram on my secondary machine for samples. I use Midi-over-lan and lightpipe between them. I load up and entire orchestra (VSL Special Edition) in V-Stack at about 1.9G, and all 4 VSL Chamber Strings instruments - the x2 patches at about 2.7G - Forte. Total memory used is ~4.5G and it works great.

I did all this in a single x64 machine, too (using MidiYoke for midi connections between the hosts), and it was great but I switched because Altiverb doesn't work in x64. And I gotta have my Altiverb. :D Absolutely everything else I have works in x64. The 64-bit drivers for my MOTU 828MkII and EMU 1820m both work great.

There's a lot of misinformation about 64-bit, but the main thing to remember is that 32-bit apps will run in x64, and they do have a limit of 4GB ram, but that's per instance. That's why I use both forte and V-stack, each one of them will handle up to 4G ram each.

I say give it a shot, works for me. If anyone is interested in more details, I'll be happy to share.

Robert Kooijman has done a ton of work in x64, he inspired me to give it a try. Here's a great thread where he gives all his details...
http://www.northernsounds.com/forum/showthread.php?t=51529


later...
buzz

[howardv]

Don't know if its this thread or maybe that there might be a whiff of 64-bit GS4 in the air somewhere. But I just ordered up the parts for a new 8-gig ram system based on an Intel 975BX2 mobo. Decided to spring for a Q6700 this time.

Howard

[JonFairhurst]

Don't know if its this thread or maybe that there might be a whiff of 64-bit GS4 in the air somewhere... I'm sure that there's more than a whiff of a 64-bit sampler in Austin/Montebello, but I have no idea when it will be announced/demo'd/shipped. After the GS3 experience, TascamGiga is silent when it comes to features and delivery dates.

BTW, I would expect GVI-Mac to ship before GS4, but that's just my guess. I don't have any inside info on either, so I have no beans to spill.

[howardv]

When I downloaded an RME Fireface update last month, I couldn't help notice mention of "64-bit GSIF support" in the readme. A Tascam guy later chimed in that it was for GS4. I'm ready!

Howard

[Andrew Aversa]

http://www.dawbench.com/blofelds-xp-v-vista.htm

A more objective look at XP vs. Vista, don't forget to read both parts. Very clear test procedures which are explained and outlined.

[JonFairhurst]

When I downloaded an RME Fireface update last month, I couldn't help notice mention of "64-bit GSIF support" in the readme. A Tascam guy later chimed in that it was for GS4. I'm ready!Very nice! I'm smilin' right now! )(~

What this tells us is, yes, GS4 will be 64-bits. (But we already knew this, didn't we?) It also tells us that GS4 will almost certainly use a kernel-level interface to the audio card. No telling how much of the sampler will be at the kernel-level though.

Another thing it tells us is that the 64-bit GSIF spec is not only defined, but delivered to manufacturers and implemented. This is HUGE. It means that they've slayed a big part of the 64-bit dragon.

What it doesn't tell us is when GS4 will ship, what its features will be, or what its performance will be.

Hmmm. I might just be ordering a Fireface with my next system...

[JonFairhurst]

http://www.dawbench.com/blofelds-xp-v-vista.htm

A more objective look at XP vs. Vista, don't forget to read both parts. Very clear test procedures which are explained and outlined.Ouch!

For those who lack the time to read the articles, here's the author's bottom line conclusion: Stay far away from Vista for pro audio - for now. Maybe that will change in 2008...

[clonewar]

Very nice! I'm smilin' right now! )(~

What this tells us is, yes, GS4 will be 64-bits. (But we already knew this, didn't we?) It also tells us that GS4 will almost certainly use a kernel-level interface to the audio card. No telling how much of the sampler will be at the kernel-level though.

Another thing it tells us is that the 64-bit GSIF spec is not only defined, but delivered to manufacturers and implemented. This is HUGE. It means that they've slayed a big part of the 64-bit dragon.

What it doesn't tell us is when GS4 will ship, what its features will be, or what its performance will be.

Hmmm. I might just be ordering a Fireface with my next system...

The real question is whether or not sample library developers will start supporting GS again. The available libraries have really dried up. I'm sure that besides 64 bit support GS4 will have a more advanced scripting engine to compete with Kontakt.

I'm sure that NI knows about GS4's 64 bit abilities, which should be pushing them to make K3 a 64 bit app also.

[Steve_Karl]

http://www.dawbench.com/blofelds-xp-v-vista.htm

A more objective look at XP vs. Vista, don't forget to read both parts. Very clear test procedures which are explained and outlined.


Good find Andrew!

Thanks,



S

[Robert Kooijman]

I've tried really hard to get Vista X64 working decently with Cubase 4, but without success.

At lower latencies, XP Pro X64 is simply more stable, gives less clicks / pops, and uses less RAM. So yes, I can only second the conclusions of Vin Curigliano. Sad thing is that Steinberg only supports Vista X64 with forthcoming Cubase 4.1. But I wouldn't be surprised if it works better on XP anyway ;)

[TAFKAT]

Hey All,

For those that don't know me by my TAFKAT Alter Ego, I am Vin Curigliano, the author of the recent XP v Vista reports that some of the guys here have posted about.

First of all I'd like to say that it is quite refreshing to see such a positive response to my efforts here. I have to say
that the response on some other forums has been somewhat hostile , simply because I have not jumped onto the Vista Band Wagon, instead offering objective and easily quantifiable results to my testing.

I find it interesting that Rains report is still being posted as representative of Vista Audio performance over XP..

For all intensive purposes, it has been proven to be flawed, as have their conclusions in regards to explaining the performance delta.

It is in direct conflict with all other reports from Pro DAW builders and Audio / Software manufacturers.

Sound On Sound did a recent article where they gathered all of the name players in Audio Software / Hardware.., apart from some expected hyperbole from the Cakewalk camp, it was pretty clear where everyone else sat.

Now considering that the Audio Interface used on the Rain testing was an RME Fireface 800 , you would think that Mathias Carsten from RME would have been crowing from the rooftops if their Vista drivers had delivered a 60-100% improvement over their respective XP driver implementation. Instead he reported the opposite , that performance under Vista is not as good as XP , which co-incides with my findings.. :-)

Anyhow,

Sorry for the vent on my first post.. :-(

I digress,

I thought I would add my 2 cents in regards to the shift to x64.

This has definately been a long time coming, and the transition is not going to be as smooth as most would hope.

Anyone who has experienced the performance hit using the SONAR bitbridge is well aware that the concept is far from ideal. The real advantage of x64 will only take place when all the VSTi's and Plugins navigate across to native x64 , and that is not going to be anytime soon.

Steinbergs upcoming native x64 releases, will also employ a "Bitbridge" of sorts , where all 32 bit VSTi's, Plugins will
run within a single 32 bit application - i.e : Bitbridge/ Wrapper . The VSTi's will still be reserved to using a 2 GB memory address space , only Native VSTi's/PlugIns will be able to take advantage of the 64bit memory address space - ( many will be surprised to know that both Intels and AMD x86 spec only has support for a 40 Bit memory address space - which allows memory access to 1TB - more than we will ever physically achieve, so who's counting )

Also , for those thinking of making the jump to an X64 O.S, despite the Non Official support , I'll be very surprised if
the Steinberg x64 applications do not perform better under XP x64 than Vista x64 initially. I don't hold a lot of merit in the "Multimedia Class Scheduler Service" that Cakewalk have already implemented in SONAR, and Steinberg have reportedly utilised in N/C 4.1.

Then again the apps could also be highly SSE4 optimised as well, which lean it back to Vista , but will also mean a chip upgrade will be required..

Aghhh, it just keep getting better.. LOL

Peace

V:

[Tobias Erichsen]

> Steinbergs upcoming native x64 releases, will also employ a "Bitbridge" of sorts , where all 32 bit VSTi's, Plugins will
> run within a single 32 bit application - i.e : Bitbridge/ Wrapper . The VSTi's will still be reserved to using a 2 GB memory address space ,

I doubt that this 32bit wrapper application will be limited to 2GB, I would rather think that this application has the "large address aware" option
set, so depending on the OS one could use either 3 or 4 GB...

> then again the apps could also be highly SSE4 optimised as well, which lean it back to Vista

Well applications optimized for SSE4 running under XP will also profit... so I guess Vista won't have any advantage in this respect ;-)

Tobias

[Steve_Karl]

Welcome aboard Vin!

Thanks for doing what you do!

[TAFKAT]

>
I doubt that this 32bit wrapper application will be limited to 2GB, I would rather think that this application has the "large address aware" option
set, so depending on the OS one could use either 3 or 4 GB...
I stand corrected,

32 Bit applications access the full 4GB under an x64 O.S.. :-)


Well applications optimized for SSE4 running under XP will also profit... so I guess Vista won't have any advantage in this respect ;-)
Hmmm, good point..

I was trying desperately to shine some light on Vista.. , and ya just flicked the switch.. LOL

Peace

V:

[JonFairhurst]

Depending on the limitations in the kernel space, I wonder if GigaStudio might have a big advantage over other solutions - at least for a year or so.

While VSTis depend on lots of infrastructure, GS4 and GSIF64 could potentially bypass all things MicrosoftAudio and go directly from the Kernel app to the soundcard.

Of course, this is just conjecture. We won't know the score until we get our hands on it and test it.

BTW, Vin, thanks for your input. I like where you're coming from. We want Vista to succeed with audio, but we want more than to just throw around the 64-bit number. We want measured performance improvements.

With the size of the PC music market, and the fact that 64-bits (OS) has been on the market for months and is the default on every new PC sold, I'm surprised that things are still so slow...

[germancomponist]

With the size of the PC music market, and the fact that 64-bits (OS) has been on the market for months and is the default on every new PC sold, I'm surprised that things are still so slow...

Oh yes, me too.

Perhaps they think: Let`s wait what the industrie will built the next days.... . Or are they only sleeping? I think no... .:D

[howardv]

Been playing with implementing an 8 gb system this week on XP64 and its been more bumpy installing than Vista64. For one thing I had to knock down to 4 gb during the xp64 install to make it go. Had the same issue loading flash chjipset updates... they apparently uses a Linux kernel during the install which also gets confused by too much memory. But for now I'm sticking with XP64 which seems solid as a rock and pretty brisk once it and Sonar64 are installed.

Haven't had a chance to test a patched BitBridge on the 8 gb system but I have no doubt it'll load up 4 gb of vsti's. I was getting about 3.3 gb loaded on a 4 gb system. Looking forward to my first 64bit vsti and expect it'll be gvi or gs4. Whatever comes first, I suspect a flood of them will follow.

I also was pleased to find out that Sweetwater just got in one of RME's new PCIe boards which they're selling for about $400. Now that's a good candidate for testing Vista64 against XP64. I think the Motu PCIe card also has both 64-bit drivers out too. But I'm hoping to get by with my firewire ff400 and 1884 units till I save up a few more nickles.

Howard

[JonFairhurst]

Keep us posted Howard.

BTW, I told my son that he gets my old PC when I upgrade to a 64-bit ground up system. Now he's more anxious to get 64-bits than we are!

[germancomponist]

Keep us posted Howard.

BTW, I told my son that he gets my old PC when I upgrade to a 64-bit ground up system. Now he's more anxious to get 64-bits than we are!

Whats about 128-bits? :D

How many bits did the computers have from the american NASA for the first moonvisit? ;) 1, 2, 4, 8...? :)

[TAFKAT]

Hey All,

I thought I'd drop by and give you all a quick update ..

It has been confirmed that the Vintage Channel Plugin VC-64 that I used in the recent SONAR x64 / Vista x64 report - is not x-64 Native, ( Go figure - a plugin called VC-64 is NOT Native x64 ) and that the results are reflective of the performance penalty imposed by the Bit Bridge.

The Test session is currently being revised with x64 Native Plugins only, and I'll rerun the tests and update the performance data in Part III.

I will also detail the looming minefield of navigating the Bit Bridge and other variations of the same theme

Peace

V:

[JonFairhurst]

TAFKAT,

I'm looking forward to reading your results. Good luck to running a smooth and accurate test.

[Steve_Karl]

Yes. Thanks for being so conscientious and persistent. )(~

[TAFKAT]

Hey All ,

Just a quick update..

First off, the guys over at the Cakewalk forum did a great job on revising the bench, ensuring that all of the plugins have native x86/x64 versions - the Sonitus Multiband Plugin used as the back breaker is definately far hungrier than the V-Channel, which is a good thing as the V-channels were not really challenging my Dual Quad.. :-)

Test will be available from the DAWbench site for download shortly..

O.K,

Here are the numbers..

-------------------------------------------------------------------------------------------

SONARbench DSP R2 : Core2Quad QX6700 @ 2.66 GHZ : 1066 FSB : Sonar 6.2

Motherboard : i975

Memory : 2 GB - XMS 6400 @ PC6400 - 800 MHZ : Standard Timings by SPD :

O.S : XP SP2 :

Lynx 2 : Driver : V2 Build 14

256 Samples - 72 Multiband Comps / Save-ReOpen 72:

128 Samples - 57 Multiband Comps / Save-ReOpen 57:

064 Samples - 34 Multiband Comps / Save-ReOpen 34:

032 Samples - No Go from the Get Go :

----------------------------------------------------------------------------------

SONARbench DSP R2 : Core2Quad QX6700 @ 2.66 GHZ : 1066 FSB : Sonar 6.21 x64

Motherboard : i975

Memory : 2 GB - XMS 6400 @ PC6400 - 800 MHZ : Standard Timings by SPD :

O.S : Vista64 Bus:

Lynx 2 : Driver : V2 Build 14 / ASIO

256 Samples - 57 Multiband Comps / Save-ReOpen 57:

128 Samples - 33 Multiband Comps / Save-ReOpen 33:

064 Samples - No Go from the Get Go :

032 Samples - No Go from the Get Go :


-------------------------------------------------------------------------------------------

SONARbench DSP R2 : Core2Quad QX6700 @ 2.66 GHZ : 1066 FSB : Sonar 6.2

Motherboard : i975

Memory : 2 GB - XMS 6400 @ PC6400 - 800 MHZ : Standard Timings by SPD :

O.S : XP SP2 :

RME HDSP 9632 : Driver : V3 Build 5 / ASIO

256 Samples - 72 Multiband Comps / Save-ReOpen 72:

128 Samples - 56 Multiband Comps / Save-ReOpen 56:

064 Samples - 34 Multiband Comps / Save-ReOpen 32:

032 Samples - No Go from the Get Go :

----------------------------------------------------------------------------------

SONARbench DSP R2 : Core2Quad QX6700 @ 2.66 GHZ : 1066 FSB : Sonar 6.21 x64

Motherboard : i975

Memory : 2 GB - XMS 6400 @ PC6400 - 800 MHZ : Standard Timings by SPD :

O.S : Vista64 Bus:

RME HDSP 9632 : Driver : V3 Build 5 / ASIO

256 Samples - 58 Multiband Comps / Save-ReOpen 58:

128 Samples - 33 Multiband Comps / Save-ReOpen 33:

064 Samples - No Go from the Get Go :

032 Samples - No Go from the Get Go :

-------------------------------------------------------------------------------------

I have cross referenced the results between the RME and Lynx cards, just to get that variable out of the way from the get go. As in my previous results with R1 , the results between the 2 cards is within 1-2 plugins across both XP and Vista, so we have maintained good consistency with the previous benchmark.

Behaviour under Vista 64 was smoother this time, but the results are still way below what I was expecting with the BitBridge eliminated out of the equation.

So this definitely raises the question on what exactly is going on.

We have now eliminated the Bitbridge as the variable , which leaves the combination of the X64 Application / x64 O.S

I am not interested in exploring SONAR x86 on Vista x64, simply because it defeats the purpose of the exercise , which is to have a direct comparison of a Native x86 application on XP32 , and a native x64 application running under Vista x64 - the O.S that it is touted as being developed and optimised for.

I have been in direct contact with Cakewalk in relation to the issues raised in the first round of testing, and I know that my concerns have been passed on to numerous members of the dev team, who have still not bothered to reply.., maybe this second round will wake them from their slumber.. :-)

Either way ,

This is now looking like the issues encountered on the first bench were only partly related to the Bitbridge , and that the variable is indeed directly related to SONAR x64/ Vista x64

Can anyone say.. Can of Worms.. :-)

Peace

V:

[Steve_Karl]

Thanks Vin.

Just in case you've ever checked ....
What's your take on the difference between ..... um. .... lets say ....
Sonar 4.0.2 and Sonar 6x as far as performance.?



.

[howardv]

Hi, Vin. Just waded through the Cakewalk forum thread on this and downloaded the DSPR2beta test file but couldn't get to the instructions without a registration.... could you just cut and paste them here? Any open forum would do. Or maybe just drop them into the rar? I could then publish some numbers for some of my XP32 and XP64 systems.

Also what does this result mean?
256 Samples - 72 Multiband Comps / Save-ReOpen 72:

I assume it denotes using a buffer size of 256 but is that a maximum number of 72 tracks before popping? Or perhaps an export time of 72 seconds?

Howard

[Daryl]

Multiband Compressors, I think........

D

[James Thornton]

Although I'm certainly not thrilled with the reported numbers, for my application the critical factor is memory and not so much CPU; so the comparison is really 8 Gb under Vista versus 2 Gb under XP with everything else the same. Factoring that into the equation my main concerns are less about performance and more about how long till Cubase and my favorite VSTs are 64-bit and how long after that until they're not too buggy.

Cheers,
James

[TAFKAT]

Hi, Vin. Just waded through the Cakewalk forum thread on this and downloaded the DSPR2beta test file but couldn't get to the instructions without a registration.... could you just cut and paste them here? Any open forum would do. Or maybe just drop them into the rar? I could then publish some numbers for some of my XP32 and XP64 systems.

Also what does this result mean?
256 Samples - 72 Multiband Comps / Save-ReOpen 72:

I assume it denotes using a buffer size of 256 but is that a maximum number of 72 tracks before popping? Or perhaps an export time of 72 seconds?

Howard


Hey Howard,

Instructions are actually in the session notes when you first load the session.. :-)

The results denote number of added multiband comps loaded on top of the plugins already in the template , the ReOpen figure is the number of plugins that the session would successfully playback with after saving and reopening the session.

That second value stems from a lot of research I have done over the years where there was an issue reloading and playing back heavily loaded sessions , requiring some plugin load to be eliviated before the sessions would playback successfully again. This happens across multiple applications.

I am happy to report that the issue is diminishing with the latest ASIO drivers, especially with RME , that suffered from the issue more so on the 2.9x drivers.

Peace

V

[TAFKAT]

Thanks Vin.

Just in case you've ever checked ....
What's your take on the difference between ..... um. .... lets say ....
Sonar 4.0.2 and Sonar 6x as far as performance.?

.

Hey Steve,

Haven't done any comparative testing with previous versions of SONAR , sorry Mate..


BTW: Is it just me, but a few times that I have tried posting here, I have to post twice before the post appears, and then I have to go and delete the duplicate.., its very strange.., given I use the exact software on my own forum, and know it quite intimately, I am wondering if anyone else has encountered the issue..?

Peace

V:

[JonFairhurst]

I'm in the same boat as James. Lots of effects are nice, but I generally group things into busses, apply the effects there and keep things running smoothly.

I'm interested in a 64-bit sample engine. The key factors are:
* Available RAM
* Low latency
* High polyphony (this might scale similarly to the # of effects)
* High reliability

I happen to be a Sonar user, and a Giga user. Once those two tools can load up a bunch of 64-bit addressed RAM, I'll be a happy guy.

Oh, I also have Appassionata. I'd prefer it if it ran in Giga, but that ain't gonna happen. So, I'd like the system to run 32-bit VSTis and well.

[TAFKAT]

Hey All,

It was requested by some of the Cakewalk community that I cross reference my Vista x64 with XP x64, just to dot the i's..

O.K , here are the XP x64 numbers with the Lynx Card only , I really couldn't be bothered cross referencing the RME card this time, I think I have already proven that the audio cards are not the variable here.

--------------------------------------------------------------------------------------------

SONARbench DSP R2 : Core2Quad QX6700 @ 2.66 GHZ : 1066 FSB : Sonar 6.2

Motherboard : i975

Memory : 2 GB - XMS 6400 @ PC6400 - 800 MHZ : Standard Timings by SPD :

O.S : XPx64 SP1 :

Lynx 2 : Driver : V2 Build 14

256 Samples - 58 Multiband Comps / Save-ReOpen 58:

128 Samples - 36 Multiband Comps / Save-ReOpen 36:

064 Samples - * Go , but 0 Multiband Comps *

032 Samples - No Go from the Get Go :

-----------------------------------------------------------------------------

Performance is about on par to Vista 64, except the system felt way more responsive, also at *064 samples the session template would actually playback, but as soon as I tried to turn on 1 MBC, it tanked * .. :-(

So its not only SONAR x64 / Vista x64 tanking, its also XP x64.., so congratulations Cakewalk , its the application itself thats tanking on the x64 O.S's..

Lets put this into perspective.., my testing with the 32 bit Steini apps showed a performance hit using both XPx64 and Vista x64 over XP32, but the performance hit was not really tangible until we got into the lower latencys below 128 , however we are already seeing a 25% hit at 256 here, and a 75% at 128..

I suspect that SONAR x86 would perform much better on the x64 O.S's, but I refuse to even entertain going down that path with this project , simply because that is not what we are trying to achieve, and that is a native x64 DAW , something that Cakewalk have been screaming from the rooftops for quite a while.

The other thing that is highlighted here is that the much touted Multimedia Class Scheduler Service optimisation has not amounting to anything past hyperbole.. Surprise .. :-(

Lets hope the Cakewalk Devs find the time and energy to get involved in the ongoing discussion here, and give some insight into what we are experiencing..

Should I hold my breath ? :-)

Right now, I am logging off for a while , its the weekend , its an awesome sunny day outside, and I am going to sit out in the sunshine with my 4 month old son , and actually get back to something far more important... :-)

Peace:

V:

[Steve_Karl]

Hey Steve,
BTW: Is it just me, but a few times that I have tried posting here, I have to post twice before the post appears,
V:

Forum posts ... Hummm .. never happened to me.
Sometimes I'll loose one but never had to do twice.

[howardv]

Hi, Tafkat. Thanks for the info. I'll try run some numbers later today. I don't have the same interfaces as you but I do have a FF400. Also, like Jon and James, I tend to bus everything and only connect to an audio port on the master out. Though I do use the spidif in for audio recording. And occasionally spidif in/out for inserting and freezing hardware effects. Additionally, I'm using allot more ram with xp64 than you seem to be. I can run some numbers with 2, 4, and 8 gigs and see if that makes any difference. I'm still waiting for more drives for my newer 975bx2 mobo with the q6700 in it but I can borrow its 8 gigs of ram easily enough and throw them into my older 975bx workhorse.

I can tell you that I've been running Sonar64 on a 4 gig E6700 oc'd to 3.1 ghz in a 975bx mobo for almost a year now and there's no comparison with my older 2 gig p4p800 2.8 ghz p4 with 2 gigs ram running xp32. I'll run some numbers on that too. Which for me would represent a sanity test for the benchmark.

Howard

[JonFairhurst]

Howard,

Please remind me which sampler(s) you're running...

Thanks!

[TAFKAT]

Hi, Tafkat. Thanks for the info. I'll try run some numbers later today. I don't have the same interfaces as you but I do have a FF400.
Hey Howard,

Thanks Mate, the more results , and wider cross reference with audio interfaces the better..

BTW: The amount of RAM is not going to make any difference on this particular test , as it is not actually hitting memory very hard at all.

I'll be interested to see if the old PIV rig will even run the template... :-)

Peace

V:

[howardv]

Hi, Jon. I run gs3 on my win32 machine... only reason I keep it around. Run gvi, k2, and standalone ni instruments like jabb on the xp64 machine. And I verified tonight that I can in fact get a little over 7 gb of samples loaded with separate instances of gvi and/or k2. But right now the project I'm working on is more straight-up 88.2k / 24-bit audio.

Ran some stuff and it was definitely interesting.

Well, you're right, tafkat, about the p4... couldn't get much of anything to run on it unless I deleted all the sine wave tracks.

On the 975bx, the maximum # of multi-band compressors I could add were:

SONARbench DSP R2 : Core2Duo E6700 @ 3.04 GHZ : 1066 FSB : Sonar 6.21

Motherboard : Intel 975XBX

Memory : 4 GB - PC2 5400 SPD 5-5-5-13 @ 667 MHZ

O.S : XPx64 SP2 :

FF400 : Driver v2.75 hardware v1.63

256 Samples - Sonar32: 51 ; Sonar64: 44

128 Samples - Sonar32: 38 ; Sonar64: 35

096 Samples - Sonar32: 30 ; Sonar64: 27


Also:

Memory : 8 GB - DDR2 6400 SPD 5-5-5-12 800 @ 667 MHZ

O.S : XPx64 SP2 :

FF400 : Driver v2.75 hardware v1.63

256 Samples - Sonar32: 49 ; Sonar64: 42

128 Samples - Sonar32: 35 ; Sonar64: 33

096 Samples - Sonar32: 25 ; Sonar64: 22

Unfortunalely I don't have an XP32 dual boot on this box. So the SOnar32 and Sonar64 were both run under XP64.

It's odd that the lower number of mbc plugins possible under Sonar64 compared to Sonar32 above doesn't relate to my normal Sonar usage experiece. I tend to stay away from Sonar32 when doing recording sessions because I've had better luck with Sonar64. Guess its apple and oranges.

Another thing I noticed when running these tests was how sensitive they were to video performance and how insensitive they were to disk i/o performance. Not sure what to make of that. I ran them on both a 2-disk raid 0 sata array as well as a stand-alone stata drive and noticed I could load only 1 less mbc plugin when using non-raid. My everyday experience is that raid normally makes a bigger difference than that.

Also, I got wildly variable results using different zoom settings with an open track window. I ended up minimizing the track window to get more consistent and repeatable results. I'm using an Asus nvidia en7300le for video... mainly because I didn't want another board with a fan on it. I have the idea that a higher powered video board might make a difference if you need to work with the track window open. Cakewalk used to recommend lowering video performance settings... might still apply.

Another thing that struck me was how much harder it was under Sonar32 for me to detect the pops as staturation was approached. They seemed to creep up and I was often unsure if I was perceiving them or not. Under Sonar64, there didn't seem to be any pops or crackle... it was either perfectly clean or audio stopped all together. I think I prefer this type of behavior.

You're also spot-on about running with 8 gb ram. In fact, it loaded fewer plugins. I'll have to see how the results compare with the q6700 running in the 975bx2 when I get that more together. At least that board will run the ram at 800 mhz.

Btw, there was an over at 25:22 causing a pop not related to performance... needed to throw a clip volume envelope on track #6 and notch the guitar hit there down by 1.5 db.


Howard

[TAFKAT]

Hey Howard,

Thank you so much for you time and energy, much appreciated.

Can you please post that over at the SONAR forum as well, I am sure that the membership there would be very interested in you experiences with SONAR x86 and X64 on XPx64.

Thread is Here (http://forum.cakewalk.com/tm.asp?m=1090789&mpage=1&key=&#1090789)

The differences are definately not as pronounced as what I have reported with SONAR x86 on XP32 , and SONAR x64 on XP x64, so we definately have another area of discussion opening up..

Also, your Overclocked DualCore results are rivaling my Quadcore results on XPx64.., Go Figure.., so SONAR's x-scaling on the 64 Bit O.S's seems to be another issue as well judging by those numbers..

Peace

V:

[howardv]

Just did the cross post. I haven't been able to oc the q6700 as aggressively... only got to 2.81 ghz. Hoping the extra cores and faster memory ability make up for less ghz.

Howard

[germancomponist]

Why is this progress sooooo slow....?

Do I have to buy a Mac? :-)

[Gesticulator01]

Why is this progress sooooo slow....?

Do I have to buy a Mac? :-)
Yep - the $64,000 question, or thereabouts. I might start a thread asking for advice about how to go about making the change. (software compatibility, etc).

I dont want to have to change.

But they do look nice.;)

[Daryl]

Why is this progress sooooo slow....?

Do I have to buy a Mac? :-)
What would that achieve? There is no 64bit OS on Mac, where there are two on PC.

D

[Gesticulator01]

What would that achieve? There is no 64bit OS on Mac, where there are two on PC.

D What would it achieve? Well i dnt use a Mac so these are 2nd-hand observations, but:
1. I believe you can comfortably use 16G on a mac dual core and,
2. macs are ahead on core processor technology, and also on chip speed within those cores, and on heating issues.

**None of the above is supposed to be any sort of gospel, just impressions i have based on some forum reading. ** Glad to hear what users say.

I'm surprised if thats correct that there's no 64OS on Macs.
I assume its safe to have a relevant discussion about this here without it getting into some mac/pc nerd war.;)

[Daryl]

There are so many caveats with what you say that I don't know where to start.

However, the most important thing is that whilst applications are 32bit, most will be limited to 4GB of RAM, even in a 64bit OS. I believe that Logic can just about scrape 3GB before weird things happen, so using the rest of the available RAM has to be done with standalone versions of whatever you are loading. I can comfortably load 7.5GB of samples on my XP64 machine with the same trick, and if I had 16GB loaded am confident that I could load 15.GB, so there is no advantage there.

Macs are now using PC hardware, so whilst it is theoretically true that the fastest processor on Mac has faster than that currently available for Windows machines (due to a special relationship with Intel), I don't know of any Mac music applications that can make use of all 8 cores, scaled properly in these machines, so it is not of much use.

Currently Mac doesn't solve anything in the 64bit game and whilst Leopard, when it is released, if it works, is supposed to answer this one, the real test will be for the software developers and the hardware manufacturers to see how quickly they can get their drivers out.

D

[germancomponist]

Hm, I am not safe me whether I absolutely need a 64 Bit system, but I want to use 16 GB or more Ram....... .

[Robert Kooijman]

Well then you *do* need a 64 bit system (OS) :)

[Gesticulator01]

Well then you *do* need a 64 bit system (OS) :)
Forgive me - I must be missing something here - but how is it you can run 16G on a mac if they have no 64bit OS then?

[Daryl]

Forgive me - I must be missing something here - but how is it you can run 16G on a mac if they have no 64bit OS then?
OSX memory handling is different to XP. You are still limited to 3 or so GB of RAM within any one application. Theoretically it should be 2GB, but like in XP there are various things that can be done to make programs use more. Logic is one of these that can use around 3GB.

D

[germancomponist]

Logic is one of these that can use around 3GB.

D

Cubase too :)

[TAFKAT]

Hey All,

Just a quick one to inform you that I have uploaded Part III of my XP v Vista Series, which has all of the latest round of testing , as well as all of the fun of the fair..Here (http://www.dawbench.com/blofelds-xp-v-vista3.htm)

Peace:

V: