Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER General Discussion Forum

Reply
 
Thread Tools Display Modes
Old 06-01-2006, 04:02 AM   #1
jens
Human being with feelings
 
jens's Avatar
 
Join Date: Feb 2006
Location: Basel, Switzerland
Posts: 4,715
Default question about ' 64-bit floating point sample pipeline for high quality '

What does this mean?

Is the whole mixing engine 64bit?

If so could it be made optional? (as it usually is if the host supports 64bit fpp)

64bit surely uses more cpu-resources than 32bit and personally I wouldn't want to see them wasted like this (as my old ears can't hear any difference anyway).
jens is offline   Reply With Quote
Old 06-01-2006, 04:08 AM   #2
malcolmj
Human being with feelings
 
malcolmj's Avatar
 
Join Date: Jan 2006
Location: Australia
Posts: 1,668
Default

It basically means that all internal processing is done at 64 bit floating point so you always get the highest internal resolution.

Why would you want it optional? Have you noticed REAPER chewing up your CPU resources?
malcolmj is offline   Reply With Quote
Old 06-01-2006, 04:08 AM   #3
Art Evans
Mortal
 
Join Date: Feb 2006
Posts: 6,654
Default

Come on, you wouldn't want to reduce the headroom down to a mere 1500dB in 32 bit, would you?

I'd be in favour of a 32 bit/64 bit switch if it actually made a useful difference in performance.
Art Evans is offline   Reply With Quote
Old 06-01-2006, 04:45 AM   #4
jens
Human being with feelings
 
jens's Avatar
 
Join Date: Feb 2006
Location: Basel, Switzerland
Posts: 4,715
Default

Quote:
Originally Posted by Art Evans
Come on, you wouldn't want to reduce the headroom down to a mere 1500dB in 32 bit, would you?
yes, I would indeed.

Quote:

I'd be in favour of a 32 bit/64 bit switch if it actually made a useful difference in performance.

How can you know it makes no difference.

It surely makes a difference in Tracktion and Podium - as axpected - hence it is optional there - there are simply more numbers to calculate - what makes you think the higher precision comes at no expense?
jens is offline   Reply With Quote
Old 06-01-2006, 04:50 AM   #5
jens
Human being with feelings
 
jens's Avatar
 
Join Date: Feb 2006
Location: Basel, Switzerland
Posts: 4,715
Default

Quote:
Originally Posted by malcolmj
It basically means that all internal processing is done at 64 bit floating point so you always get the highest internal resolution.
are you sure that's what it means?

Quote:
Why would you want it optional?
please read my first post again - I already have adressed this point in plain words.

Quote:
Have you noticed REAPER chewing up your CPU resources?

Yes.


(I have done a few tests - saying 'the performance is good' or 'the performance is bad' is just meaningless propaganda without actually having done valid tests - so that's what I always do if I compare the performance of application X with the performance of application Y. )

Last edited by jens; 06-01-2006 at 04:52 AM.
jens is offline   Reply With Quote
Old 06-01-2006, 05:19 AM   #6
Art Evans
Mortal
 
Join Date: Feb 2006
Posts: 6,654
Default

Quote:
How can you know it makes no difference.
We're on the same page, Jens - what I mean is, if by having a switch from 64 bits to 32 bits I'd be loading the CPU significantly less, then it's a good idea to have a switch. If it would make no difference in CPU usage, I don't see the point. I too doubt whether I'd hear a difference under normal circumstances but perhaps if you've got a huge effects rack, maybe cumulative errors might be avoided? dunno.
Art Evans is offline   Reply With Quote
Old 06-01-2006, 05:48 AM   #7
jens
Human being with feelings
 
jens's Avatar
 
Join Date: Feb 2006
Location: Basel, Switzerland
Posts: 4,715
Default

Quote:
Originally Posted by Art Evans
We're on the same page, Jens - what I mean is, if by having a switch from 64 bits to 32 bits I'd be loading the CPU significantly less, then it's a good idea to have a switch. If it would make no difference in CPU usage, I don't see the point.
agreed - but I think it should make a significant difference :-)

Quote:
I too doubt whether I'd hear a difference under normal circumstances but perhaps if you've got a huge effects rack, maybe cumulative errors might be avoided? dunno.
probably there are indeed situations where a small difference is noticable for good&trained ears.


Here's what Frits Nilsen (the developer of Podium) wrote about 64bit fpp:


