An oscillator is a digital or analog component that generates a repeating waveform — think of it as a signal source. In audio programming, it’s the piece of code that spits out samples of a sine wave (or other waveform) over time, at a given frequency.

For example:

• A 440 Hz oscillator emits values that, when played back at 44.1 kHz, recreate the pitch of the musical note A4.

• You can think of it as a mathematical function that cycles through waveform values at a certain speed.

By adjusting the oscillator's frequency, amplitude, and waveform shape, we can synthesize anything from a beep to a bass line.

So far in this series, we’ve been implementing oscillator logic manually inside our sample loop — like we did in Part 2. But now, we’re going to wrap that logic into a proper, reusable oscillator — one that behaves more like what you’d find in real audio engines and synthesizers.

Defining our naive oscillator

To begin shaping different waveforms, we’re going to write our first reusable oscillator. This will let us plug in different waveform logic — like square, triangle, and sawtooth — all using the same reusable structure.

If you’re already familiar with how Rust structs and enums work — great!

If not, don’t worry — you can still follow along or check out those links for a quick refresher.

• https://doc.rust-lang.org/rust-by-example/custom_types/structs.html

• https://doc.rust-lang.org/rust-by-example/custom_types/enum.html

To keep things familiar, we’ll start with just the sine wave — the same waveform we’ve been using throughout Part 1 and Part 2. It’s smooth, simple, and perfect for verifying that our oscillator behaves correctly.

Here’s our minimal Oscillator struct that generates a sine wave:

use std::f32::consts::TAU;

pub struct Oscillator {
    phase: f32,
    phase_increment: f32,
    sample_rate: f32,
}

impl Oscillator {
    pub fn new(sample_rate: f32, frequency: f32) -> Self {
        let phase_increment = frequency / sample_rate;
        Self {
            phase: 0.0,
            phase_increment,
            sample_rate
        }
    }

    pub fn set_frequency(&mut self, frequency: f32) {
        self.phase_increment = frequency / self.sample_rate;
    }

    pub fn next_sample(&mut self) -> f32 {
        self.phase += self.phase_increment;
        if self.phase >= 1.0 {
            self.phase -= 1.0;
        }

        (self.phase * TAU).sin()
    }
}

Let’s compare this new Oscillator implementation to what we did manually back in Part 2.

Here’s a quick reminder of the relevant lines from our previous code:

let phase_increment = 2.0 * PI * freq_hz / sample_rate;
phase = (phase + phase_increment) % (2.0 * PI);
let sample = (amplitude * phase.sin()) as i16;

And here’s what we do now inside our Oscillator::next_sample method:

self.phase += self.phase_increment;

if self.phase >= 1.0 {
    self.phase -= 1.0;
}

(self.phase * TAU).sin()

Let’s break it down:

Amplitude is now external

We removed amplitude scaling from the oscillator itself. Why?

Because in most audio systems, amplitude is handled outside the oscillator — through gain controls, envelopes, or mixing. That’s more modular, and it gives you full control when combining signals later.

Now, instead of embedding it in the waveform, we do:

let sample = oscillator.next_sample() * amplitude;

We changed how we handle the phase

In Part 2, we tracked phase in radians, and wrapped it using: phase = (phase + increment) % (2π).

Now we’re using a normalized phase in the range 0.0..1.0, and converting to radians only when we need the sine value. It’s simpler and matches DSP conventions more closely.

This also lets us write a cheaper phase wrap:

if self.phase >= 1.0 {
    self.phase -= 1.0;
}

This avoids calling .fract() or % every sample, which helps when optimizing for performance (especially at higher sample rates).

Why TAU instead of 2π?

Mathematically, TAU is just 2π — one full circle in radians.

So instead of:

(phase * 2.0 * PI).sin()

We now do:

(phase * TAU).sin()

Same result, cleaner expression — and easier to think of 1.0 as one full waveform cycle.

Updating our melody generator to use the oscillator

Now that we’ve wrapped our sine wave logic into a reusable Oscillator, let’s use it to recreate the melody we built in Part 2, but this time, with much cleaner code.

For simplicity, we’re keeping the Oscillator struct definition in the same file as the melody code. This tutorial isn’t about Rust project structure or module hygiene — we’re here to explore audio concepts.

If you’re curious how this could be packaged more cleanly, you can also check out oscy — a small crate I’m building that includes different oscillators and support for multiple waveforms.

fn main() {
    let spec = hound::WavSpec {
        channels: 1,
        sample_rate: 44100,
        bits_per_sample: 16,
        sample_format: hound::SampleFormat::Int,
    };

    let mut writer = hound::WavWriter::create("melody_struct.wav", spec)
        .expect("Failed to create WAV file");

    let sample_rate = spec.sample_rate as f32;
    let duration_secs = 8.0;
    let amplitude = i16::MAX as f32;
    let total_samples = (sample_rate * duration_secs) as usize;

    let mut osc = Oscillator::new(sample_rate, 440.0);

    for t in 0..total_samples {
        let time = t as f32 / sample_rate;

        let freq_hz = match time.ceil() {
            1.0 => 440.0,  // A4
            2.0 => 494.0,  // B4
            3.0 => 523.25, // C5
            4.0 => 587.33, // D5
            5.0 => 659.25, // E5
            6.0 => 698.46, // F5
            7.0 => 783.99, // G5
            _ => 880.0,    // A5
        };

        osc.set_frequency(freq_hz);

        let sample = (osc.next_sample() * amplitude) as i16;
        writer.write_sample(sample).unwrap();
    }

    writer.finalize().unwrap();
    println!("✅ Melody written to 'melody_struct.wav'");
}

Let’s listen and look

Build and run your code again:

cargo run

This will generate a new WAV file: melody_struct.wav.

If you open both melody_fixed.wav (from Part 2) and melody_struct.wav (this version) in Audacity and zoom in around the 5 to 6 second mark, just like we did before, you’ll notice there’s no visible difference between them — no harsh corners, no sudden jumps, and most importantly: no audible clicks.

That means our new oscillator-based approach is working exactly as intended.

Exploring waveforms

So we built a clean-sounding melody and solved a common audio issue: phase discontinuity (aka clicks). We even wrapped our sine wave logic into a reusable Oscillator.

Now, it’s time to level up.

We’re going to make our oscillator more flexible — not just locked to sine waves, but capable of generating other classic shapes too: square, sawtooth, and triangle.

Each of these waveforms sounds different and has its own harmonic profile — which gives them their character:

• Sine waves are smooth and pure.

