N-Track and CPU Utilization

I’ve done a search, but only came up with vers 3 and 4 answers.

Since vers 6 is so much advanced, I didn’t think those answers would be relevant.

So, does N-Track have the ability to utilize quad core processing? Or is Dual core 2 processing the most efficient right now?

Is there a huge difference between the 32bit and the 64bit utilization, in terms of rendering (mixdown, aux send/returns)?

A friend is building a new PC and wants to use N-Track. He could save money buy a dual core 2 instead of quad if N Tracks isnt utilized for it.

I have an Intel Quad 9450. It seems to handle some things pretty fast, but I am not at all sure that it is faster than a Duo would be. I ran the latency checker on it and it is only nimimally acceptable, about 500 (whatever the symbol stands for) if I know how to ready the gauge. My AMD 2X 64 4200plus runs with far less latency, about 6 to 8 on the scale. So, I use the Intel for video work (faster) and the AMD for recording. The verable here is the motherboard, the AMD maybe a better board, but it is 400 FSB and the Intel is 677 FSB.
Bax

Quote: (michaelST @ Dec. 12 2008, 7:39 AM)

I've done a search, but only came up with vers 3 and 4 answers.

Since vers 6 is so much advanced, I didn't think those answers would be relevant.

So, does N-Track have the ability to utilize quad core processing?
Or is Dual core 2 processing the most efficient right now?

Is there a huge difference between the 32bit and the 64bit utilization, in terms of rendering (mixdown, aux send/returns)?

A friend is building a new PC and wants to use N-Track.
He could save money buy a dual core 2 instead of quad if N Tracks isnt utilized for it.

n-Track does take advantage of quad core CPUs. The gain from switching from 2 to 4 cores depends on both the structure of the song(s) and the audio buffering used.
The more channels (i.e. tracks, groups, auxs) and/or effects per channel you have, the more n-Track will be able to split the work among the available cores.

Buffering comes into play because the less buffering you have the smaller must be the chunk of work that n-Track assigns to each core, so as buffering decreases the efficiency of splitting the work decreases too and you reach a point where it's faster to just use a single core. It's kind of like dividing work between people: if you have many dishes to wash you finish quicker if you many people and assign to each a portion of the available work. But if you put 4 people to wash 1 single dish you're likely to be slower than one lone washer.

Again depending on the song and CPU type (speed, number of cores, cache, shared vs non-shared cache) the point where single core may perform better than multiple cores may be from 64 to 256 samples per buffer. You can test this by toggling the 'Multithreaded audio processing' box in Preferences/Options and then performing mixdowns of a test song and measuring the time each mixdown takes for decreasing buffering settings.
It would be interesting if we could post the results of mixdowns of a benchmark song on various systems, for example the Sometimes n-Track sample song, perhaps augmented by an n-Track Reverb on each channel to make it more CPU heavy.

Flavio.

Just to have a few numbers:

“Sometimes” sample song modified to have all tracks have 1 n-Track Reverb (with default preset)
Hardware: Core 2 Duo T7300, 2.0 Ghz, 800 Mhz FSB, 4 Mb L2 Cache (shared between the 2 cores), 4 Gb RAM
n-Track 32 bit on x64 Vista, all meter windows closed.
Measuring the time it takes to mixdown the whole song to a 16 bit .wav file.

8192 x 4 (Default buffering)
No multithread: 42 sec.
Multithreaded: 27 sec. (36% speedup)

256 x 2 buffering
No multithread: 47 sec.
Multithreaded: 33 sec. (30% speedup)

128 x 2 buffering
No multithread: 50 sec.
Multithreaded: 39 sec. (22% speedup)

64 x 2 buffering
No multithread:
55.4 sec.
Multithread: 51.6 sec. (7% speedup)

The speedup from using two cores instead of one decreases as the buffer size decreases, but it remains positive even for very low buffering.

Adding a 2nd reverb for each track yields for 64 samples buffering 1:12 vs 1:30, i.e. 20% speedup, which means that increasing the song CPU load the relative advantage of using multiple CPU cores increases even for very small buffering.



I’m at home getting over a heavy flu bug so thought I’d give this a go on our system.
Here are the stats from my tests:

Hardware: Intel Core 2 Quad Q6600 / 2.4 GHz processor, 1066 MHz FSB, 8MB L2 ,
4 Gb RAM installed (3.25 Gb recognised by 32 bit XP)
n-Track 32 bit on XP 32 Bit Service Pack 3, all meter windows closed.
Measuring the time it takes to mixdown the whole song to a 16 bit .wav file.

8192 x 4 (Default buffering)
No multithread: 37 sec.
Multithreaded: 15 sec. (60% speedup)

256 x 2 buffering
No multithread: 37 sec.
Multithreaded: 22 sec. (40% speedup)

128 x 2 buffering
No multithread: 39 sec.
Multithreaded: 29 sec. (26% speedup)

64 x 2 buffering
No multithread: 43 sec.
Multithread: 41 sec. (5% speedup)