mystran wrote: ↑Sat Jan 12, 2019 7:40 am

it's mostly in recursive computations where you might (or might not, depending on the situation) benefit from double precision. In this case the recursive computation of interest is the phase accumulation which mostly affects pitch accuracy (probably good enough) or LFO drift (might or might not become a problem).

I've started with another "problem" in mind once I open this topic:

Code: Select all

```
y1 = sin(x1)
y2 = sin(x2)
y3 = sin(x3)
...
```

my concern was more about the drift of y1, y2, y3 between calculating it using float instead of double, rather than the accumulation error of x1, x2, x3 at each step, which is another trouble, of course; let me talk about this below. First back to "original" trouble.

As said to BertKoor, starting with a signal "already" with less precision, couldn't be a problem for future processing of itself?

I mean...

If the sinfloat(x) already have more error rather than sindouble(x), wouldn't this error increment if I apply other FX to the signal later (wave shaping, for example)?

Or (even more) if I use that signal as modulation source (FM, for example)?

Or the "number" of following stages are irrelevant since it would need a very huge amount of post process to introduce noticeable drifts (i.e. a 100 FM chain, which is uncommon)?

That's my concern about precision on math functions in audio

Now, lets talk about phase accumulation...

mystran wrote: ↑Sat Jan 12, 2019 7:40 am

If I'm not mistaken, you are actually giving up some precision here by using 2*PI as your period. Modulo by power of two (eg. typically 1.0 for phase wrap-around) is exact (in the sense that it just bit-shifts mantissa and adjusts exponent), where as modulo by 2*PI will introduce additional rounding (not that it's going to make a huge difference in practice, but still).

That said, if we assume phase wrap around at 1.0 (for simplicity of the computation that follows), then your pitch accuracy for single precision is on the order of 1/(2^23) cycles per sample and for double precision on the order of 1/(2^52) cycles per sample. So for single precision at 44100Hz sampling that means roughly 0.005Hz precision, which is probably sufficient for audio most of the time, but could become a problem for slower LFOs if you're running them at audio rates.

Yes, I calculate phase (x1, x2, x3, ecc) this way:

Code: Select all

```
double bp0 = mNoteFrequency * mHostPitch;
...
for (int sampleIndex = 0; sampleIndex < blockSize; sampleIndex++) {
// sin(phase) here
phase += std::clamp(radiansPerSample * (bp0 * pB[sampleIndex] + pC[sampleIndex]), 0.0, PI);
if (phase >= TWOPI) { phase -= TWOPI; }
}
```

And indeed using double instead float will introduce more errors on phase accumulation, right

I've just ignore it until now, hehe.

Not sure about your suggestion of the "trickier way" to remove this phase drift: reset... on wrap?

How do you know which value "should it be" at wrap moment? Uhm, can you provide to me an example?

mystran wrote: ↑Sat Jan 12, 2019 7:40 am

Each decimal digit is worth 20dB of signal to noise, so 8 decimal digits equals 160dB which is certainly enough for pretty much all audio purposes (although I'd guess it's really 26 bits of mantissa, so about 162dB). That's more than you can fit into single-precision, and honestly twiddles for long FFTs are pretty much the only thing I can think of that might need more. In fact, for general audio use you might even want to opt for less accurate approximation.

Well, yes: I think ippsSin_64fc_A26 is enough so! I'll looking for a sin math approx with this kind of error (approximately 8 exact decimal digits), which can work on SSE2 and also double (for testing purpose). Found

this, but it only works with float.

kryptonaut wrote: ↑Sun Jan 13, 2019 3:40 am

As Mystran says, if you are using the wave as an audio source then a naively generated saw/pulse/triangle will sound very rough regardless of whether you use floats or doubles, due to the presence of harmonics with frequencies greater than Nyquist. This is not a precision issue, but is caused by the abrupt changes in the waveform value/slope.

Yeah I know. Right now I'm more interested on "generating" precision; I know the problem of aliasing, I'll challenge it later, thanks for remark.

kryptonaut wrote: ↑Sun Jan 13, 2019 3:40 am

I'd suggest you look at wavetables or BLEP synthesis if you are interested in this area.

BLEP and

Wavetable are my next cases of study

Now I'm getting the basics!