Software Developer (C++/Audio) — Answers

Arithmetic mean

I'm returning a small struct with the mean plus a validity flag, so the empty case has a clear answer rather than dividing by zero or returning a misleading 0.

#include <vector>
#include <iostream>

struct MeanReturn
{
    float mean;
    bool isValid;
};

MeanReturn meanFinder(const std::vector<float>& numbers)
{
    MeanReturn result;

    if (numbers.empty())
    {
        result.isValid = false;
        result.mean = 0.0f;
        return result;
    }

    float runningTotal = 0.0f;
    for (float number : numbers)
        runningTotal += number;

    result.mean = runningTotal / numbers.size();
    result.isValid = true;
    return result;
}

int main()
{
    MeanReturn r = meanFinder({2.0f, 4.0f, 6.0f});
    if (r.isValid) std::cout << "Mean: " << r.mean << "\n";   // Mean: 4

    MeanReturn empty = meanFinder({});
    if (!empty.isValid) std::cout << "Empty collection - no mean\n";
}

Parse a test method name into English

public void testCowsCanBeMilked()
public void testSheepAreNotTheOnlyFruit()

"Cows can be milked"
"Sheep are not the only fruit"

Approach: pull out just the method name from the signature, drop the test prefix, split into words wherever there's a capital letter, then keep the first word's capital and lowercase the rest.

#include <string>
#include <vector>
#include <cctype>
#include <iostream>

std::string parseFunction(const std::string& signature)
{
    // grab just the method name - it sits between the last space and the '('
    std::size_t start = signature.find_last_of(' ');
    std::size_t end   = signature.find('(');
    std::string name  = signature.substr(start + 1, end - start - 1);

    // drop the "test" prefix
    const std::string prefix = "test";
    if (name.rfind(prefix, 0) == 0)
        name = name.substr(prefix.size());

    // split into words at each capital letter
    std::vector<std::string> words;
    std::string currentWord;
    for (char c : name)
    {
        if (std::isupper(c) && !currentWord.empty())
        {
            words.push_back(currentWord);
            currentWord.clear();
        }
        currentWord += c;
    }
    if (!currentWord.empty())
        words.push_back(currentWord);

    // first word keeps its capital, the rest go lowercase, joined by single spaces
    std::string result;
    for (int i = 0; i < words.size(); ++i)
    {
        std::string word = words[i];
        if (i > 0)
        {
            for (char& ch : word)
                ch = std::tolower(ch);
            result += ' ';
        }
        result += word;
    }
    return result;
}

int main()
{
    std::cout << parseFunction("public void testCowsCanBeMilked()") << "\n";
    std::cout << parseFunction("public void testSheepAreNotTheOnlyFruit()") << "\n";
    // Cows can be milked
    // Sheep are not the only fruit
}

Which depend on a #include vs a forward declaration

class widget
{
    ...
};

class fubar : public widget          // 1
{
    void value_parameter(widget );          // 2
    void ref_parameter(widget &);           // 3
    void ptr_parameter(widget *);           // 4

    virtual void value_parameter(widget );  // 5
    virtual void ref_parameter(widget &);   // 6
    virtual void ptr_parameter(widget *);   // 7

    widget value_return();                  // 8
    widget & ref_return();                  // 9
    widget * ptr_return();                  // 10

    widget instance_value_member;           // 11
    widget & instance_ref_member;           // 12
    widget * instance_ptr_member;           // 13

    static widget static_value_member;      // 14
    static widget & static_ref_member;      // 15
    static widget * static_ptr_member;      // 16
};

The rule throughout: you only need the full #include when the compiler has to know widget's actual size or layout. If it only needs to know the name exists, a forward declaration (class widget;) is enough.

Only two need the include:

• #1, the inheritance — fubar embeds widget as a base, so the compiler needs widget's full layout to build fubar.
• #11, the by-value member — that member lives inside every fubar, so fubar's size depends on widget's size. Needs the full type.

Everything else is fine with a forward declaration:

