Re: [ecasound] 64bit float DSProcessing?

Hi,

On Tue, 16 Feb 2010, Klaus Schulz wrote:

> I think 64bit (double precision) throughout the chain guarantees for lowest losses. The more
> you calculate the worse it gets. What does it help to run your plugins ( e.g. libsamplerate)
> at 64 bit  if the results get cut off later on.

but I'm not convinced this is in practise such a leap forward. I mean
already *ten* years ago, we were discussing about 64bit sample formats for
LADSPA:

"LADSPA 64bit FP support ?", Mar/2000
http://www.mail-archive.com/linux-audio-dev@email-addr-hidden/msg00342.html

... LADSPA ended up standardizing on 32bit and so far this hasn't proven
to be a problem.

Basicly 32bit floats provide 24bit of precision, and for passing sample
data around (including to audio files and hardware interfaces, 24bit suits
most needs). Processing is a different matter, but here 64bit floats can
be already used.

And it's not just us Linux folks. OS X Core Audio defaults
to 32bit floats as well:
http://developer.apple.com/audio/xaudiooverview.html
And also our friends at MS are following suit (with Windows 7):
http://blog.szynalski.com/2009/11/17/an-audiophiles-look-at-the-audio-stack-in-windows-vista-and-7/

And while "all-64bit" might provide theoretical improvements, it has
potentially very real performance impact. One thing that is still on short
supply on modern machines, is processor caches (or more precile, fast
access to enough big chunks of memory). By doubling the sample size you
are also doubling the working set size. And if this pushes your inner loop
working set out of L1 cache (which is a very real possibility with common
audio params), your performance will plummet. And with the memory
architectures of today's machines (with long pipelines), the performance
difference will be very notable!

> Come on. You're always striving for the best. You provide the best audio engine I came across
> and then your come up with "and this would be harder to implement " and "it should
> do for most of the people".

Well, this is actually a fairly easy change to make.
libecasound/sample-spec.h defines the sample type, and with a simple
change you can replace s/float/double/. A few places in the codebase need
fixing (notably LADSPA support will break as one then needs to convert the
buffer every time going into, and coming out of, LADSPA domain; and
similarly for JACK). But basicly majority of the codebase is already
ready.

But I still see very little gains from doing this, and lots of possible
drawbacks (especially to performance).

> 64 bit throughout the chain is IMO the way to go to bring losses down to the absolute
> minimum.  OSX/MS DAWs are ahead of us here - that's bugging me at least.

I do agree it's picking up in popularity as a marketing tool "full 64bit
audio path", but I'd like to see some independent sources indicating it's
really a worthwhile in terms of quality.

------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev

_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Wed Feb 17 04:15:01 2010