Quote:
Originally Posted by Frits Nilsen
Technical explanation of the 64 bit floating point mixing:

If your music production mainly concentrates on using softsynths and encoding the final master to MP3 files, then don't bother with 64 bit mixing as you won't be able to hear any improvements in audio quality.

If however you are producing music recorded in pristine studio conditions and aimed for reproduction on high end audio equipment, 64 bit mixing will offer better precision and larger dynamic range.

The 64 bit mixing will only be utilized when the mixer engine is processing and routing audio internally. The VST plugin specification currently only supports 32 bit floating point audio, so the mixer engine will convert the audio down to 32 bit floats when routing audio through VST plugins.

When describing floating point numbers, the 32 and 64 bits refers to the amount of memory that is required to store the floats. The bits are split into two parts that stores the precision and the exponent for the 'floating point'. 32 bit floats offers 25 bit precision and 64 bit floats offers 54 bit precision.

The advantage of 64 bit mixing is evident when an audio signal is gain scaled or when two or more audio signals are 'summed' in the mixer engine.

Gain scaling occurs when the track gain or pan settings are affecting the audio signal. The scaling involves multiplying the floating point audio signal with a floating point scale value. These multiplications will result in values that uses more precision bits than the original audio signal, causing the least significant bits of the result to be discarded.

To illustrate the effect of summing, let's assume that you have two 25 bit precision audio sources that you want to mix together. These sources could be wave files or the 32 bit floating point output of VST plugins. If you mix these sources together without changing the gain of the tracks, the output will fit within 32 bit floats, provided that the summed output does not clip. If you change the gain of one of the tracks, then the 25 bit precision of that track is displaced up or down in relation to the other track. A gain change of 6 dB will result in approximately one bit displacement. When summing the two tracks the combined precision interval has thus been extended beyond the 25 bits that can be stored in 32 bit floats, so the least significant bits are truncated and you loose some of the precision in the audio sources.

This is where 64 bit mixing will offer an advantage over 32 bit mixing, as it can use 54 bit precision to store the results of gain scaling and summing, and thereby reduce the artifacts of the floating point truncations.

So what's the point of the higher precision if the master output is being bounced to a 24 bit or 16 bit wave file? For every audio track that you add to a mix, you add noise as a result of the truncation of the lower bits of the signal. The accumulation of these rounding errors can result in a sligthly degraded output that can be present even when rendering to 16 bit wave files.

Despite these apparent mathematical benefits, 64 bit mixing will only yield a minimal quality improvement. 32 bit mixing is still fully sufficient for professional grade productions.


An example of how to test the difference between 32 bit and 64 bit mixing:

* Set the mixer engine to 32 bit mode in the preferences dialog.
* Create an arrangement with a bounce enabled master track.
* Import a 16 bit wave file onto a new track.
* Create a track with level automation and create a curve sequence containing a few curve events with slow fades.
* Bounce record the arrangement.
* Drag the bounced master sound to a new track and mute the track. The sound properties should show that it is using 32 bit float.
* Switch the mixer engine to 64 bit mode.
* Create a new sound on the master output track.
* Bounce record again.
* Drag the bounced master sound to a new track. The sound properties should show that it is using 64 bit float.
* Enter the sound editor for one of the two bounced recordings, select the entire wave data and use the 'Invert phase' edit menu.
* Mute the 16 bit wave file track and the level automation track, and unmute the two tracks containing the bounced audio.
* Create a new sound on the master output track.
* Bounce record again.
* The new bounced sound appears to be silent, because the inverted phase sound will cancel out the non-inverted phase sound.
* Enter the sound editor for the newly bounced sound, select the entire wave data and use the 'Normalize' edit menu.
* Normalizing will boost the extremely low level noise differences between the 32 bit and 64 bit bounced recordings.
* Before hitting play to listen to the noise, make sure the volume dial on your stereo is turned down. The noise you hear is the result of the truncation that occurs during 32 bit processing.

jens is offline   Reply With Quote
Old 06-01-2006, 06:36 AM   #8
Art Evans
Mortal
 
Join Date: Feb 2006
Posts: 6,654
Default

Excellent quote - many thanks!!
Art Evans is offline   Reply With Quote
Old 06-01-2006, 10:40 AM   #9
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,716
Default

The truth is that modern CPUs process 32-bit and 64-bit floating point data at the same rate anyway (unless you area using SSE*)-- the main disadvantage to 64 bit fp is that it uses twice the memory.

