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

On 11 May 2007, at 20:37, Fons Adriaensen wrote:

> On Fri, May 11, 2007 at 06:24:38PM +0100, Steve Harris wrote:
>
>> On 11 May 2007, at 15:07, Fons Adriaensen wrote:
>
>>> 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.
>
> First, if you read the paragraph above in its context, it should be
> clear that this is *not* the rationale for having sample rates as
> a ratio of two integers. It's just a side note.
>
> (Sigh) I have already written (some nights ago) that this has nothing
> to do with _absolute_ precision. Most sound cards are way off their
> nominal sample rate anyway, and very few people complain.
>
> This is about _relative_ precision in multirate processing. It only
> works if the ratios are exact. It does not work at all if they are
> not. I can easily imagine processing networks where not all plugins
> run at the same rate, but at rates related by simple integer ratios.
> Maybe improbable for music production. But certainly possible for
> audio DSP work in general.

I see. So that's the point that I missed. Here, I think the
difference of opinion is that I don't think LADSPA-style APIs are at
all appropriate for multirate audio - the LADSPA API was built very
much with input sample rate = output sample rate in mind. I think
that any move away from that will complicate the API, when a better
solution would be to use a different API altogether.

In audio production, IME the main need for multirate processing in
music production is resampling, and while there are a wide variety of
resampling algorithms, I'm not sure it justifies a plugin URI, or any
kind of substantial addendum to one. IMHO it certainly should not be
a major feature of a predominantly synchronous API, due to the level
of complexity it brings with it. You can argue that you can ignore
the multirate features if you're writing synchronous plugins, but the
multirate parameters will always be there, confusing newbies and
making the spec document longer.

LADSPA, for all its faults was very easy to start programming. I
would never have bothered learning if it was a complex as AudioUnits,
for example.

>> b) hosts will have the sample rate available to them in that form.
>
> ??? In the current spec the sample rate is an integer. JACK and ALSA
> will give you an integer. Just set the denominator to 1 if your host
> runs all plugins at the normal sample rate, as most will do.

No all hosts run in JACK or ALSA, there are gstreamer LADSPA hosts
and Core Audio LADSPA hosts offline LADSPA hosts, and so on.

- Steve
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Received on Sat May 12 04:15:03 2007