• Sawtooth waves are bright and buzzy.

• Square waves have a hollow, woody tone.

• Triangle waves are soft but richer than sine.

The difference isn’t just in how they look — it’s in how they vibrate.

When you hear a musical note, you’re not just hearing one frequency. You’re actually hearing a blend of frequencies: the main one (called the fundamental) and a bunch of quieter ones stacked on top — called harmonics or overtones.

These harmonics are integer multiples of the fundamental frequency:

• If the fundamental is 100 Hz, you might also hear 200 Hz, 300 Hz, 400 Hz…

• Each one adds flavor and texture to the sound.

What makes each waveform unique is which harmonics are present, and how strong they are.

• Sine wave → no harmonics at all — just the fundamental. Pure and tone-like.

• Square wave → odd harmonics only (3x, 5x, 7x…), creating a hollow, flute-like sound.

• Sawtooth wave → all harmonics (1x, 2x, 3x, 4x…), giving it a bright, brassy edge.

• Triangle wave → odd harmonics too, like square, but much softer — their intensity drops off faster.

These harmonic “recipes” are what give each waveform its distinct voice. They don’t just change what we hear — they shape how we feel the sound.

Square wave

Let’s kick things off with the square wave — one of the most recognizable shapes in digital sound synthesis.

It alternates between two levels: high and low, with no gradual transition between them. That sudden flip gives it a bold, buzzy sound full of odd harmonics.

In code, it’s one of the simplest waveforms to implement:

• If the phase is in the first half of the cycle (0.0 to 0.5), output +1.0

• Otherwise, output -1.0

Let’s update our oscillator so it can generate both sine and square waves based on a selected waveform type.

To support multiple waveform shapes, we’ll define a new enum called Waveform. For now, we’ll keep it simple with just two options:

pub enum Waveform {
    Sine,
    Square,
}

We’ll now store the selected waveform in our oscillator. That way, next_sample() knows what shape to generate.

pub struct Oscillator {
    phase: f32,
    phase_increment: f32,
    sample_rate: f32,
    waveform: Waveform,
}

And we’ll update the constructor to accept the waveform as a parameter:

pub fn new(sample_rate: f32, frequency: f32, waveform: Waveform) -> Self {
    let phase_increment = frequency / sample_rate;
    Self {
        phase: 0.0,
        phase_increment,
        sample_rate,
        waveform,
    }
}

To use the square wave in your melody code, simply update the oscillator construction like this:

let mut osc = Oscillator::new(sample_rate, 440.0, Waveform::Square);

Here’s what happens inside next_sample():

pub fn next_sample(&mut self) -> f32 {
    self.phase += self.phase_increment;
    if self.phase >= 1.0 {
        self.phase -= 1.0;
    }

    match self.waveform {
        Waveform::Sine => (self.phase * TAU).sin(),
        Waveform::Square => {
            if self.phase < 0.5 {
                1.0
            } else {
                -1.0
            }
        }
    }
}

Time to test it out! Run your project to generate the new waveform.

Now open that file in Audacity:

No curves, no slopes — just straight lines up and down. That’s your square wave in action.

It’ll also sound more intense and buzzy than the smooth sine wave from before — thanks to all those odd harmonics baked into the waveform.

Saw wave

Next up is the saw (or sawtooth) wave — a bright, sharp waveform known for its aggressive tone and rich harmonic content.

It gets its name from how it looks: a straight ramp up followed by a sharp drop — just like the teeth of a saw blade.

The formula to generate a saw wave is: output = 2 × phase − 1.

Here’s what that means:

• The phase always moves from 0.0 to 1.0 in a loop — that’s one full waveform cycle.

• At the start of the cycle (phase = 0.0), we get:

  2 × 0.0 − 1 = -1.0

• In the middle (phase = 0.5):

  2 × 0.5 − 1 = 0.0

• At the end (phase = 1.0):

  2 × 1.0 − 1 = +1.0

Then the phase wraps back to 0, and the pattern repeats.

This formula gives us a linear slope from -1.0 to +1.0 over the full waveform cycle. That’s what makes the sawtooth look like a ramp — and sound bright and buzzy due to all its harmonic content.

So lets update the Waveform enum:

pub enum Waveform {
    Sine,
    Square,
    Saw,
}

Change the oscillator construction to:

let mut osc = Oscillator::new(sample_rate, 440.0, Waveform::Saw);

Update the next_sample() logic:

match self.waveform {
    // ...other variants
    Waveform::Saw => 2.0 * self.phase - 1.0,
}

Once we’ve updated the code and generated the .wav file, lets open it the editor:

By looking at it visually, you’ll immediately spot the sawtooth shape:

• A straight, linear ramp upward from -1.0 to +1.0

• Followed by a sudden vertical drop back to -1.0

• And then the cycle repeats

And of course, it sounds a lot brighter and harsher than sine or square — all thanks to its full spectrum of harmonics.

Why does the sine wave sound quieter?

You might have noticed: the sine wave sounds noticeably quieter than the square and saw waves — even though they all use the same amplitude range (-1.0 to +1.0).

That’s not a bug — it’s how sound perception works.

Here’s why:

• A square wave holds full volume for half the cycle at +1.0 and the other half at -1.0. That means its average power is very high.

• A saw wave is constantly moving, but it still spends a lot of time near high (and low) values as it ramps from -1.0 to +1.0. It also contains lots of harmonics, which adds even more perceived loudness.

• A sine wave, on the other hand, gently eases up and down in a smooth curve — spending much less time near its peak values and containing only the fundamental frequency. So even though the peak values are the same, the harmonic content makes the square and saw waves feel louder and fuller.

In real-world synths and audio engines, this is usually handled by scaling different waveforms so they have similar perceived loudness — not just matching the numbers.

You can experiment by adjusting the amplitude multiplier when writing samples, to make each waveform feel more balanced in loudness. Don’t stress about finding a perfect value — just adjust it until it feels right.

But keep in mind, a 16-bit WAV file cannot natively contain amplitude values greater than the 16-bit range.

If your signal goes beyond -1.0..1.0 before converting to i16, it will be clamped to the max value (32767 or -32768) — and this flattens the waveform’s peaks, making our sine wave look and sound more like a square wave.

It ends up looking like this:

Triangle wave

The triangle wave is a gentler cousin of the square wave.

Like the square wave, it only contains odd harmonics, but it rolls them off much faster — making it sound smoother, rounder, and less harsh.

Visually, it’s a perfect zig-zag:

• It rises steadily from -1.0 to +1.0

• Then falls back down just as steadily

To generate a triangle wave digitally, we once again rely on the phase value — which linearly moves from 0.0 to 1.0 every cycle.

The trick is to split the waveform into two halves:

• First half (0.0..0.5): the wave ramps up

• Second half (0.5..1.0): the wave ramps down

Here’s the piecewise formula:

if phase < 0.5 {
    4.0 * phase - 1.0
} else {
    -4.0 * phase + 3.0
}

In the first half, we want a linear rise from -1.0 → +1.0:

• When phase = 0.0: 4.0 * 0.0 - 1.0 = -1.0

• When phase = 0.5: 4.0 * 0.5 - 1.0 = +1.0

In the second half, we want to fall from +1.0 → -1.0:

• When phase = 0.5: -4.0 * 0.5 + 3.0 = +1.0

• When phase = 1.0: -4.0 * 1.0 + 3.0 = -1.0

The slope of +/-4.0 gives us just the right speed to move between those values in half a cycle.

So lets extend the Waveform enum again:

pub enum Waveform {
    Sine,
    Square,
    Saw,
    Triangle,
}

Then update the next_sample() method of your Oscillator struct to support it:

match self.waveform {
    // ...other variants
    Waveform::Triangle => {
        if self.phase < 0.5 {
            4.0 * self.phase - 1.0
        } else {
            -4.0 * self.phase + 3.0
        }
    }
}

And change the Oscillator construction to:

let mut osc = Oscillator::new(sample_rate, 440.0, Waveform::Triangle);

Run your project to generate the .wav file:

cargo run

Once the file is generated, open it in Audacity and you’ll see:

• A clean up–down ramp

• Peaks at +1.0 and -1.0

• Sharp corners, but not the harsh harmonics of saw/square

The result is a soft, muted tone.

🎬 Wrapping up [PART 3]

In this post, we built a reusable oscillator in Rust, explored multiple waveform shapes, and visualized how their structure affects tone and loudness. Along the way, we touched on harmonics, amplitude scaling, and how even simple math shapes sound.

But as you’ve probably guessed, our oscillator is still kind of naive, and there’s much more to explore beneath the surface.

Our waveforms are generated using simple math, which means sharp corners in square and saw waves. That leads to a common problem in digital synthesis: aliasing.

Aliasing happens when high-frequency content folds back into the audible range, creating unwanted artifacts — especially at higher pitches. It can make sounds harsher, noisier, and less realistic.

If you’re ready to go deeper, check out my crate oscy. It includes alternate oscillator implementations (like PolyBLEP) that reduce aliasing while staying CPU-friendly.

🚧 What’s next?

That wraps up our Oscillator Series!

Next up? A new series where we:

• Combine oscillators

• Add envelopes and modulation

• And build toward real-time Rust-powered synths

Stay tuned!

💾 Source code from this article:

View on GitHub →

Now it’s time to make it sing — or at least play a short melody.

We’ll modify our existing code to switch between different notes over time, building up something that feels more musical. But we’re also going to hit a snag — and that snag is going to teach us an important concept in audio programming.

Let’s dive in.

We’ll play an 8-second melody, changing the note once per second. We’ll reuse the core logic from Part 1, but adapt it to loop over an array of frequencies — one for each second.

This is a naive implementation:

use std::f32::consts::PI;

fn main() {
    // WAV file settings
    let spec = hound::WavSpec {
        channels: 1,        // mono
        sample_rate: 44100, // samples per second
        bits_per_sample: 16,
        sample_format: hound::SampleFormat::Int,
    };
    // Create a WAV writer
    let mut writer =
        hound::WavWriter::create("melody.wav", spec).expect("Failed to create WAV file");
    // Sine wave parameters
    let duration_secs = 8.0; // 2 seconds
    let amplitude = i16::MAX as f32; // max volume

    let sample_rate = spec.sample_rate as f32;
    let total_samples = (sample_rate * duration_secs) as usize;

    for t in 0..total_samples {
        let time = t as f32 / sample_rate;

        let freq_hz = match time.ceil() {
            1.0 => 440.0,  // A4
            2.0 => 494.0,  // B4
            3.0 => 523.25, // C5
            4.0 => 587.33, // D5
            5.0 => 659.25, // E5
            6.0 => 698.46, // F5
            7.0 => 783.99, // G5
            _ => 880.0,    // A5
        };

        let sample = (amplitude * (2.0 * PI * freq_hz * time).sin()) as i16;
        writer.write_sample(sample).unwrap();
    }

    writer.finalize().unwrap();
    println!("✅ Melody written to 'melody.wav'");
}

Let’s break down what we’ve changed in this version of the code:

In Part 1, we generated a single 2-second tone.

Now we’ve extended the total duration to 8 seconds so we can play eight notes, one per second:

let duration_secs = 8.0;

We keep a single loop running over all the samples:

for t in 0..total_samples {
    let time = t as f32 / sample_rate;
    let freq_hz = match time.ceil() { ... };
}

Instead of generating one note from start to finish, we now check the current time and change the frequency every second.

This lets us build a full melody from just one continuous time stream.

The rest stays the same — we’re still generating samples, writing them to a .wav file.

Let’s play our melody

Run the program with:

cargo run

You’ll see the file melody.wav pop up in your project folder. Go ahead and open it in your favorite audio player — or better yet, drop it into Audacity to listen and inspect the waveform.

At first, it’ll sound like a simple melody — but listen closely 👂 and you might hear something unexpected between the notes…

Those little clicks or pops you’re hearing between notes aren’t a bug in your system — they’re a classic issue in audio programming caused by discontinuities in the waveform.

Remember, we’re using this formula: sample = amplitude * sin(2π × frequency × time)

What that means is:

• At the end of each second, the sine wave is at a certain phase (e.g., somewhere mid-curve).

• Then, without warning, we jump to a new sine wave — starting at a totally different frequency, but continuing the same time.

The result? The waveform suddenly jumps from one value to another — and your ear hears that jump as a click.

To be smooth and click-free, a waveform should connect seamlessly — one sample to the next, with no sudden jumps in value.

But when we change the frequency without resetting or adjusting the phase, we break that continuity.

So instead of a curve that flows naturally, we get a sharp corner in the waveform — and your ear hates sharp corners.

See it for yourself (in Audacity)

By default, Audacity might show beats and measures, which isn’t helpful for our waveform timing.

To change that:

1. Look at the timeline above the waveform.

2. Click the little drop-down arrow on the left side of the timeline.

3. Select “Minutes and Seconds” from the list (instead of “Beats and Measures”).

To see the discontinuity clearly:

1. Zoom in until you’re seeing just a few milliseconds of waveform per screen.

2. Navigate to the 5 to 6 second mark (between note 6 and 7).

3. Look closely at the transition point — right around the 6.0s boundary.

🎯 You should see a clean, repeating wave suddenly jump to a new shape — no smooth transition.

Or even closer

This is the exact spot where our phase mismatch causes a discontinuity in the waveform — and that’s what we’ll fix in the next step. You can choose any transition point between notes to inspect — I picked the gap around second 6 just as an example. The same issue will appear wherever the frequency changes abruptly mid-wave.

Let’s smooth it out

We’re going to fix this with as little code change as possible — just enough to demonstrate the concept of phase continuity.

We’ll do that by:

• Tracking a persistent phase variable across the entire loop

• Using freq only to adjust how fast phase advances — not where it starts

Quick recap

As we saw earlier, using this formula: sample = amplitude * sin(2π × frequency × time) …works great until the frequency changes. Then the wave jumps because time keeps going, but the math rebuilds a brand new sine wave. The waveform doesn’t connect smoothly — and that sharp transition becomes an audible click.

The fix

Here’s our original melody code, with just a few crucial lines added:

use std::f32::consts::PI;

fn main() {
    let spec = hound::WavSpec {
        channels: 1,
        sample_rate: 44100,
        bits_per_sample: 16,
        sample_format: hound::SampleFormat::Int,
    };

    let mut writer =
        hound::WavWriter::create("melody_fixed.wav", spec).expect("Failed to create WAV file");

    let duration_secs = 8.0;
    let amplitude = i16::MAX as f32;

    let sample_rate = spec.sample_rate as f32;
    let total_samples = (sample_rate * duration_secs) as usize;

    // NEW: keep track of waveform position
    let mut phase = 0.0;

    for t in 0..total_samples {
        let time = t as f32 / sample_rate;

        let freq_hz = match time.ceil() {
            1.0 => 440.0,  // A4
            2.0 => 494.0,  // B4
            3.0 => 523.25, // C5
            4.0 => 587.33, // D5
            5.0 => 659.25, // E5
            6.0 => 698.46, // F5
            7.0 => 783.99, // G5
            _ => 880.0,    // A5
        };

        // NEW: advance phase smoothly based on current frequency
        let phase_increment = 2.0 * PI * freq_hz / sample_rate;
        phase = (phase + phase_increment) % (2.0 * PI);

        // sample now comes from continuous phase
        let sample = (amplitude * phase.sin()) as i16;
        writer.write_sample(sample).unwrap();
    }

    writer.finalize().unwrap();
    println!("✅ Melody written to 'melody_fixed.wav'");
}

If you open the new .wav file in Audacity, you’ll notice something important:

✅ No more sudden jumps in the waveform.

Even when the frequency changes, the wave connects naturally.

If you zoom in to the same transition point as before (say, between second 5 and 6), you’ll see that the waveform now flows without a visible click.

That’s phase continuity in action.

What changed?

Instead of recalculating the sine wave angle from scratch every time, we now:

• Keep a phase that tracks our position inside the waveform

• Move it forward a tiny bit for each sample, based on the current frequency

• Use sin(phase) to get the sample value

• Wrap it around once it reaches 2π to avoid overflow

What is a radian?

A radian is just a unit for measuring angles — like degrees, but more mathematically convenient.

• A full circle is 360°, right?

• In radians, a full circle is 2π radians (≈ 6.283)

So when we talk about 2π, we’re talking about one full rotation — or in waveform terms, one full sine wave cycle.

Let’s say we want to generate a 440 Hz tone (A4). That means we need to complete 440 full sine wave cycles every second.

Since one full cycle is 2π radians, we need to sweep through: 2π × 440 = 2764.6 radians per second.

That’s the total angular distance our sine wave needs to travel per second to hit that pitch.

How much to move per sample

But we don’t generate one sample per second — we generate 44100 samples per second. So we have to split that angular distance across all 44100 samples.

Here’s the math:

let phase_increment = (2.0 * PI * frequency) / sample_rate;

This gives us the tiny step we take through the wave with each sample.

Using our 440 Hz example: phase_increment ≈ 0.0627 radians per sample.

That means every sample moves us forward about 0.0627 radians through the sine wave.

And since one full wave cycle is 2π radians, we can divide: 2π / 0.0627 ≈ 100 samples.

So it takes around 100 samples to complete one full sine wave cycle at 440 Hz.

By adjusting the phase increment, we control how many samples it takes to go from 0 → 2π → back to 0.

Why % (2π)

In our code, we update the phase like this:

phase = (phase + phase_increment) % (2.0 * PI);

So why are we using modulo 2π here?

Because the sine wave is a loop.

A full sine wave cycle is exactly 2π radians — and after that, it just repeats.

That means:

• sin(0) = sin(2π) = sin(4π)

• sin(π/2) = sin(2π + π/2) = sin(4π + π/2)

• …and so on

So whether the phase is 6.3, 12.6, 18.9, etc — the result of sin(phase) will be the same shape, just wrapped around.

By keeping phase in the range 0.0..2π, we:

• Keep everything tidy

• Prevent precision drift

• Avoid weird edge cases down the line

🏁 That’s a wrap for [PART 2]

In this post, we turned our naive melody generator into something smarter and smoother.

We uncovered and explained a common problem in audio programming (clicks from phase discontinuity), and we fixed it using one of the most fundamental DSP concepts: tracking phase over time.

This technique isn’t just a trick — it’s the foundation of how digital sound generators work under the hood.

And even though we haven’t formally built an oscillator yet, we’re already using one in spirit — walking through the waveform cycle sample by sample.

🔜 What’s next?

In Part 3, we’ll finally write our first true oscillator and take things further:

• Generate different waveforms

• Compare how they sound and look

• Learn how waveform shape affects tone and harmonics

▶️ Continue to Part 3:

Rust Audio Programming: Oscillator – Exploring the waveforms [PART 3]

💾 Source code from this article:

View on GitHub →

Whether you’re a seasoned rustacean, a curious audio hacker, or just someone who thinks synths are cool — welcome aboard!

This is the Rust Audio Programming series, and today we’re diving into the basics of audio programming by building our very first sine wave — the audio equivalent of “hello, world”.

⚙️ This tutorial assumes you already have the Rust toolchain installed (via rustup). If not, check out the official install guide — setting it up is out of scope for this post.

So what digital sound is?

Sound, at its core, is a vibration in the air — pressure waves that travel to our ears. Inside, these vibrations are turned into signals that our brains understand as sound.

In the digital world, we sample these continuous waves at discrete intervals — usually thousands of times per second — and store the values as numbers.

This is known as digital audio. For example, CD-quality audio samples the waveform 44,100 times per second (44.1 kHz), capturing its shape with enough detail that it sounds smooth and natural to the human ear.

Enter the waveform

Every sound you hear — a piano note, a bird chirp, a voice — has a unique waveform. The shape of this waveform determines the character or timbre of the sound.

Waves are building blocks of synthetic sound, and they’re what we’ll be working with in this series.

What’s a note, really?

When we talk about a musical note, we're really talking about a specific frequency of vibration — how fast the air is wiggling back and forth. Each full wiggle is called a cycle.

That frequency is measured in hertz (Hz), or cycles per second. So if a sound wave vibrates 440 times in one second, it has a frequency of 440 Hz — which just happens to be the pitch of the musical note A4.

Different notes are just different frequencies:

• A lower note? Slower vibrations (lower Hz).

• A higher note? Faster vibrations (higher Hz).

So when we generate sound in code, we’re not saying “play A4” we’re saying “generate a waveform that cycles at 440 Hz.”.

Let’s try it out!

First, let’s set up a fresh Rust project for our experiment. Open your terminal and run:

cargo new sine_wave && cd sine_wave

💡 These examples use Unix-style commands (Linux/macOS). If you’re on Windows… well, you know the drill — adjust accordingly.

Before jumping into code, let’s take a second to understand what we’re actually generating.

We’re going to produce a 2-second sine wave that plays the musical note A4 — which has a frequency of 440 Hz. That means the waveform will complete 440 full cycles every second.

To represent that wave digitally, we’ll sample it — break it down into thousands of tiny values we can save to a file.

We’ll use a sample rate of 44100 Hz (standard CD quality), meaning we’ll capture 44100 samples per second. For 2 seconds of audio: 44100 samples/sec × 2 sec = 88200 samples.

To generate each sample, we’ll use the classic sine wave equation: sample = amplitude × sin(2π × frequency × time), where:

• frequency is 440.0 (A4)

• time is the current time in seconds for each sample (t / sample_rate)

• amplitude controls the volume — we’ll use the max for 16-bit audio

🧠 Isn’t the sine formula usually written differently?

In math you’ll often see it as A × sin(2πft + φ), where φ is the phase offset.

In our case, we’re starting the wave right at the beginning of its cycle, so we just set phase to zero — and skip it entirely.

Now let’s generate our very first sine wave and save it as a .wav file we can actually play and analyze.

To do that, we’ll use a single dependency: hound.

Run this in your terminal:

cargo add hound@3.5

hound is a simple Rust library for reading and writing WAV files.

Open src/main.rs and replace everything with this:

use std::f32::consts::PI;

fn main() {
    // WAV file settings
    let spec = hound::WavSpec {
        channels: 1,        // mono
        sample_rate: 44100, // samples per second
        bits_per_sample: 16,
        sample_format: hound::SampleFormat::Int,
    };
    // Create a WAV writer
    let mut writer = hound::WavWriter::create("sine.wav", spec).expect("Failed to create WAV file");
    // Sine wave parameters
    let freq_hz = 440.0; // frequency (A4)
    let duration_secs = 2.0; // 2 seconds
    let amplitude = i16::MAX as f32; // max volume

    let sample_rate = spec.sample_rate as f32;
    let total_samples = (sample_rate * duration_secs) as usize;

    for t in 0..total_samples {
        let time = t as f32 / sample_rate;
        let sample = (amplitude * (2.0 * PI * freq_hz * time).sin()) as i16;
        writer.write_sample(sample).unwrap();
    }

    writer.finalize().unwrap();
    println!("✅ Sine wave written to 'sine.wav'");
}

What’s happening in the code?

Let’s break down the essential parts:

1. WAV file setup

let spec = hound::WavSpec {
    channels: 1,
    sample_rate: 44100,
    bits_per_sample: 16,
    sample_format: hound::SampleFormat::Int,
};

We configure the .wav file to be:

• Mono audio (channels: 1)

• 44.1 kHz sample rate (standard quality)

• 16-bit samples (i.e., each sample is stored as a signed 16-bit integer)

2. Main parameters

let freq_hz = 440.0;
let duration_secs = 2.0;
let amplitude = i16::MAX as f32;

We want a 440 Hz sine wave (A4 note) that lasts 2 seconds, at maximum volume.

3. Generate samples

for t in 0..total_samples {
    let time = t as f32 / sample_rate;
    let sample = (amplitude * (2.0 * PI * freq_hz * time).sin()) as i16;
    writer.write_sample(sample).unwrap();
}

writer.finalize().unwrap();

We:

• Loop through each sample

• Use the sine wave formula to calculate its value

• Write the value to the WAV writer’s internal buffer

Then, in the next step:

• Call .finalize() to flush the buffer and write everything to the file

Now let’s actually run the code and hear what we’ve created:

cargo run

You should see:

✅ Sine wave written to 'sine.wav'

That means your .wav file was successfully generated! Now go ahead and play sine.wav using your favourite audio player.

If everything worked, you should hear a clean, steady tone — no clicks, no weird noise. That’s a pure 440 Hz sine wave, also known as concert A.

Let’s see the sound

To visualize the waveform, open sine.wav in Audacity — a free, open-source audio editor that makes it easy to zoom in and inspect waveforms.

You should see a smooth, repeating sine wave — but heads up, it might not look like much at first.

Audacity will probably show it as a solid block by default. Zoom in horizontally until you can see the individual wave cycles — that’s your sine wave in action!

🏁 That’s a wrap for [PART 1]

Congrats — you just generated your first sine wave from scratch using Rust. 🎉

You now understand:

• What digital sound is

• How sampling works

• How to generate individual audio samples using math

Not bad for one article, huh?

🔜 What’s next?

In the next part of this series, we’ll build on what we’ve made by changing the note over time — like playing a simple melody with just a sine wave.

It sounds straightforward… but we’ll run into some interesting behavior that’s worth a closer look 👀

Along the way, we’ll improve the math behind our waveform generation and start shaping the code into something more flexible and reusable.

▶️ Continue to Part 2:

Rust Audio Programming: Oscillator – Handle frequency changes smoothly [PART 2]

💾 Source code from this article:

View on GitHub →

cargo new rust_docker_app --bin
cd rust_docker_app
cargo add actix-web
touch Dockerfile

So what we've actually done here:

• created a new binary crate, called rust_docker_app

• added web framework dependency (I prefer Actix, but you can choose any)

• created empty DockerFile

Now let's create a web server with one simple health check endpoint. To do this, you need to update your main.rs file with:

use actix_web::{App, HttpServer, HttpResponse, get};

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .service(ping)
    })
    .bind(("0.0.0.0", 8080))?
    .run()
    .await
}

#[get("/ping")]
async fn ping() -> HttpResponse {
    HttpResponse::Ok().body("pong")
}

So we created an app with 0.0.0.0 address and 8080 port bindings.

0.0.0.0 is the special “all interfaces” address. You must set a docker container’s main process (Actix web app in our case) to bind to it, or it will be unreachable from outside the container.

Our app has only one endpoint, which responds with a "pong" message all the time.

Now let's update our Dockerfile with:

FROM rust:1.66.0 as build
COPY . /rust_docker_app
WORKDIR /rust_docker_app

RUN --mount=type=cache,target=/usr/local/cargo/registry --mount=type=cache,target=/root/target \
    cargo build --release

FROM debian:buster-slim as runtime
COPY --from=build /rust_docker_app/target/release/rust_docker_app .
CMD ["./rust_docker_app"]

We don't need any project files except compiled binary in our image, that's why we use multi-stage build.

You can read more about multi-stage builds here: https://docs.docker.com/build/building/multi-stage/

So what does this Dockerfile do step by step:

• copy project files to the first (build) stage

• compile the code

• copy the binary executable file from the "build" stage to the "runtime" stage, leaving behind everything else we don’t want in the final image

• run the compiled binary

This part is needed --mount=type=cache,target=/usr/local/cargo/registry for caching Rust dependencies and it defines which path should be cached as a container image layer.

Now we are ready to build our image. Simply just run the below command in the project root directory:

docker build -t rust_docker_app .

And finally, let's run our web server:

docker run -p 8080:8080 rust_docker_app

Now you can access the health check endpoint by http://127.0.0.1:8080/ping. Just try to get it via browser or CURL or any other HTTP client.

I hope you enjoy it. As always you can find working example in my GitHub repository :)

In this one, we will learn how to configure and run it on AWS.

This article is not about the CI/CD best practises. I just want to show you in a simple examples how to run and test your code on AWS lambda.

Let's go!

Create Role

Firstly, we need to create a role, that will allow our lambda functions to pop data from SQS.

Enter the AWS console roles web interface and click on the Create role button.

Choose AWS service as trusted entity and lambdas as a common use case, then click on the Next button

Attach AWSLambdaSQSQueueExecutionRole policy to your new role and click on the Next button Name your role as TestRustLambdaRole Click on the Create Role button.

Perfect! Our new role is created successfully!

Create AWS lambda function

Enter the AWS console lambdas web interface and click on the Create function button.

Then just fill in the Basic information block this way

Choose TestRustLambdaRole as a execution role of our lambda function Click on Create function button

Test AWS lambda

Build and deploy

Firstly, we need to build our code. Everything we need is to run this command

cargo lambda build --release --bin rust-lambda-example --arm64 --output-format zip

Our compiled binary will be stored in path: target/lambda/rust-lambda-example.

Then in your new lambda function web interface go to the Code section and click on Upload from -> .zip file and upload our binary

Test in AWS console

Now we need to create a test event.

Go to the Test section, and name our new test event

Then add the SQS event sample below to Event JSON block and click on the Save button

{
    "Records": [
      {
        "messageId" : "MessageID_1",
        "receiptHandle" : "MessageReceiptHandle",
        "body" : "Hello from message 1!",
        "md5OfBody" : "fce0ea8dd236ccb3ed9b37dae260836f",
        "md5OfMessageAttributes" : "582c92c5c5b6ac403040a4f3ab3115c9",
        "eventSourceARN": "arn:aws:sqs:us-west-2:123456789012:SQSQueue",
        "eventSource": "aws:sqs",
        "awsRegion": "us-west-2",
        "attributes" : {
          "ApproximateReceiveCount" : "2",
          "SentTimestamp" : "1520621625029",
          "SenderId" : "AROAIWPX5BD2BHG722MW4:sender",
          "ApproximateFirstReceiveTimestamp" : "1520621634884"
        },
        "messageAttributes" : {
          "Attribute3" : {
            "binaryValue" : "MTEwMA==",
            "stringListValues" : ["abc", "123"],
            "binaryListValues" : ["MA==", "MQ==", "MA=="],
            "dataType" : "Binary"
          },
          "Attribute2" : {
            "stringValue" : "123",
            "stringListValues" : [ ],
            "binaryListValues" : ["MQ==", "MA=="],
            "dataType" : "Number"
          },
          "Attribute1" : {
            "stringValue" : "AttributeValue1",
            "stringListValues" : [ ],
            "binaryListValues" : [ ],
            "dataType" : "String"
          }
        }
      },
      {
        "messageId" : "MessageID_2",
        "receiptHandle" : "MessageReceiptHandle",
        "body" : "Hello from message 2!",
        "md5OfBody" : "fce0ea8dd236ccb3ed9b37dae260836f",
        "md5OfMessageAttributes" : "582c92c5c5b6ac403040a4f3ab3115c9",
        "eventSourceARN": "arn:aws:sqs:us-west-2:123456789012:SQSQueue",
        "eventSource": "aws:sqs",
        "awsRegion": "us-west-2",
        "attributes" : {
          "ApproximateReceiveCount" : "2",
          "SentTimestamp" : "1520621625029",
          "SenderId" : "AROAIWPX5BD2BHG722MW4:sender",
          "ApproximateFirstReceiveTimestamp" : "1520621634884"
        },
        "messageAttributes" : {
          "Attribute3" : {
            "binaryValue" : "MTEwMA==",
            "stringListValues" : ["abc", "123"],
            "binaryListValues" : ["MA==", "MQ==", "MA=="],
            "dataType" : "Binary"
          },
          "Attribute2" : {
            "stringValue" : "123",
            "stringListValues" : [ ],
            "binaryListValues" : ["MQ==", "MA=="],
            "dataType" : "Number"
          },
          "Attribute1" : {
            "stringValue" : "AttributeValue1",
            "stringListValues" : [ ],
            "binaryListValues" : [ ],
            "dataType" : "String"
          }
        }
      }
    ]
  }

The next thing we should do to make the code from previous article work is to add environment variable

After that let's move back to Code section. Here just choose our new test event and click on the Test button As you can see, the output is the same as in local test from a first article. Our lambda is working!

Function Logs
START RequestId: 56cbfd84-3601-4c13-9da6-84b94aed972a Version: $LATEST
test
Hello from message 1!
Hello from message 2!
END RequestId: 56cbfd84-3601-4c13-9da6-84b94aed972a
REPORT RequestId: 56cbfd84-3601-4c13-9da6-84b94aed972a    Duration: 0.99 ms    Billed Duration: 19 ms    Memory Size: 128 MB    Max Memory Used: 13 MB    Init Duration: 17.17 ms

Connect lambda with SQS events

Create SQS queue with default settings by filling in the name

and pressing Create queue button

Next, go back to your lambda function interface and add a new trigger

Select SQS as a source

and our new created queue

Then add this trigger to our lambda function

To test that everything works as expected let's decrease trigger batch size to 1

and then move back to your SQS web interface and click on send and receive messages button

And push a test message to the queue

Then go to the Monitor -> logs section in your lambda function interface

Here you can see that our lambda handled the new message

The Lambda functions can perform any kind of computing task, from serving web pages and processing streams of data to calling APIs and integrating with other AWS services, like SQS, Kinesis etc.

In case of this article, we will create SQS consumer, running on AWS lambda.

SQS stands for Simple Queue Service, which means a web service that gives you access to a message queue that can be used to store messages while waiting for a computer to process them.

SQS can be used as a classic pub/sub queue solution, and it can support the First In First Out principle if needed.

More about SQS you can find on official amazon pages.

How to create a lambda code

Cargo gives us a beautiful helper command to deal with Rust and AWS Lambda, called cargo-lamda.

We need to install it by running cargo install cargo-lambda.

After that let's create our first lambda project with cargo lambda new rust-lambda-example.

After running this command, you need to answer a few questions to help cargo-lambda create the needed template.

As I mentioned earlier, our goal is to create an SQS consumer (a rust lambda that is triggered by SQS events), so your answers should be like:

cargo lambda new rust-lambda-example
? Is this function an HTTP function? No
? AWS Event type that this function receives sqs::SqsEvent

Let's take a look at new template!

Your new template should look something like the one below.

I've removed all comments and annotations and some blocks of code to make the most basic example, so don't worry if your code might look a bit different.

use aws_lambda_events::event::sqs::SqsEvent;
use lambda_runtime::{run, service_fn, Error, LambdaEvent};

async fn function_handler(event: LambdaEvent<SqsEvent>) -> Result<(), Error> {
    Ok(())
}

#[tokio::main]
async fn main() -> Result<(), Error> {
    run(service_fn(function_handler)).await
}

function_handler is a function that will handle every event, that's a "heart" of our future lambda.

You can easily pass additional parameters to your function_handler function by changing the code like this.

async fn function_handler(
    event: LambdaEvent<SqsEvent>,
    conn: &SomeConnection,
) -> Result<(), Error> {
    Ok(())
}

#[tokio::main]
async fn main() -> Result<(), Error> {
    let conn = SomeConnection {}; // an abstract example, replace it with the real one if needed

    run(service_fn(|event: LambdaEvent<SqsEvent>| {
        function_handler(event, &conn)
    }))
    .await
}

Let's have a quick look at our dependencies in Cargo.toml

[dependencies]
aws_lambda_events = { version = "0.6.3", default-features = false, features = ["sqs"] }
lambda_runtime = "0.6.0"
tokio = { version = "1", features = ["macros"] }

Here we see the awslabs lambda runtime, built on tokio runtime and aws_lambda_events crate, which provides a collection of common AWS events structs.

Ok, let's teach our handler to print all SQS messages bodies, by adding simple code to our handler

async fn function_handler(event: LambdaEvent<SqsEvent>) -> Result<(), Error> {
    event
        .payload
        .records
        .into_iter()
        .filter_map(|m| m.body) // since body is optional, we want to skip all None values
        .for_each(|m| println!("{m}"));

    Ok(())
}

How to test it locally

Write a simple test

First, let's add a new dependency, a well-known json library called serde-json. Add this line to our Cargo.toml dependencies block: serde_json = "~1.0.59".

Next. let's create some test dataset:

1. Create a "fixtures" folder
2. Create "example-sqs-event.json" file into this folder
3. Fill "example-sqs-event.json" file with the data below

   {
    "Records": [
      {
        "messageId" : "MessageID_1",
        "receiptHandle" : "MessageReceiptHandle",
        "body" : "Hello from message 1!",
        "md5OfBody" : "fce0ea8dd236ccb3ed9b37dae260836f",
        "md5OfMessageAttributes" : "582c92c5c5b6ac403040a4f3ab3115c9",
        "eventSourceARN": "arn:aws:sqs:us-west-2:123456789012:SQSQueue",
        "eventSource": "aws:sqs",
        "awsRegion": "us-west-2",
        "attributes" : {
          "ApproximateReceiveCount" : "2",
          "SentTimestamp" : "1520621625029",
          "SenderId" : "AROAIWPX5BD2BHG722MW4:sender",
          "ApproximateFirstReceiveTimestamp" : "1520621634884"
        },
        "messageAttributes" : {
          "Attribute3" : {
            "binaryValue" : "MTEwMA==",
            "stringListValues" : ["abc", "123"],
            "binaryListValues" : ["MA==", "MQ==", "MA=="],
            "dataType" : "Binary"
          },
          "Attribute2" : {
            "stringValue" : "123",
            "stringListValues" : [ ],
            "binaryListValues" : ["MQ==", "MA=="],
            "dataType" : "Number"
          },
          "Attribute1" : {
            "stringValue" : "AttributeValue1",
            "stringListValues" : [ ],
            "binaryListValues" : [ ],
            "dataType" : "String"
          }
        }
      },
      {
        "messageId" : "MessageID_2",
        "receiptHandle" : "MessageReceiptHandle",
        "body" : "Hello from message 2!",
        "md5OfBody" : "fce0ea8dd236ccb3ed9b37dae260836f",
        "md5OfMessageAttributes" : "582c92c5c5b6ac403040a4f3ab3115c9",
        "eventSourceARN": "arn:aws:sqs:us-west-2:123456789012:SQSQueue",
        "eventSource": "aws:sqs",
        "awsRegion": "us-west-2",
        "attributes" : {
          "ApproximateReceiveCount" : "2",
          "SentTimestamp" : "1520621625029",
          "SenderId" : "AROAIWPX5BD2BHG722MW4:sender",
          "ApproximateFirstReceiveTimestamp" : "1520621634884"
        },
        "messageAttributes" : {
          "Attribute3" : {
            "binaryValue" : "MTEwMA==",
            "stringListValues" : ["abc", "123"],
            "binaryListValues" : ["MA==", "MQ==", "MA=="],
            "dataType" : "Binary"
          },
          "Attribute2" : {
            "stringValue" : "123",
            "stringListValues" : [ ],
            "binaryListValues" : ["MQ==", "MA=="],
            "dataType" : "Number"
          },
          "Attribute1" : {
            "stringValue" : "AttributeValue1",
            "stringListValues" : [ ],
            "binaryListValues" : [ ],
            "dataType" : "String"
          }
        }
      }
    ]
   }
   

   So your project should look like

Now let's write a test! Add this block of code to the end of your main file.

#[cfg(test)]
mod tests {
    use super::*;

    #[tokio::test]
    async fn test_function_handler() {
        let data = include_bytes!("fixtures/example-sqs-event.json");
        let parsed: SqsEvent = serde_json::from_slice(data).unwrap();
        let context = lambda_runtime::Context::default();
        let event = LambdaEvent::new(parsed, context);

        function_handler(event).await.expect("failed to handle event");
    }
}

After running the test, output should be:

running 1 test
Hello from message 1!
Hello from message 2!
test tests::test_function_handler ... ok

Great! Our handler is working as expected!

Emulate

cargo lambda start command emulates the AWS Lambda control plane API.

Run this command at the root of the project and you will see such output

INFO invoke server listening on 127.0.0.1:9000

Now while our lambda is working, let's try to send an event to it by running cargo lambda invoke rust-lambda-example --data-file src/fixtures/example-sqs-event.json in a separate window.

After invoking lambda, the output should be updated by something like this

 INFO starting lambda function function="rust-lambda-example"
[Running 'cargo run --bin rust-lambda-example']
   Compiling rust-lambda-example v0.1.0 ({your_path}/rust-lambda-example)
    Finished dev [unoptimized + debuginfo] target(s) in 2.37s
     Running `target/debug/rust-lambda-example`
Hello from message 1!
Hello from message 2!

Cool! That works.

AWS lambda Environment variables

Let's imagine that we need to use AWS lambda environment variables. How should we test it locally?

Easy! You just need to work with them like with classic Rust environment variables!

Let's update our main file with

async fn main() -> Result<(), Error> {
    let env_var = std::env::var("MODE").expect("Environment error");
    println!("{env_var}");

    run(service_fn(function_handler)).await
}

and then rerun our API emulation with MODE=test cargo lambda start.

Let's try to send an event again with lambda invoke rust-lambda-example --data-file src/fixtures/example-sqs-event.json.

The output will be

[Running 'cargo run --bin rust-lambda-example']
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/rust-lambda-example`
test
Hello from message 1!
Hello from message 2!

Not surprising, but it works!

The next step is to configure and run our code on AWS lambda, so let's move to the next article.

P.S. You can find a working example on my GitHub repository :)

OK, lets go!

In Rust to run code asynchronously you should start the block or function with async keyword. Async keyword transforms block of code into a state machine that implements a trait called Future. A future represents an asynchronous computation. For example

async fn one() -> u32 {
   1
}

is the same as

fn one() -> impl Future<Output=u32> { 
   async { 1 } 
}

Async bodies are lazy: they do nothing until they are run. The most common way to run a Future is to .await it. .await can be used inside an async function, otherwise you should use thread-blocking operations like futures::executor::block_on to run the future, but it is not important, since in this article we will work with async code only.

To allow async main function, you need to choose runtime for running our asynchronous program. In this example i will use Tokio runtime. So let`s start with adding this line to our Cargo.toml file into dependencies section.

tokio = { version = "1.15.0", features = ["full"] }

It is easy to make our main function async with tokio, we just need to mark function to be executed by selected runtime this way:

use tokio;

#[tokio::main]
async fn main() {}

Let`s write simple async function that we will use for future testing of our code

async fn task(name: &str, long: bool) {
    println!("Executing {}", name);

    if long {
        tokio::time::sleep(Duration::from_secs(1)).await;
    }

    println!("{} executed", name);
}

Name argument is needed here for user-friendly output of our program.

Long argument stands for if the function gets blocked for a second during its execution.

Note that we will use tokio::time::sleep here instead of std::thread::sleep as std::thread::sleep is thread-blocking operation and will block all the thread instead of allowing other tasks to run if the future is currently unable to make progress.

Update main function with this code and then try to run it

use tokio;
use std::time::Duration;

#[tokio::main]
async fn main() {
    task("Long Task 1", true).await;
    task("Short Task 1", false).await;
    task("Long Task 2", true).await;
    task("Short Task 2", false).await;
}

As a result we will have such output:

Executing Long Task 1
Long Task 1 executed
Executing Short Task 1
Short Task 1 executed
Executing Long Task 2
Long Task 2 executed
Executing Short Task 2
Short Task 2 executed

As you can see all tasks here were executed consistently, short tasks were waiting for a long ones to be executed. This is definitely not what we wanted.

Let`s improve our code to run the tasks concurrently. To achieve our goal, we need to add a new dependency to our Cargo.toml file.

Add this line to dependencies section:

futures = "0.3.5"

The futures crate provides a number of core abstractions for writing asynchronous code. In our case we will need futures::future::join_all functionality. join_all function creates a future which represents a collection of the outputs of the futures given.

The returned future will drive execution for all of its underlying futures, collecting the results into a destination Vec<T> in the same order as they were provided.

So lets rewrite our main function. Now we need to collect our tasks futures into vector and then execute them via join_all function.

use tokio;
use std::time::Duration;
use futures;

#[tokio::main]
async fn main() {
    let mut futures = Vec::new();

    futures.push(task("Long Task 1", true));
    futures.push(task("Short Task 1", false));
    futures.push(task("Long Task 2", true));
    futures.push(task("Short Task 2", false));

    futures::future::join_all(futures).await;
}

And if we run it, the output will be:

Executing Long Task 1
Executing Short Task 1
Short Task 1 executed
Executing Long Task 2
Executing Short Task 2
Short Task 2 executed
Long Task 1 executed
Long Task 2 executed

As you can see, long blocked tasks yield to a small ones!

Our code works concurrently as we expected!

You can find all working examples on my GitHub repository :)