Making it switchable between 32/64 bit would make the whole thing more complex and larger and more work to debug, so we're not going to do that. You will have your 64 bit and like it. And also, re: the podium post, the VST spec now has 64 bit support in it as well (we will be adding that soon).
Justin is offline   Reply With Quote
Old 06-01-2006, 11:40 AM   #10
synth
Human being with feelings
 
synth's Avatar
 
Join Date: Feb 2006
Location: Synthopia
Posts: 1,729
Default

So,this means if using SSE,64-bit mixing mode will be even faster? If so,SSE optimizations is the way to go

I don't care about memory usage,performance is much more important.
__________________
Synth's consolidated FR thread: Loaded with some of the *hottest* features in DAW-land:

http://forum.cockos.com/showthread.php?t=22279
synth is offline   Reply With Quote
Old 06-01-2006, 02:05 PM   #11
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,716
Default

Quote:
Originally Posted by synth
So,this means if using SSE,64-bit mixing mode will be even faster? If so,SSE optimizations is the way to go

I don't care about memory usage,performance is much more important.
No, last I checked (I may be wrong by now) SSEx only supported 32 bit floats, so it would mean you couldn't SSE optimize 64 bit mode.. but it's irrelevant anyway cause we don't use SSE.

If you don't care about memory usage, then using 64 bit floats is only marginally slower than 32 bit floats.
Justin is offline   Reply With Quote
Old 06-01-2006, 02:08 PM   #12
jens
Human being with feelings
 
jens's Avatar
 
Join Date: Feb 2006
Location: Basel, Switzerland
Posts: 4,715
Default

Quote:
Originally Posted by Justin

If you don't care about memory usage, then using 64 bit floats is only marginally slower than 32 bit floats.

didn't know that *oops* - thanks for clarifying it, Justin - I also don't care about the ram...
jens is offline   Reply With Quote
Old 06-01-2006, 02:11 PM   #13
jens
Human being with feelings
 
jens's Avatar
 
Join Date: Feb 2006
Location: Basel, Switzerland
Posts: 4,715
Default

Quote:
Originally Posted by Justin
And also, re: the podium post, the VST spec now has 64 bit support in it as well (we will be adding that soon).

does this also go for 'non 64bit'-cpu's?

(probably 'yes' as the fpu is 80bit anyway, right?)
jens is offline   Reply With Quote
Old 06-01-2006, 03:24 PM   #14
synth
Human being with feelings
 
synth's Avatar
 
Join Date: Feb 2006
Location: Synthopia
Posts: 1,729
Default

Justin,read this:
Introduced with the Pentium 4, SSE2 is a major enhancement to SSE (which some programmers renamed "SSE1"). SSE2 adds new math instructions for double-precision (64-bit) floating point and 8/16/32-bit integer data types, all operating on the same 128-bit XMM vector register-file previously introduced with SSE.


SSE1 would be great speed up,combined with a 32-bit FP pipeline.

SSE2 or later will be great with the modern CPUs with the 64-bit pipeline.

So,32-bit will still benefit many users with AthlonXP machines or lower.
__________________
Synth's consolidated FR thread: Loaded with some of the *hottest* features in DAW-land:

http://forum.cockos.com/showthread.php?t=22279
synth is offline   Reply With Quote
Old 06-01-2006, 03:26 PM   #15
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,716
Default

Quote:
Originally Posted by synth
Justin,read this:
Introduced with the Pentium 4, SSE2 is a major enhancement to SSE (which some programmers renamed "SSE1"). SSE2 adds new math instructions for double-precision (64-bit) floating point and 8/16/32-bit integer data types, all operating on the same 128-bit XMM vector register-file previously introduced with SSE.


SSE1 would be great speed up,combined with a 32-bit FP pipeline.

SSE2 or later will be great with the modern CPUs with the 64-bit pipeline.

So,32-bit will still benefit many users with AthlonXP machines or lower.

Well to be honest the mixing portions really don't need that much of speedups, they are already quite fast, compared to fx/resampling/etc. And doing SSE versions just would increase complexity greatly...
Justin is offline   Reply With Quote
Old 06-01-2006, 03:51 PM   #16
synth
Human being with feelings
 
synth's Avatar
 
Join Date: Feb 2006
Location: Synthopia
Posts: 1,729
Default

