Question

I’m looking at this example about sound generation on iOS because I need to do something similar but there’s some parts I don’t understand and I was hoping someone could help me with that.

In this part of the code:

    double theta_increment = 2.0 * M_PI * viewController->frequency / viewController->sampleRate;
    // Generate the samples
    for (UInt32 frame = 0; frame < inNumberFrames; frame++) 
    {
        buffer[frame] = sin(theta) * amplitude;

        theta += theta_increment;
        if (theta > 2.0 * M_PI)
        {
            theta -= 2.0 * M_PI;
        }
    }

I don’t really understand what the theta += theta_increment; part is for. To me it makes more sense to do something like this inside the for loop:

buffer[frame] = sin(theta_increment * frame);

Any idea why that wouldn’t work? Also, I have no idea what this part of the code is for: if (theta > 2.0 * M_PI) so any explanation on that would be very welcome too.

Answer 1

Your approach could be used to create the same result, expressed differently. However, theta += theta_increment; will be a simpler expression (to calculate) than what you propose.

The domain of the phase is wrapped to sin's logical parameter domain. This step is really not necessary for short samples. Due to limits in floating point storage, your frequency may eventually vary and ultimately never increment if the value is not wrapped, depending how many samples you generate and whether you use float or double. Think of it this way: What will happen if you have a huge positive floating point number (the value of your phase accumulator) and you attempt to add 0.000004 to it? Floating point error will round it to fit into a float or double and the error will result in phase and ultimately pitch instabilities. For short samples (e.g. some cycles), the wrap wouldn’t be needed in this case, but for many many cycles, it serves to stabilize the pitch and phase accumulator over time.

Finally, theta would be used to store the phase ramp’s last value, in order to resume generation where it left off in a following render invocation. Without that, the output would restart at 0 at render invocation boundaries, producing very unpleasant noises and the wrong frequencies.

All things considered: It was likely because it was a simple demo, and a fast way to generate the sine in that context. Your approach has some ‘costly’ conversions, but it is branchless — it could be faster than the original, esp for higher frequencies.