• Anything that's a pointer or reference (params #3 #4 #6 #7, returns #9 #10, members #12 #13 #15 #16) is just an address, so the compiler doesn't need to look inside widget.
• The by-value params and returns (#2 #5 #8) are also fine with a forward declaration. You only need the complete type where the function is actually defined or called, not where it's declared. virtual doesn't change that.

The sneaky one is #14, the static by-value member. It looks identical to #11 but does NOT need the include, because a static member is only declared inside the class. Its real definition lives in the .cpp, and that's the file that needs the include. So forward declaration in the header, include in the .cpp.

Other ways fubar could depend on widget: calling widget's methods, accessing its members, constructing or destroying it, deleteing a widget* (delete needs the full type to run the destructor), sizeof(widget), or using it as a template argument. All of those need the complete type at the point of use.

Code review — FileStar

class FileStarError
{
public:
    FileStarError(const char *e)
    {
        message=e;
    }
    const char *what() { return message; }

    const char *message;
};

class FileStar
{
public:
    FileStar(const char *fn, const char *m="r")
    {
        filename=strdup(fn);
        f=fopen(fn,m);

        if (f==NULL)
        {
            throw FileStarError("Error opening file");
        }
    }

    ~FileStar()
    {
        delete [] filename;
        if (fclose(f)<0)
        {
            throw FileStarError("Error closing file");
        }
    }

    void read(char *buf, int size)
    {
        if (fread(buf, 1, size, f)!=size)
        {
            throw FileStarError("Error reading from file");
        }
    }

    const char *filename;
    FILE *f;
};

Comments I'd feed back:

Reacting immediately when pre-calc takes 100s of ms

The pre-calc can never run on the audio thread — it would blow the buffer deadline and you'd get a glitch. So the concepts are:

Do the heavy pre-calculation on a background/worker thread, off the audio thread entirely. The audio thread carries on producing sound using its current settings the whole time it's running.

Hand the finished result over to the audio thread lock-free, because taking a lock on the audio thread is itself blocking (unbounded wait, plus priority-inversion risk). That's an atomic pointer swap, or an SPSC FIFO for streaming smaller messages. The worker builds the whole new thing off to the side and publishes it with a single atomic operation, so the audio thread only ever sees the old complete result or the new complete one.

Bridge the gap while the calc runs: keep using the old processor until the new one is ready, and crossfade over to it when it arrives so there's no click at the switchover.

The mental model is that the audio thread is never waiting on anything — it's always running either the old thing or the freshly published new thing.

Measuring true (inter-sample) peak

Sample peak just looks at the actual sample values and takes the highest one. The problem is that the waveform leaving the DAC is reconstructed between the samples, and that reconstructed curve can overshoot above the highest sample. Those are inter-sample peaks, and it means a signal that reads exactly 0 dBFS on its samples can still clip the converter.

To catch them you reconstruct what happens between the samples: oversample the signal (typically 4×) using interpolation / a low-pass filter, which fills in the in-between values, then take the peak of that upsampled signal. That reveals the overshoots the raw samples hid.

This is basically what the ITU-R BS.1770 true peak measurement specifies — oversample by at least 4× and measure the max of the reconstructed signal. More oversampling is more accurate, but 4× is the standard practical amount.

Architecture for device, mixer, plugins

The idea is to use interfaces at the two swappable points — the audio device and the plugins — so concrete implementations plug in without the engine or mixer needing to know about them. Same thinking as dependency inversion: the high-level parts depend on abstractions, not on specific devices or plugins.

        +------------------+
        |   AudioEngine    |   owns + drives everything
        +------------------+
                 |
                 | talks to an interface, not a specific device
                 v
        +------------------+
        |  IAudioDevice    |   interface: open / close / start / callback
        +------------------+
            ^          ^
            |          |        concrete backends implement it
   +----------------+ +----------------+
   | CoreAudioDevice| |   AsioDevice   |
   +----------------+ +----------------+

   audio from the device callback passes through:

        +------------------+
        |     Mixer        |   sums / routes channels
        +------------------+
                 | hosts a list of...
                 v
        +------------------+
        |    IPlugin       |   interface: process(buffer) / setParam / prepare
        +------------------+
            ^          ^
            |          |        concrete plugins implement it
   +----------------+ +----------------+
   |  ReverbPlugin  | |    EqPlugin    |
   +----------------+ +----------------+

Flow: the AudioEngine grabs one of the installed devices through the IAudioDevice interface, so it doesn't care which one it is. The device fires its callback (on its own high-priority thread), audio passes through the Mixer, and the Mixer runs its plugin chain by calling process() on each plugin through the common IPlugin interface.

Why interfaces in both spots: you can add a new device backend or a new plugin just by implementing the interface, without touching the engine or the mixer. It also lets you drop in a mock device or mock plugin for testing.