Sure,SSE optimizations can be extremely useful for VSTi/VST FX and resampling
Maybe that's where FL Studio uses the optimizations mostly.I can even run some smaller projects with 64-point realtime resampling.

and,indeed - simple is better
__________________
Synth's consolidated FR thread: Loaded with some of the *hottest* features in DAW-land:

http://forum.cockos.com/showthread.php?t=22279

Last edited by synth; 06-01-2006 at 03:57 PM.
synth is offline   Reply With Quote
Old 06-01-2006, 03:56 PM   #17
Rednroll
Human being with feelings
 
Join Date: Jan 2006
Posts: 1,990
Default

Reaper is already the leanest/meanes DAW out there without all the other bloat of all the other apps, so let's just keep it how it is. Simple and lean. What other DAW do you know of with this much functionality with an installer of 1Meg in size? None!!!!! So you're gaining speed over anything else out there anyways.
Rednroll is online now   Reply With Quote
Old 06-01-2006, 04:14 PM   #18
synth
Human being with feelings
 
synth's Avatar
 
Join Date: Feb 2006
Location: Synthopia
Posts: 1,729
Default

Quote:
Originally Posted by Rednroll
Reaper is already the leanest/meanes DAW out there without all the other bloat of all the other apps, so let's just keep it how it is. Simple and lean. What other DAW do you know of with this much functionality with an installer of 1Meg in size? None!!!!! So you're gaining speed over anything else out there anyways.
Such small sizes are typical for apps programmed in assembly.
But this one is pure C,I think
REAPER.exe = only 947kB
Very impressive.

But remember,energyXT is also a great piece of software and the only thing that comes close.
__________________
Synth's consolidated FR thread: Loaded with some of the *hottest* features in DAW-land:

http://forum.cockos.com/showthread.php?t=22279

Last edited by synth; 06-01-2006 at 04:20 PM.
synth is offline   Reply With Quote
Old 06-01-2006, 04:58 PM   #19
synth
Human being with feelings
 
synth's Avatar
 
Join Date: Feb 2006
Location: Synthopia
Posts: 1,729
Default

This is interesting:

On AMD Athlon XP and K8-based cores (i.e. Athlon 64), assembly programmers have noted that it is possible to actually use both 3DNow! and SSE at the same time, because the processor has separate functional units for both. This can allow more performance by increasing further the number of calculations per clock, but it is difficult to accomplish.
__________________
Synth's consolidated FR thread: Loaded with some of the *hottest* features in DAW-land:

http://forum.cockos.com/showthread.php?t=22279
synth is offline   Reply With Quote
Old 06-01-2006, 07:28 PM   #20
jens
Human being with feelings
 
jens's Avatar
 
Join Date: Feb 2006
Location: Basel, Switzerland
Posts: 4,715
Default

Quote:
Originally Posted by Rednroll
What other DAW do you know of with this much functionality with an installer of 1Meg in size?
eXT's installer is even smaller (but doesn't come with a demo-project)
jens is offline   Reply With Quote
Old 09-18-2006, 05:38 PM   #21
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

Quote:
Originally Posted by Justin
Well to be honest the mixing portions really don't need that much of speedups, they are already quite fast, compared to fx/resampling/etc. And doing SSE versions just would increase complexity greatly...
please consider sse2 optimizations! something has to be improved in the engine. i found it very slow (three times) compared to nuendo/cubase. afaik they're using sse and/or sse2 too.
Dstruct is offline   Reply With Quote
Old 09-20-2006, 01:56 PM   #22
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

how much could sse2 speed up things?
Dstruct is offline   Reply With Quote
Old 09-20-2006, 04:15 PM   #23
Panatrope
Human being with feelings
 
Join Date: Jun 2006
Location: Melbourne, Australia
Posts: 28
Default

From many years experience at a systems level, I make this observation:

"Increased efficiency comes at a price of increased complexity".

Each user would like the program to be optimised for his/her particular system. Noting that the program is intended to be used from W98 to XP, and from P3 upwards, this is a tall order.

From peering into other peoples work, it seems the path to success is by focussing on routines that are used most frequenctly and making them very tight (assembler); then an overall organisational structure that manages the tasks optimally. Then allow users to manage their resources for the tasks they want to do.

While the program is still in development/optimisation phase, is there room for a more comprehensive 'diagnostic plug-in' which will report activity in critical resource areas or tasks which will help users (and Justin) to optimise their configuration and/or locate routines that be crunched for better performance? In particular, is the problem cpu grunt or memory bandwidth or disc speed? Then the user can take curative action with the appropriate priority.

