Q:

Delay between consecutive calls to Console. Beep()

I am trying to make a simple program that generates a tone that can vary based on an input value.  I want to sue the Console. Beep() function since it appears to be the simplest solution but am running into a problem.  I noticed that when I call the Console.beep() function consecutively, like this:
System. Console. Beep(440, 500);
System. Console. Beep(460, 500);
System. Console. Beep(480, 500);

That there is a small delay (maybe 100-200 ms or so) or so between when the current tone stops and the next starts.  I'm wondering if there is any way to reduce this delay so that the tone will not appear to be momentarily pausing whenever the frequency is updated? 

A:

When attempting to understand why .NET acts in an undesirable way, it's often helpful to check out the source code for .NET Core on GitHub.   Looking at the source code for Console. Beep:
    public static void Beep(int frequency, int duration)
    {
        ConsolePal. Beep(frequency, duration);
    }

There are two implementations for ConsolePal: one for Windows, another for Unix-like systems.   Assuming you're on Windows, let's take a look at the Beep implementation in ConsolePal.Windows.cs:
    public static void Beep(int frequency, int duration)
    {
        const int MinBeepFrequency = 37;
        const int MaxBeepFrequency = 32767;

        if (frequency < MinBeepFrequency || frequency > MaxBeepFrequency)
            throw new ArgumentOutOfRangeException(nameof(frequency), frequency, SR.Format(SR.ArgumentOutOfRange_BeepFrequency, MinBeepFrequency, MaxBeepFrequency));
        if (duration <= 0)
            throw new ArgumentOutOfRangeException(nameof(duration), duration, SR.ArgumentOutOfRange_NeedPosNum);

        Interop. Kernel32.Beep(frequency, duration);
    }

The key line here is the call to Interop. Kernel32.Beep.   This is a strong indicator that we're about to call into the native Windows API, but let's verify that.   Interop. Kernel32 is split over a bunch of files--normally this might pose some difficulty for us, but it just so happens that the first one in the list is Interop. Beep.cs--convenient! 
Opening the file, our suspicions about the native call are confirmed:
    [DllImport(Libraries. Kernel32, SetLastError = true)]
    internal static extern bool Beep(int frequency, int duration);

This is using a technique called Platform Invoke, usually abbreviated to P/Invoke.   There's a great site, pinvoke.net, that provides common P/Invoke snippets, as well as some accompanying implementation.   Let's see what pinvoke.net has to say about Beep in kernel32.dll:

Unlike MessageBeep, this function is synchronous. ( It doesn’t return control to its caller until the sound finishes.) 

Since there's nothing else in your code or Console. Beep that would cause a delay, this means the Windows API is probably the culprit.   Fortunately, pinvoke.net provides a workaround that will likely work.   Just to make sure, let's check out MSDN's documentation on Windows' Beep, to which pinvoke.net conveniently links.   It comes with some pretty fascinating history on Beep, as well as a recommendation to switch to MessageBeep. 
Unfortunately, the MSDN documentation for MessageBeep brings disappointment: we can't use it to generate an arbitrary tone. 
This brings us to our ultimate conclusion: kernel32's Beep isn't really meant for generating fancy sounds.   It's both hardware- and platform-dependent, neither of which are ideal if you're trying to generate consistent sounds across a wide variety of devices.   It's essentially a relic of the past; it was even removed in Windows XP, though it was later added back with Windows 7.   This means .NET's Console. Beep(int, int) has all the same issues, since it's just a wrapper around kernel32's Beep. 
A more robust solution would be to look into various audio frameworks, but these will likely be a lot more complicated.   For now, if you're just starting with C# and want to keep things simple, you're probably stuck with inconsistencies such as the delays you're observing.