64-bit audio engines are on the way !

[WillieJenkins]

http://www.cakewalk.com/x64/

See the bottom of the page for the video / white paper of the AES talk.

[DevonB]

Hmm, will have to give this a read later. Should be interesting!

Devon

[drez]

Oversimplification here, but why did we ever move to 32 bit from 16 bit? or to 16 bit from 8 bit? Those that don't see a benefit to moving to 64 bit computing should move back to 8 bit processors and be happy because obviously all those bits are not needed, right?

You're an idiot. Colour is more my specialty so I'll explain it from that point-of-view, although its pretty much the same for audio. 8-bit colour processing gives you a total range of 256 colours, like a GIF image. 16-bit processing gives you a range of 65,536 colours which is much better but if you change your graphics card settings to 16 bit you will definitely notice the difference. 32 bit processing gives us 4.2billion colours which is considerably more colours than any device can display and probably more colours than the human eye is capable of perceiving. The standard colour depth for digital images is 24 bit [8bit x 3 channels] which covers more than enough to be able to display any image with sufficient precision.
Working with 8bits-per-channel precision leaves some room for calculation but when compositing images over one another we sometimes get nasty artifacts like colour-banding and clipping/clamping [just like overdriven audio]. It also limits how much we can alter an image before it starts to look "wrong". 16bits-per-channel gives us a lot more room to manouvre and, in my experience, is plenty for most of the work I do. Processing image information with 32bit precision gives us a mile of headroom for making calculations that will result in full, natural colour no matter how much we alter [process] the image. With HDRI, an image which takes full advantage of 32bits-per-channel, we can make a single image look like anything from middle of the night to middle of the day without any perception of the image having been altered to achieve the result. Going to 64bit colour precision will not in any way improve our ability to do the kind of work we do in the film/TV/video industry. There is just no advantage at all.
In audio, 32bit precision gives us virtually infinite headroom already so going to a full 64bit processing pipeline is not going to give us too many practical advantages. As already mentioned, there are plenty of applications which already take advantage of 64bit processing where it makes a difference and this has to be more efficient than doing everything with twice the bit depth whether it matters of not.

So you are saying that a 64bit pipeline on your chipset will not give you a performance increase due to parallel processing? Are you saying there will be no increase in performance because of increased bus and IO bandwidth? It increases the instructions per clock cycle, so how in the world is it not going to translate to a performance gain?

You don't think people want to load 10 gig piano sample sets in RAM? You may or may not, but lots of people would like the flexibility. The advantages aren't just about what you think you can HEAR, but about the increase in performance of the applications.

Take your blinders off.

[SKoT_FX]

BONES: A 32-bit application running on a 64bit OS can still only access 4GB. It's knowledge of memory addresses only extends to 32bit. You *can* have multiple applications, each with 4GB, running in an address space > 4GB. 32-bit Applications can be specially compiled to use tech like intel's EM64T, which gives access to > 4GB, but generic 32bit apps running on 64bit OS's will only get the benefit of potentially having their own 4GB address space completely co-existant in RAM with our apps.

Processing audio as doubles has advantages when extremely high accuracy is required, eg in filters with any kind of feedback (IIR filters), or FFT ops. Small round-off errors can quickly accumulate, especially if running DSP modules at a high sampling rate to avoid aliasing.

[spaceman]

Oversimplification here, but why did we ever move to 32 bit from 16 bit? or to 16 bit from 8 bit? Those that don't see a benefit to moving to 64 bit computing should move back to 8 bit processors and be happy because obviously all those bits are not needed, right?

You're an idiot. Colour is more my specialty so I'll explain it from that point-of-view, although its pretty much the same for audio. 8-bit colour processing gives you a total range of 256 colours, like a GIF image. 16-bit processing gives you a range of 65,536 colours which is much better but if you change your graphics card settings to 16 bit you will definitely notice the difference. 32 bit processing gives us 4.2billion colours which is considerably more colours than any device can display and probably more colours than the human eye is capable of perceiving. The standard colour depth for digital images is 24 bit [8bit x 3 channels] which covers more than enough to be able to display any image with sufficient precision.
Working with 8bits-per-channel precision leaves some room for calculation but when compositing images over one another we sometimes get nasty artifacts like colour-banding and clipping/clamping [just like overdriven audio]. It also limits how much we can alter an image before it starts to look "wrong". 16bits-per-channel gives us a lot more room to manouvre and, in my experience, is plenty for most of the work I do. Processing image information with 32bit precision gives us a mile of headroom for making calculations that will result in full, natural colour no matter how much we alter [process] the image. With HDRI, an image which takes full advantage of 32bits-per-channel, we can make a single image look like anything from middle of the night to middle of the day without any perception of the image having been altered to achieve the result. Going to 64bit colour precision will not in any way improve our ability to do the kind of work we do in the film/TV/video industry. There is just no advantage at all.
In audio, 32bit precision gives us virtually infinite headroom already so going to a full 64bit processing pipeline is not going to give us too many practical advantages. As already mentioned, there are plenty of applications which already take advantage of 64bit processing where it makes a difference and this has to be more efficient than doing everything with twice the bit depth whether it matters of not.