The great thing I find about the REAPER community is participation of the users as key stakeholders in the process. This is the key to continuous improvement and success. Way to go!
__________________
Pan: (Gr) all, everything
Tropos: (Gr) turn.
Loose translation: all rounder!
Panatrope is offline   Reply With Quote
Old 09-27-2006, 01:52 PM   #24
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

Quote:
Originally Posted by Dandruff
please consider sse2 optimizations! something has to be improved in the engine. i found it very slow (three times) compared to nuendo/cubase. afaik they're using sse and/or sse2 too.
confirmed:
Quote:
Originally Posted by Fredo
C4 is already using SSE instructions.
C4 = Cubase 4
Dstruct is offline   Reply With Quote
Old 09-27-2006, 02:27 PM   #25
olzzon
Human being with feelings
 
olzzon's Avatar
 
Join Date: Jul 2006
Location: Europe
Posts: 705
Default

Quote:
Originally Posted by Dandruff
confirmed:


C4 = Cubase 4
Cubase may have sse,sse2 and no sse optimized code. Three versions of the same code in the program.
But it also has 3 times as many bugs

I think when justin says:
"Well to be honest the mixing portions really don't need that much of speedups, they are already quite fast, compared to fx/resampling/etc. And doing SSE versions just would increase complexity greatly..."
I believe him.
There might be places where reaper can be optimized, but iīm not sure that has anything to do with sse.
And to state that reaper is 3 times as slow cubase, is WAY out IMO.
Iīm really not sure that you know what you talk about when you come to that kind of conclusions.
__________________
Light travels faster than sound. Thatīs why some people appear bright until you hear them speak
Kasper Olsson Hans
olzzon is offline   Reply With Quote
Old 09-27-2006, 02:37 PM   #26
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

here reaper uses about 3 times more cpu in stop-mode than cubase with a similar setup (number of tracks): http://www.cockos.com/forum/showpost...0&postcount=56

i didn't say that it is caused by not using sse-optimisations. i've asked if it is.


cubase has much more features than reaper, thus more bugs. and reaper has plenty of bugs too!
Dstruct is offline   Reply With Quote
Old 01-07-2007, 07:05 PM   #27
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

After all this hype about the new Intel prozessors I bought myself one (E6700). And I have to say they still are too slow. I've build a template with pretty much pre-routed tracks which already uses ~15% CPU (with fx running all the time). And working with this load already gives a little laggy feeling. Hard to explain. I really would love to see some uge optimisations in the engine to give reaper some more horsepower ...
Dstruct is offline   Reply With Quote
Old 01-09-2007, 09:02 PM   #28
bogo
Human being with feelings
 
bogo's Avatar
 
Join Date: Jun 2006
Posts: 761
Default computer performance Samplitude vs Reaper

Here is a 24 bit stereo wav file played by Samp and Reaper (not at the same time) setted at 32 bit. I open the task manager to show the computer performances with both program. They are about the same. (my computer is old and slow but it did some good work mixing 8-10 track with few fx.) I haven't done the test with more track or plugins but I'm pretty sure Reaper will eat more cpu's (like it used to do in previous versions). I'm wondering what can cause that. Is this something Reaper's developpers-programmers are working on?
Attached Images
File Type: jpg sampvsreap.jpg (41.7 KB, 360 views)

Last edited by bogo; 01-09-2007 at 09:04 PM.
bogo is offline   Reply With Quote
Old 01-09-2007, 09:18 PM   #29
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

i bet the "big boys" (cubase, samplitude) all are sse (and sse2?) optimized (engine). even zynewave's podium i think ...
Dstruct is offline   Reply With Quote
Old 01-10-2007, 03:36 AM   #30
olzzon
Human being with feelings
 
olzzon's Avatar
 
Join Date: Jul 2006
Location: Europe
Posts: 705
Default

Quote:
Originally Posted by Dandruff View Post
i bet the "big boys" (cubase, samplitude) all are sse (and sse2?) optimized (engine). even zynewave's podium i think ...
I have the exact same CPU, and i donīt feel ANY slowness about this one. Reaper performs perfect. And as noted before by Justin, the mixing engine donīt take up much power.
I do believe Justin when he states that it wouldnīt make a huge difference.
There may be things that could be optimized at lower latency(64 buff), but then again multi CPUīs allways makes this hard to acomplish.
Are you sure you have setup reaper for the best performance for this CPU?
I easily run 60 tracks with good Eq and comps on all the tracks (AirEq and sonalksis comp) and i donīt have any hickups. When i run 256 buff or above. When i run 128 buff or 64, i can have some poops when running this large amount of tracks.
But less problems than i experience in ProTools. (and PT donīt allow me to run this many tracks BTW)
I think it might be worth for you to check your buffer setup in reaper.
__________________
Light travels faster than sound. Thatīs why some people appear bright until you hear them speak
Kasper Olsson Hans
olzzon is offline   Reply With Quote
Old 01-10-2007, 03:59 AM   #31
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

what are good settings for these cpus? i've just changed it to use 2 threads (one per cpu) and enabled "fx-render ahead" ...


this "laggy feeling" was a bit harsh from my side. i think sometimes the programs just look a bit laggy. just disabled all the pre-loaded vsts in my template (55 pre-routed tracks - midi and audio) and it fluctates between 4 and 10%. that's quite good and enough for me. didn't even test to max the cpu out. just hope that i can write some music again (without thinking about cpu-usage all the time) after some years with this (now) horrible slow 2.8 p4 (400mhz fsb + rambus) ...


easy
Dstruct is offline   Reply With Quote
Old 01-10-2007, 04:03 AM   #32
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

but i still have the opinion that software developers should make use of some hardware-features. why does intel and amd give us them? just to sit there unused all the time? especially if you read some articles, how fast the core duos can do sse and sse2 instructions!
Dstruct is offline   Reply With Quote
Old 01-10-2007, 04:10 AM   #33
synth
Human being with feelings
 
synth's Avatar
 
Join Date: Feb 2006
Location: Synthopia
Posts: 1,729
Default

Dandruff,try that Core 2 Duo on software that uses SSE2 (or better) optimizations and especially on PGO-optimized apps.The difference is _HUGE_.
Core 2 Duo's short pipeline and 2x better SIMD (SSE) processing ability is where it shines. Try some SSE2-optimized VSTi for example.
synth is offline   Reply With Quote
Old 01-10-2007, 04:15 AM   #34
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

yeah that's why i thought it even could boost reaper
Dstruct is offline   Reply With Quote
Old 01-10-2007, 07:47 AM   #35
pipelineaudio
Mortal
 
pipelineaudio's Avatar
 
Join Date: Jan 2006
Location: Wickenburg, Arizona
Posts: 14,046
Default

Im running dual opterons. For running 256 sample latency, I found that switching "Source material buffer size" under prefs\audio\buffering, to 200 vs the default 600, made a HUGE cpu difference
pipelineaudio is offline   Reply With Quote
Old 01-10-2007, 07:38 PM   #36
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

how many threads are good for dual-processors? just setting 2 (or should we set more like 4 or 8)?
Dstruct is offline   Reply With Quote
Old 02-04-2007, 09:05 PM   #37
Jae.Thomas
Human being with feelings
 
Join Date: Jun 2006
Posts: 22,560
Default

Quote:
Originally Posted by Justin View Post
No, last I checked (I may be wrong by now) SSEx only supported 32 bit floats, so it would mean you couldn't SSE optimize 64 bit mode.. but it's irrelevant anyway cause we don't use SSE.


is there any benefit for using SSE?
Jae.Thomas is offline   Reply With Quote
Old 02-11-2007, 05:14 PM   #38
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 12,480
Default

sse2 maybe could really speed things up i think, as it supports double-precision floating point (64bit) afaik!
Dstruct is offline   Reply With Quote
Old 02-11-2007, 06:00 PM   #39
Jae.Thomas
Human being with feelings
 
Join Date: Jun 2006
Posts: 22,560
Default

Quote:
Originally Posted by Dandruff View Post
sse2 maybe could really speed things up i think, as it supports double-precision floating point (64bit) afaik!
well that would be really excellent then.
Jae.Thomas is offline   Reply With Quote
Old 02-11-2007, 06:22 PM   #40
yep
Human being with feelings
 
Join Date: Aug 2006
Posts: 2,019
Default

Quote:
Originally Posted by Justin View Post
...You will have your 64 bit and like it...
If you ever make REAPER t-shirts, this has to be printed on the back.
yep is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 12:04 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.