Re: [linux-audio-dev] Simple Plugin API: In/Out Ports

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: Eli Brandt (eli_AT_t.gp.cs.cmu.edu)
Date: ti maalis 07 2000 - 11:35:36 EST


First and most importantly, I would like to see non-audio signals be
possible. Control signals have differing natural units, so
collectively have a wide dynamic range. A filter cutoff might be in
Hz and want to range up to 48000. Thirty-two bits is not enough integer
to hold that and audio too.

Bill Gribble wrote:
> Floating point makes things easier for the *programmer* (fixed-point
> arithmetic is fiendishly hard to code up correctly).

I don't think plug-in programmers should be expected to do fixed-point.
As you say, it's hard. Even on a DSP that supports it, in a language
(assembly) that gives you access to that support, it's hard. We can't
count on either CPU or language support.

(
For those who haven't tried to do fixed-point in x86 C: consider
multiplying two values. First say it's 0.32 format -- all the bits are
after the `decimal' point. You could say
        (x>>16) * (y>>16)
but that's obviously no good. You could correctly say
        (int32_t)(((int64_t)x * y) >> 32)
but that's gruesome: it might well mean a library call to do a 64*64->64
multiply you don't really need.

So far this is all C's fault. The truth is that the x86's 32-bit
multiply actually a 64-bit result. It leaves it in EDX:EAX, so we can
write a little asm and take EDX as the answer. (Whereas C takes EAX.)

That's fine (if non-portable) for 0.32, but we really want 4.28 or
something, to represent values greater than unity. Now it's
        mul eax, ebx
        shl edx, eax, 4 ; (I think)
which last I checked was slower than just the multiply -- don't know what
happens these days.
)

Programmers are expensive and bits are cheap. If 32-bit float is
enough, I say use it.

> Given 32 bits to
> work with, and inputs and outputs that will be within a 24-bit range
> for the foreseeable future, I'd much rather have a fixed-point
> representation than floating point.

Fixed point is marginally better than floating point as a storage
(vs. processing) format. But really, if you're within the 24-bit
range of the float mantissa, I don't see that it matters much.

One thing that might sway me: what's the current state of vector
processing (mmx, 3dnow, altivec)? Does a useful fraction of the user
base have support for something that does real 32-bit fixed-point with a
useful speed multiplier? (Or does graphics still rule the sevagram?)
I don't personally care to drop into assembly and hack this stuff,
but if it's a big win I wouldn't want to preclude it.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST