num/denom v's double (was: Re: [LAD] [ANN] LV2 beta3)

Lars Luthman lars.luthman at gmail.com
Wed May 30 09:41:17 UTC 2007


On Wed, 2007-05-30 at 10:30 +0100, Steve Harris wrote:
> On 26 May 2007, at 18:05, Dave Robillard wrote:
> 
> > On Fri, 2007-05-11 at 18:24 +0100, Steve Harris wrote:
> >> On 11 May 2007, at 15:07, Fons Adriaensen wrote:
> >>> On Fri, May 11, 2007 at 03:33:04PM +0200, Lars Luthman wrote:
> >>>
> >>>> That sounds like a good argument for two ints to me. Although
> >>>> you'd have
> >>>> to do a lot better than double if you wanted to represent  
> >>>> irrational
> >>>> numbers in binary form. =)
> >>>
> >>> Two 32-bit ints can represent (the non-integer part of) most (not  
> >>> all)
> >>> irrational values to better precision than a double. The algo to  
> >>> find
> >>> them is a bit mysterious but very simple. Simple example: 355/113 is
> >>> equal to pi with a relative error of less than 1e-7, not bad for two
> >>> 3-digit numbers. It's not difficult to find two 32-bit ints that  
> >>> would
> >>> be better than a double.
> >
> > So, what's the verdict on this?
> >
> > Don't want to fall into the perpetual beta with known issue trap, I'd
> > like to fix the sample rate issue and crank out another beta ASAP..
> >
> > I'm skeptical we'd ever actually see a plugin that would use rational
> > sample rate, so I vote double unless:
> >
> > - rational is required for perfect video sync over long time frames
> >
> > - someone can provide a concrete example of a realistic plugin that
> > would require/benefit from rational
> 
> Agreed. And no-one has to my knowledge.
> 
> Multirate processing would require an extension, so that extension  
> may as well add the num/denom format for the sample rates as and when  
> it's needed.

Unless you count internal filter banks with lower samplerate for each
band (to save memory and CPU, since they have lower bandwidth than the
total signal). But I don't know enough about multi-rate processing to
suggest an actual example.


--ll
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20070530/aeedf23d/attachment.pgp>


More information about the Linux-audio-dev mailing list