So you are saying that a 64bit pipeline on your chipset will not give you a performance increase due to parallel processing? Are you saying there will be no increase in performance because of increased bus and IO bandwidth? It increases the instructions per clock cycle, so how in the world is it not going to translate to a performance gain?

You don't think people want to load 10 gig piano sample sets in RAM? You may or may not, but lots of people would like the flexibility. The advantages aren't just about what you think you can HEAR, but about the increase in performance of the applications.

Take your blinders off.

he was saying that 32bit is more than plenty in most situations. 64bit is usefull in others but it would be foolish to have the constant overhead in processing involved in 64bit processing when 32bit is all it needs in most situations..

I think however that 64bit engine will/do actually dynamically adjust their processing when encountering situations that onle require 32bit. iow I don't think a 64bit engine does everything in 64bit

[drez]

Oversimplification here, but why did we ever move to 32 bit from 16 bit? or to 16 bit from 8 bit? Those that don't see a benefit to moving to 64 bit computing should move back to 8 bit processors and be happy because obviously all those bits are not needed, right?

You're an idiot. Colour is more my specialty so I'll explain it from that point-of-view, although its pretty much the same for audio. 8-bit colour processing gives you a total range of 256 colours, like a GIF image. 16-bit processing gives you a range of 65,536 colours which is much better but if you change your graphics card settings to 16 bit you will definitely notice the difference. 32 bit processing gives us 4.2billion colours which is considerably more colours than any device can display and probably more colours than the human eye is capable of perceiving. The standard colour depth for digital images is 24 bit [8bit x 3 channels] which covers more than enough to be able to display any image with sufficient precision.
Working with 8bits-per-channel precision leaves some room for calculation but when compositing images over one another we sometimes get nasty artifacts like colour-banding and clipping/clamping [just like overdriven audio]. It also limits how much we can alter an image before it starts to look "wrong". 16bits-per-channel gives us a lot more room to manouvre and, in my experience, is plenty for most of the work I do. Processing image information with 32bit precision gives us a mile of headroom for making calculations that will result in full, natural colour no matter how much we alter [process] the image. With HDRI, an image which takes full advantage of 32bits-per-channel, we can make a single image look like anything from middle of the night to middle of the day without any perception of the image having been altered to achieve the result. Going to 64bit colour precision will not in any way improve our ability to do the kind of work we do in the film/TV/video industry. There is just no advantage at all.
In audio, 32bit precision gives us virtually infinite headroom already so going to a full 64bit processing pipeline is not going to give us too many practical advantages. As already mentioned, there are plenty of applications which already take advantage of 64bit processing where it makes a difference and this has to be more efficient than doing everything with twice the bit depth whether it matters of not.

So you are saying that a 64bit pipeline on your chipset will not give you a performance increase due to parallel processing? Are you saying there will be no increase in performance because of increased bus and IO bandwidth? It increases the instructions per clock cycle, so how in the world is it not going to translate to a performance gain?

You don't think people want to load 10 gig piano sample sets in RAM? You may or may not, but lots of people would like the flexibility. The advantages aren't just about what you think you can HEAR, but about the increase in performance of the applications.

Take your blinders off.

he was saying that 32bit is more than plenty in most situations. 64bit is usefull in others but it would be foolish to have the constant overhead in processing involved in 64bit processing when 32bit is all it needs in most situations..

I think however that 64bit engine will/do actually dynamically adjust their processing when encountering situations that onle require 32bit. iow I don't think a 64bit engine does everything in 64bit

If I have twice the bandwidth to shove something through to the processor that is capable of a lot more cycles being processed in the same amount of time as a 32 bit hardware architecture, then I am going to see a performance increase. Why is this a problem? I don't care if you render audio at 8 bit mono, the fact is I will be able to "process" more of that data through a wider bus to the processor. I will then have better performance over the 32 bit architecture with the same audio files created on a 32 bit box or a 64 bit box. Its about processing power not the sound of the output. The processing power is what I care about.

[HHaynes]

The truth is that there are lots of opportunities to improve things in a 64-bit architecture - not because it's inherently 64-bit, but because it's a newer architecture with more resources, and even more importantly - more efficient abstractions for handling data that's important to media creation. Addressing more memory is the least of it.

The "YAH - but will it RAWK?" question is the straw man here. The most important factor in answering that question honestly has much more to do with the musician than it does with the software or underlying architecture.

[SKoT_FX]

People already have access to 128-bit wide instructions with SSEx / AltiVec etc, and have even had access to 64-bit instructions since MMX; wider instructions / data can exist on any bit-count system. Addressable memory space *is* the big thing when talking about specifically 64bit OS/archs.

[HHaynes]

http://uk.news.yahoo.com/21092006/152/a ... thers.html

I rest my case. [unsubscribes]

[drez]

