64 Bit Scope Drivers

[ReD_MuZe]

Indeed 64bits is faster for 64bit data types.
still potential to be fast applies to anything software....

I agree that 64bit FLOAT is potentially better than 32bit FLOAT. But that has very weak link to this 64bit architecture hype.

float, integer, signed , unsigned, it doesnt matter.
Basicaly what interests guys like us is not how fast windows is working generaly but specificly but how efficient the DSP algorithms are working... this is the part that is the most cpu intensive.
and this has a BIG impact specifically on DSP.

So no adavantage when not the entire chain is 64bit.

this is totally untrue. the audio chain can be 24bit for all i care, as long as the filters internals are calculated in double precision data types (can be float integer or your own arithmetics doesn't matter).
you don't need a data consistent chain to enjoy faster and more precise algos.

Sounds familiar ?!
You can have 192kHz ADDA converters, but if your mastering is 48kHz.....

yet another audio voodoo (originated in a confusion between data integrity and audio quality). if you want u can open an entire thread for that one , i promise to prove it out of existence....

So no (recent) benchmark shows any real advantage of 64bit architecture and OS, but only for optimized (tailored) SW for 64bit.

for most software its just a matter of doing some replaces, and compiling differently. no need to taylor software that is already running on 64 bits. even sse based algos dont need anything else than a 64bit os, and fresh compilation to work faster.

64bit architecture+OS+Application, when available, is the (far) future and will come.
In the meantime I take my fast 32bit train

yep for you windows-only users it is unfort....
flexor has made the transition to 64bits for mac several weeks ago, and well. there is a BIG difference.
and indeed, we are not sure if we should start supporting 3 more windows versions nobody uses. perhaps this is why windows is lagging so far behind on the 64bit issue

[astroman]

...leopard is true 64bits from the ground up. ...

sure it is...
reminds me on the dude editing a 3 pages business contract on his Macbook Pro.
Word had just hung itself with 1.5 Gigabyte of physical mem allocation an 3.5 of the virtual stuff... LOL

all IT pros and cons aside you first got to be able to handle it at all (from the developer's side)
and I swear (after watching the major players > 20 years)
none of them actually can
be it Adobe, Apple or M$

btw 'they' want 64bit (data width) to get rid of the FPU - makes things cheaper to produce
also avoids mode switching of the CPU - makes things faster, something to tell your customers
that way things will be completely incompatible
people HAVE to buy NEW stuff - great, that what it's all about anyway

cheers, Tom

ps: hopefully this doesn't come over as a big portion of negativity, it's not meant that way
I am sarcastic about the issue, tho - but I can stop it immediately if someone explains how you can deal responsibly with 2 billion lines of code, which I estimate the minimum for a typical OSX or Vista Office machine.
Sorry to kind of ignore the musos part in this context, but us hardly counts in that type of business.

Open Source isn't my cup of tea, but I wouldn't deny a Linux based 'custom OS' approach may be the best possible choice to performance and reliability.
But I truely mean custom, not that faking stuff most distributions are about

[ReD_MuZe]

yawn,

if someone would keep compatibility you can say they do it to eat cpu resources and make more money by selling more cpu, and if someone wants to ditch compatibility you can blame them for wanting people to buy new software.

its all cheap demagogy.

you can make a bamboo flute for free and make music without paying a dime to anyone.
its your choice to make music with high-tech, and part of the high-tech game is making better and faster stuff, and also upgrading your pc every 4 years. big deal.

[astroman]

agreed - it is cheap demagogy you're fooled by
Red, I have seen people work in DTP on 32MHZ machines, and the same folks have 3 GHZ now
that is a factor of 100, but it delivers at best an improvement of 10
which is in my humble calculation a waste of 90% of the resources. Period.
In other words, they couldn't even get 32bit 'right' and now they are telling 64bit is a must
Pardon, for what kind of improvement ?

cheers, Tom

[Warp69]

................as long as the filters internals are calculated in double precision data types (can be float integer or your own arithmetics doesn't matter).
you don't need a data consistent chain to enjoy faster and more precise algos.

Well........... It's true that 64bit has higher precision than 32bit and therefor is better, BUT

Unfortunately most (read above 95%) digital filters are using Direct form and even 64bit FP causes significant error energy in the low frequencies - the Direct form is so noise sensitive at low frequencies that even 64bit can't save it.

You could achieve much highter quality with 32bit if you implemented trunc. error feedback, Parallel balanced/MRN realization etc. compared to 64bit Direct form.

Or began to explore zero delay feedback filters.

All of the above would ofcourse benefits from 64bit, but you could easily improve (much more than just the quality jump you get from 32bit to 64bit) the current state of digital filters without 64bit.

[ReD_MuZe]

stardust - i dont think there will be any improvement n sound quality for most software that "converts to 64" unless you see something like "new internal 64bit engine" in the feature list.

astroman - i don't know all the nooks and crannies of a pc, nor do i want to. for me its just about updating my pc every 4 years, and keeping up to date with technology nothing more, nothing less. I dont care for photoshop.

i know what ur saying, and its all convoluted inside, but what isnt?
nothing is perfect. but i tend to look at the full half.

so, as far as im concerned, they got it right. im making music and loving it more each year. the small details, and all the bitterness, i leave to them.

Warp69 - indeed but then it wouldn't sound the same. 64bit dsp just means more options. and more filter topologies one can implement. and here again i must emphasize the difference between data integrity and sound quality.

[valis]

There's a lot of talking at cross purposes here. '64bits' can have several meanings, in the current usage in the computer industry it's referring to the amount of memory space (addressing space) the OS's kernel can address (the size of the register set). The x86-64 (aka EMT64) extensions were to allow addressing larger memory spaces, increasing the generalized register set in the x86 architecture that's used for memory pointers to a 64bit space. These register extensions can of course be used for other purposes, such as stuffing 2 32bit INT values into them or a single 64bit INT for calculations etc.

Apple has long touted '64bit' as if it gave an aura of superiority (first because "Altivec" allowed 64bit "SSE" style optimizations, then later because the G5 had "64bit" support in its generalized registers as well). The problem is that this is marketing kerfluffle, and somewhat misleading. Apple took some steps forward to a fully 64bit OS with the G5/PowerPC series, but then had to step back a step with the first Intel machines they released (using core1 series 32bit only cpu's). With the later Intel cpu's x86-64 (EMT-64) support allowed Apple to move forward again, and Tiger became the first OSX OS to run 32bit & 64bit apps alongside each other, although with some caveats.

While Cocoa apps (hooked into the UI), some background apps and some of the Unix underpinnings are now able to support '64bit' in OSX Leopard (10.5), the kernel itself is still a 32bit kernel with added 64bit support. Ie, in both 10.4.x and 10.5.x OSX is running a 'hybrid' kernel (32bit native with support for 64bit extensions able to be enabled on specific processes):

Currently, Mac OS X Leopard hosts both 32-bit and 64-bit apps on top of a 32-bit kernel (below). Using PAE, the 32-bit kernel can address 32GB of RAM in the Mac Pro and Xserve; Apple's consumer machines only support 4GB RAM, but unlike 32-bit operating systems they can use the entire 4GB (with appropriate hardware support). Leopard's 32-bit kernel enabled Apple to ship 64-bit development tools to give coders the ability to build applications that can work with huge data sets in a 64-bit virtual memory space (and port over existing 64-bit code), without also requiring an immediate upgrade to all of Mac OS X's drivers and other kernel-level extensions. That transition will happen with Snow Leopard.
- http://www.appleinsider.com/articles/08 ... tml&page=3

Something the above fails to mention, is that unlike windows OSX can address 4GB pages (rather than the default 2GB pages in WinXp32/Vista32 that can be switch to enlarged userspace of 3GB with /3T):

While i386 support in XNU has existed since the mid-90s, and has been a shipping feature of OpenStep, the i386 part had not been used in Mac OS X until the advent of Intel machines in 2005/2006. And with the introduction of the 64 bit Mac Pro in 2006, x86_64 (AMD64, Intel64, EM64T, x64, ...) support has been added to XNU - but XNU is not a 64 bit kernel, though. XNU supports 64 bit user mode applications, but it is 32 bit itself. Since porting a 32 bit kernel to 64 bit is a big task, it could not be donein just half a year between the introduction of the first Intel machines in January of 2006 (until then, Apple developers had worked on finalizing the 32 bit i386 version) and the introduction of the Mac Pro in August.

There is just a single kernel image for 32 and 64 bit Intel: It is loaded as a 32 bit process in 32 bit protected mode on both kinds of machines, and if 64 bit support is detected, the kernel switches into long mode compatibility mode - a mode that supports running 32 bit code, but also allows easy switching to 64 bit code. So the whole kernel code is still unmodified 32 bit code, but tiny stubs that deal with copying between user address spaces (which can be 64 bit), and the syscall and trap handlers are 64 bit code. Next to being an easy port, this has the extra advantages that the 64 bit capable kernel can still easily support 32 bit KEXTs, and conserves memory by being able to use 32 bit pointers throughout a large part of kernel code. On the flip side, the kernel cannot use the extended x86_64 register set and is restricted to a 32 bit address space.

But while all other common 32 bit operating systems like Linux, Windows and the BSDs split the address space into 2 GB for user and 2 GB for kernel (2/2) or 3 GB for user and 1 GB for kernel (3/1), the i386/x86_64 version of XNU uses a 4/4 split: While the kernel is running, the user's data is not mapped into its address space, and while user code is running, the kernel is not mapped. So user and kernel can each have 4 GB of address space with the disadvantage of being less efficient in copying of data between user and kernel. But this way, kernel mode can map more devices into its address space (like video cards with a lot of memory), and manage more RAM, thus pushing out the limit when a true 64 bit kernel is required.
- http://events.ccc.de/congress/2007/Fahr ... kernel.pdf

The rest of the Appleinsider series (was a 4-parter) is informative & worth a read for anyone who cares about OSX geekery:
http://www.appleinsider.com/topics/Road ... opard.html

[valis]

Which means that yes, Red_Muze is correct 64bit applications are fully supported in Leopard. But addressing 16TB of memory space is not available just yet...

[ReD_MuZe]

yes as i said we are not sure we will have the 64bit version since nobody does music on those oses.
we will have windows 32bits versions
internal resolution is still 64bits

[dawman]

Open Source isn't my cup of tea, but I wouldn't deny a Linux based 'custom OS' approach may be the best possible choice to performance and reliability.
But I truely mean custom, not that faking stuff most distributions are about

Is this maybe why the Linux custom O.S. used on the Muse Receptors allows so many more plugs than Mac or PC O.S.'s ?
It is a computer afterall, and it uses the AMD for it's more efficient design, meaning that most CPU's waste resources tp get the job done, even though AMD also does that, it needs less MHz to perform the same tasks.

I would love an entire live rig dedicated to audio, instead of taking leftover scraps from gamer/photoshop based O.S.'s.

[valis]

Open Source isn't my cup of tea, but I wouldn't deny a Linux based 'custom OS' approach may be the best possible choice to performance and reliability.
But I truely mean custom, not that faking stuff most distributions are about

Is this maybe why the Linux custom O.S. used on the Muse Receptors allows so many more plugs than Mac or PC O.S.'s ?
It is a computer afterall, and it uses the AMD for it's more efficient design, meaning that most CPU's waste resources tp get the job done, even though AMD also does that, it needs less MHz to perform the same tasks.

I would love an entire live rig dedicated to audio, instead of taking leftover scraps from gamer/photoshop based O.S.'s.

AMD no longer has the IPC (instructions per clock cycle) crown the way they did during the p4 era. Core & Core2 cpu's are quite efficient, though during those generations AMD could still claim their integration of memory controller and resulting more efficient memory transfers. However you'll note that this didn't grant them the performance crown. It seems to most that their purchase of ATI has cost them a bit in terms of ability to fund R&D, their last 2 generations of cpu's have either gotten really bad press for bugs (TLB bug which the i7 actually has now too!) or their lack of quad-core options (cores are the new 'megahertz').

Intel purposefully delayed integrating their own memory controller as long as possible to extend the arc of performance of their cpu's (they could have moved to a similar design years ago, but doing it now made it much easier to show continued performance improvements that drive sales). Intel gained enough performance back moving away from the p4/netburst core's deep pipeline design, and then through using additional die space (freed up via process shrinks) to add in tons of cache and multiple cores faster than AMD. It's only now as we're closing on 6 cores that Intel has opted to do the integrated memory controller in i7, as the number of cores has passed what a typical gamer/home/office user can utilize with current software. Ie, performance gain for gamers & 'average' users is peaking currently with just 4-6 cores, and in the long run 12-16 cores is probably about the extent of what typical user software will be able to ultimately take advantage of with currently known methods of optimizing for SMP/SMT in coding. So debuting their integrated memory controller at this time allows them to show a big jump in benchmarks once again, almost 'for free' as all they're really doing is catching up to tech AMD has been flaunting for several years now (and simplifying board design a bit to boot).

Anyway your idea of a custom music OS isn't a bad one, and there already several linux distros that promise this. I think OSX is actually not horrible at this, although their updates do have a tendency to occasionally cause problems. All the more reason to not update a production/stage machine willy nilly... Vista pays more attention to gaming, catching up on 'eye candy' and DRM subsystems than it does professional users of either Photoshop or Audio software. I use Photoshop figuratively, but moving the UI layer out to user mode in Vista has resulted in more sluggish UI performance for very demanding graphical apps, especially high end 3d & effects/compositing applications. This has just resulted in studios moving even further into linux on the workstation desktop...

[braincell]

On a less technical level, according to Steinberg, having more RAM benefits complex projects. It is only possible to have more than 4 gigs of RAM with a 64bit OS. My projects are increasingly complex.