People already have access to 128-bit wide instructions with SSEx / AltiVec etc, and have even had access to 64-bit instructions since MMX; wider instructions / data can exist on any bit-count system. Addressable memory space *is* the big thing when talking about specifically 64bit OS/archs.

Correct me if I'm wrong Skot, but if you now have a 64 bit path to the bus, doesn't that allow you to move those bits through to the processor faster as you have a wider "road"?

[DevonB]

How much a processor will process is based on signalling rate, or how many instructions per second a processor will process. No matter how 'wide' the bus is, 16 bit, 32 bit, 64 bit, etc. it's still serialized. This is why multi cores and multi processors really get such a boost in performance, because now you can process more than one thing at the same time.

If this has changed recently, I'd like to know about it. Be more than happy to be wrong, but looking at the slight boost in performance for 64 bit tells me it's probably not.

Devon

[Rabid]

How much a processor will process is based on signalling rate, or how many instructions per second a processor will process. No matter how 'wide' the bus is, 16 bit, 32 bit, 64 bit, etc. it's still serialized. This is why multi cores and multi processors really get such a boost in performance, because now you can process more than one thing at the same time.

If this has changed recently, I'd like to know about it. Be more than happy to be wrong, but looking at the slight boost in performance for 64 bit tells me it's probably not.

Devon

I think the counter here is a move to multi-processors. Mac has already released the new system with multiple core duo processors. In a Win machine with 4 core duo processors I think the bus bandwidth would be more limiting than the processor.

[tony tony chopper]

These quantization errors were gone when using the 64-bit mixing bus

There's error, wether it's 32bit, 64bit, 128bit, since it's finite. Error is so tiny that it's neglectable, and for mixing it's already the case with 32bit.

Technical, non-audio tests that showed you errors in 32bit mixing could have shown you the same with 64bit mixing.

[BONES]

So you are saying that a 64bit pipeline on your chipset will not give you a performance increase due to parallel processing?

Well, given that I've been working with a 64bit CPU for the last couple of years, I don't see the relevance.

Are you saying there will be no increase in performance because of increased bus and IO bandwidth?

Again, its irrelevant to this discussion.

You don't think people want to load 10 gig piano sample sets in RAM?

For the third time, you only need a 64bit OS to use that amount of RAM.

The advantages aren't just about what you think you can HEAR, but about the increase in performance of the applications.

Which, as I explained, is largely irrelevant.

Take your blinders off.

Grow a brain.

BONES: A 32-bit application running on a 64bit OS can still only access 4GB. It's knowledge of memory addresses only extends to 32bit.

And yet we've been selling 32 bit applications running on a 64bit OS with up to 16Gb or RAM. People seem happy to pay their half-a-million bucks so it must work OK. Of course the're software/hardware turnkey systems so they only get used for one thing.

You *can* have multiple applications, each with 4GB, running in an address space > 4GB. 32-bit Applications can be specially compiled to use tech like intel's EM64T, which gives access to > 4GB, but generic 32bit apps running on 64bit OS's will only get the benefit of potentially having their own 4GB address space completely co-existant in RAM with our apps.

Which is to say that if your OS allows it, you can address as much RAM as you like, which is what I said.

If I have twice the bandwidth to shove something through to the processor that is capable of a lot more cycles being processed in the same amount of time as a 32 bit hardware architecture, then I am going to see a performance increase. Why is this a problem?

Because its irrelevant. It has nothing to do with what we're talking about. Like I said, I've been using a 64 bit CPU for more than two years. We're talking about software, you're talking about hardware. Using your logic we'd be better off staying with 32bit as you can shove twice as much down the pipe. Move to 64bit software and you have to move more data around. But that's not how it works.

[Radek]

People already have access to 128-bit wide instructions with SSEx / AltiVec etc, and have even had access to 64-bit instructions since MMX; wider instructions / data can exist on any bit-count system. Addressable memory space *is* the big thing when talking about specifically 64bit OS/archs.

Correct me if I'm wrong Skot, but if you now have a 64 bit path to the bus, doesn't that allow you to move those bits through to the processor faster as you have a wider "road"?

64 bits bus was already in Pentium1. FPU had 80bits of precission ever since x86 got a FPU. We can say that SSE unit is 128 bit however it's a vector unit so it will rather mean that it can process 4x32 bit numbers (hence "128 bits"). There is nothing stoping anyone from doing any precision for mixing (or whatever) on any CPU. You can have even 4096 bit accurate mixers on current CPUs. It will only need much more cycles to compute.

It's unfortunate but all talk about "bitness" can not be set just to one thing. It's so because different parts of a cpu can have different widths:
- an intenger ALU (32bit wide before x86-64)
- a FPU (always 80bit since 8087)
- memory bus (64bit since Pentium1, 128bit since dualchannel)
- vector unit (64bit since MMX, 128bit since SSE)
- datapath to caches (???? but probably wider than 128bits)
- size of machine opcodes (variable in x86, bigger in x86-64)
- adressing capability (there are Intel extensions for 36bit adressing in 32bit processors)