C++ в аудиопотоке: выделение памяти, общие объекты и инструменты JUCE

Хост вызывает processBlock плагина (plug-in)?плагин (plug-in) — Программный модуль эффекта или инструмента, который загружается в DAW или другую программу-хост и обрабатывает переданные ему аудиоблоки. сотни раз в секунду, и у каждого вызова есть срок. При 48 000 Гц и блоке в 128 кадров это около 2,67 мс: к этому моменту звуковой карте нужен готовый блок. Если обработка не успела, наступает опустошение буфера (buffer underrun)?опустошение буфера (buffer underrun) — Ситуация при воспроизведении, когда устройству уже нужны следующие аудиоданные, а программа ещё не подготовила их. Может вызвать щелчок или прерывание звука., и слушатель слышит щелчок или короткое выпадение звука. Значение имеет худшее время выполнения: функция, которая обычно занимает 0,1 мс, но раз в несколько минут ждёт 20 мс, испортит запись. Такая ошибка редко проявляется в коротком тесте на компьютере разработчика. Она появляется в большом проекте у пользователя, когда процессор и диск заняты другими дорожками.

Поэтому код, который выполняется на каждом блоке, пишут по отдельным правилам: не создают и не удаляют объекты, не ждут другие потоки и не обращаются к диску. Эта статья продолжает «Кто владеет объектом» и разбирает, какой код плагина где выполняется, почему new и delete нельзя вызывать в processBlock, где готовить память и как проверить, что её никто не выделяет. Затем — как передать данные интерфейсу, как подменить целый объект без std::shared_ptr, какие классы владения есть в JUCE и что сообщает детектор утечек. Примеры, как и в статье о владении, взяты из учебного плагина тремоло (tremolo)?тремоло (tremolo) — Эффект периодического изменения амплитуды аудиосигнала. Скорость пульсации задаёт частота управляющего генератора, а диапазон усиления зависит от глубины и способа её преобразования. официального курса JUCE (папка complete, JUCE 8.0.12, C++23); API сверено с JUCE 9.0.3.

Два потока плагина

Аудиопоток (audio thread)?аудиопоток (audio thread) — Поток с повышенным приоритетом, который вызывает обработку звука для каждого блока. Каждый вызов должен закончиться до срока блока, поэтому в нём не выделяют память, не берут блокировки и не обращаются к диску. создаёт хост или аудиодрайвер. Он работает с повышенным приоритетом и для каждого блока вызывает processBlock, то есть аудиоколбэк (audio callback)?аудиоколбэк (audio callback) — Функция, которую аудиосистема вызывает для передачи очередного блока входных данных и получения выходных. Обработчик должен завершиться до срока, когда нужны данные. плагина. Поток сообщений (message thread)?поток сообщений (message thread) — Главный поток программы на JUCE: обрабатывает ввод, перерисовывает окна и выполняет таймеры. Срока блока у него нет, поэтому здесь создают и удаляют объекты и читают файлы. — главный поток программы: он обрабатывает мышь и клавиатуру, перерисовывает окна и выполняет таймеры. Срока у него нет: если перерисовка задержится на 30 мс, пользователь увидит лёгкое подёргивание, но звук не прервётся.

В курсе это видно на примере GuiAndAudioThreadIdPrinting: компонент печатает идентификатор текущего потока в конструкторе, в paint, resized, при нажатии кнопки и в аудиоколбэке getNextAudioBlock. Все вызовы, кроме аудиоколбэка, идут из одного потока, а getNextAudioBlock — из другого.

В плагине распределение задаёт хост, и JUCE обещает не всё. processBlock всегда вызывается из аудиопотока; документация AudioProcessor прямо запрещает в нём любые обращения к интерфейсу. Редактор и все компоненты работают только в потоке сообщений. Конструктор процессора, prepareToPlay, releaseResources, сохранение и загрузка состояния обычно тоже приходят из потока сообщений, но конкретный поток не гарантирован. Зато они вызываются при подготовке, а не на каждом блоке, и срока блока у них нет. Значения параметров хост может менять из любого потока, в том числе из аудиопотока при воспроизведении автоматизации. Поэтому JUCE хранит значение параметра в std::atomic<float>, а документация слушателей параметров требует, чтобы обработчик был потокобезопасным и не блокировался.

Отсюда правило для кода плагина: всё, что вызывается на каждом блоке, должно уложиться в срок; всё, что вызывается один раз при подготовке или по действию пользователя, может работать дольше. Рисунок 1 показывает оба потока на одной оси времени.

Почему в processBlock нельзя использовать new и delete

Ожидание чужого потока осложняется приоритетами. Поток интерфейса работает с обычным приоритетом, и ОС может прервать его ради любой другой программы, пока он держит блокировку аллокатора. Аудиопоток с высоким приоритетом в это время стоит и ждёт. Эта ситуация называется инверсией приоритетов (priority inversion)?инверсия приоритетов (priority inversion) — Ситуация, когда поток с высоким приоритетом ждёт ресурс, который держит поток с низким приоритетом, а того прерывают другие задачи. Срочная работа начинает зависеть от несрочной.: срочная работа зависит от несрочной.

Удаление так же опасно, как создание: delete возвращает память тому же аллокатору. При этом в коде слова delete может и не быть. unique_ptr::reset() удаляет объект сразу (таблица 1 в статье «Кто владеет объектом»), а локальный std::unique_ptr удаляет его при выходе из функции. Если это происходит внутри processBlock, память освобождается в аудиопотоке.

Скрытые выделения

Чаще всего память выделяют удобные классы стандартной библиотеки и JUCE, внутри которых есть new и delete. Таблица 1 собирает типичные случаи. Каждое выделение в ней подтверждено проверкой из раздела «Как проверить».

Где выделять память

Бенсина предлагает самое простое решение: выделить всё заранее. Для этого у процессора есть prepareToPlay(sampleRate, expectedMaxFramesPerBlock): хост вызывает её до начала воспроизведения и сообщает частоту дискретизации (sample rate)?частота дискретизации (sample rate) — Число отсчётов в каждом канале за одну секунду, то же число кадров аудиоданных в секунду. Измеряется в герцах: 44 100 Гц означает 44 100 отсчётов на канал в секунду. и наибольший ожидаемый размер блока. В учебном плагине prepareToPlay передаёт эти значения частям процессора:

// PluginProcessor.cpp
void PluginProcessor::prepareToPlay(double sampleRate,
                                    int expectedMaxFramesPerBlock) {
  currentSampleRate = sampleRate;

  tremolo.prepare(sampleRate, expectedMaxFramesPerBlock);

  bypassTransitionSmoother.prepare(
      {.sampleRate = sampleRate,
       .maximumBlockSize = static_cast<uint32_t>(expectedMaxFramesPerBlock),
       .numChannels = static_cast<uint32_t>(juce::jmax(
           getTotalNumInputChannels(), getTotalNumOutputChannels()))});
}

BypassTransitionSmoother::prepare выделяет буфер для копии необработанного сигнала: dryBuffer.setSize(numChannels, maximumBlockSize). При каждом блоке setDryBuffer только копирует в него отсчёты (sample)?отсчёт (sample) — Значение сигнала в один момент дискретизации, одно число. В звукозаписи его также называют сэмплом.. Класс Tremolo готовит рабочий массив под значения LFO (low-frequency oscillator, LFO)?низкочастотный генератор (low-frequency oscillator, LFO) — Генератор медленно повторяющегося управляющего сигнала, которым изменяют параметры звука, например усиление, частоту или панораму. Общей строгой верхней границы частоты у LFO нет. с четырёхкратным запасом:

// Tremolo.h, Tremolo::prepare
lfoSampleFifo.prepare(sampleRate);
lfoTransitionSmoother.reset(sampleRate, 0.025 /* 25 milliseconds */);

// allocate defensively
lfoSamples.resize(4u * static_cast<size_t>(expectedMaxFramesPerBlock));

Запас нужен потому, что expectedMaxFramesPerBlock — только подсказка. Документация JUCE называет её «strong hint» и советует программировать с оглядкой на хост с ошибкой, который пришлёт блок больше обещанного. Вариант обработки processChannelwise, который пользуется этим массивом, дополнительно ограничивает число кадров размером массива и проверяет это условие через jassert в отладочной сборке: лучше обработать часть блока, чем писать за границу массива.

Обратная пара — releaseResources(): хост вызывает её после остановки воспроизведения. Здесь можно освободить большие буферы. В учебном плагине она только сбрасывает состояние: tremolo.reset() и bypassTransitionSmoother.reset(). Память остаётся выделенной до следующего prepareToPlay или до удаления процессора.

Как проверить

Выделение памяти в аудиопотоке не видно ни по тексту программы, ни по звуку на пустом проекте. Его находит RealtimeSanitizer (RTSan)?RealtimeSanitizer (RTSan) — Инструмент Clang начиная с версии 20: при сборке с -fsanitize=realtime сообщает о выделении памяти, блокировках и других небезопасных вызовах внутри функций с атрибутом [[clang::nonblocking]]. — инструмент компилятора Clang, который появился в Clang 20 и работает на macOS и Linux (документация LLVM). Функцию, которая должна уложиться в срок, помечают атрибутом [[clang::nonblocking]], а программу собирают с флагом -fsanitize=realtime. Если во время выполнения такой функции вызывается malloc, free, pthread_mutex_lock или другая функция с непредсказуемым временем, санитайзер печатает стек вызовов и завершает программу.

#include <vector>

std::vector<float> history;

void process(float* samples, int numSamples) [[clang::nonblocking]]
{
    for (int i = 0; i < numSamples; ++i)
        history.push_back(samples[i]);  // может выделить память
}

int main()
{
    float block[512] {};
    process(block, 512);
}

$ clang++ -std=c++23 -fsanitize=realtime -g rt.cpp -o rt && ./rt
==77027==ERROR: RealtimeSanitizer: unsafe-library-call
Intercepted call to real-time unsafe function `malloc` in real-time context!
    ...
    #14 ... in std::vector<float>::push_back(float const&) vector.h:462
    #15 ... in process(float*, int) rt.cpp:8
    #16 ... in main rt.cpp:14

Если перед вызовом сделать history.reserve(1024), сообщения нет. Так же проверены остальные строки таблицы 1: unique_ptr::reset() и удаление последней копии std::shared_ptr дают free, присваивание std::function лямбды с массивом из восьми float в захвате — malloc, DBG — malloc внутри juce::String. Копирование std::shared_ptr, у которого остаются другие владельцы, санитайзер пропускает: оно только увеличивает счётчик.

target_compile_options(TremoloCoursePlugin PRIVATE -fsanitize=realtime)
target_link_options(TremoloCoursePlugin PRIVATE -fsanitize=realtime)

Мы не встраивали санитайзер в плагин, загруженный в DAW. Вместо этого собрали консольную программу с JUCE 8.0.12 и исходниками учебного плагина: она создаёт PluginProcessor, вызывает prepareToPlay(48000, 512), а затем 400 раз processBlock из функции с атрибутом. По ходу программа включает bypass, меняет форму LFO и выключает bypass. С переменной окружения RTSAN_OPTIONS=halt_on_error=false:print_stats_on_exit=true санитайзер не останавливается на первой ошибке и в конце печатает их число. Сообщение было одно, при первом включении bypass: плавный переход впервые сложил два буфера, и системная библиотека Accelerate, через которую JUCE на macOS выполняет векторные операции, при первом таком вызове на потоке выделила память под свои данные. Повторных выделений не было, и сам код курса за все 400 блоков памяти не выделял.

Данные для интерфейса

Аудиопоток и интерфейс должны обмениваться данными: ручка меняет частоту (frequency)?частота (frequency) — Число полных колебаний за секунду. Обозначается f и измеряется в герцах; 1 Гц означает одно колебание в секунду. LFO, а редактор рисует кривую LFO, которую только что рассчитал аудиопоток. Брать для этого блокировку нельзя, поэтому нужны средства без блокировок (lock-free)?без блокировок (lock-free) — Свойство алгоритма или структуры данных для нескольких потоков: обращение к ним не требует ждать, пока другой поток отпустит блокировку. Так работают атомарные числа и очереди с одним писателем и одним читателем.: ни один поток в них не ждёт, пока другой закончит. Тимур Думлер (Using locks in real-time audio processing, safely) делит задачи на три вида, и учебный плагин использует первые два.

Одно число передают через std::atomic. Параметры JUCE так и устроены: AudioParameterFloat, AudioParameterBool и AudioParameterChoice хранят значение в поле std::atomic<float>, поэтому processBlock читает parameters.rate, пока слайдер в потоке сообщений его меняет. Частоту дискретизации для редактора процессор хранит сам:

// PluginProcessor.h
std::atomic<double> currentSampleRate{0.};

// PluginProcessor.cpp
double PluginProcessor::getSampleRateThreadSafe() const noexcept {
  return currentSampleRate;
}

Атомарные операции с float, double и указателями на распространённых 64-битных процессорах выполняются без блокировок. Проверить это для своей платформы можно при сборке: static_assert(std::atomic<double>::is_always_lock_free);.

Поток значений передают через очередь с одним писателем и одним читателем (single-producer, single-consumer FIFO). Кривую на экране рисует LfoVisualizer, а каждое значение LFO рассчитывает аудиопоток. Класс SampleFifo связывает их: внутри у него juce::AudioBuffer на секунду отсчётов, выделенный в prepare, и juce::AbstractFifo, который без блокировок ведёт позиции чтения и записи в этом кольцевом буфере.

// SampleFifo.h; push вызывает аудиопоток для каждого кадра
void push(SampleType sample) {
  const auto scope = fifo.write(1);

  if (scope.blockSize1 > 0) {
    buffer.setSample(0, scope.startIndex1, sample);
  } else if (scope.blockSize2 > 0) {
    buffer.setSample(0, scope.startIndex2, sample);
  }
}

Если очередь заполнена, write(1) возвращает нулевые размеры, и отсчёт пропадает: аудиопоток не ждёт читателя. Для рисунка потеря нескольких точек незаметна. Читает очередь поток сообщений: LfoVisualizer подключён к juce::VBlankAttachment и при каждом обновлении экрана вызывает popAll, который копирует все накопленные отсчёты в буфер визуализатора. Этот буфер выделен заранее, в конструкторе визуализатора, на секунду отсчётов, а popAll меняет его размер с avoidReallocating = true: если новый размер не больше прежнего, память не перераспределяется.

Третий вид — объект целиком, например набор коэффициентов фильтра, рассчитанный после поворота ручки, или звуковой файл, загруженный с диска. В учебном плагине такого нет, и ему посвящены два следующих раздела.

std::shared_ptr и общее владение

Объект удаляется в том потоке, где исчезла последняя копия. Пусть аудиопоток в начале блока сделал локальную копию, а поток сообщений тем временем заменил общий указатель новым набором коэффициентов. Теперь единственный владелец старого набора — локальная копия, и в конце processBlock она вызовет delete в аудиопотоке.

Осторожности требует и сам общий указатель. Атомарен только счётчик, объект std::shared_ptr — нет: если один поток копирует его, а другой одновременно присваивает новое значение, это гонка данных и неопределённое поведение (cppreference, std::atomic<std::shared_ptr>). C++20 добавил для этого std::atomic<std::shared_ptr<T>>, но в стандарте он не обязан работать без блокировок, а на практике так не работает. В libstdc++ (GCC) и стандартной библиотеке Microsoft is_always_lock_free равен false: внутри используется блокировка на младшем бите указателя, и аудиопоток может ждать поток сообщений. В libc++, библиотеке Clang и Xcode, этот шаблон не реализован, и std::atomic<std::shared_ptr<T>> не компилируется.

В докладе на CppCon 2015 Тимур Думлер показал схему, которую потом часто повторяли: атомарная подмена shared_ptr и «пул освобождения» (release pool), который держит лишнюю копию каждого объекта, чтобы последняя ссылка исчезала в потоке сообщений. В 2019 году автор написал, что схема в корне неверна и небезопасна, а std::shared_ptr не подходит для обмена объектами с потоком реального времени (форум JUCE). Позже он советовал неизменяемые объекты: поток сообщений не правит объект, которым пользуется аудиопоток, а готовит новую версию, и аудиопоток переходит на неё, когда закончит со старой. Следующий раздел показывает такую схему с явным владельцем на каждом шаге.

Подмена объекта через очереди

Идея похожа на SampleFifo, только по очереди передаются указатели на готовые объекты. Нужны две очереди. По первой поток сообщений отправляет аудиопотоку новый набор, по второй аудиопоток возвращает отработавший набор, и поток сообщений его удаляет. Кода нет в учебном плагине, его мы написали для статьи. Очередь построена на том же juce::AbstractFifo:

// Очередь указателей: пишет один поток, читает другой, без блокировок
template <typename T, int Capacity>
class PointerFifo {
public:
  bool push(T* object) noexcept {
    const auto scope = fifo.write(1);
    if (scope.blockSize1 == 0)
      return false;  // очередь заполнена
    slots[static_cast<size_t>(scope.startIndex1)] = object;
    return true;
  }

  T* pop() noexcept {
    const auto scope = fifo.read(1);
    return scope.blockSize1 > 0 ? slots[static_cast<size_t>(scope.startIndex1)]
                                : nullptr;
  }

  bool hasFreeSpace() const noexcept { return fifo.getFreeSpace() > 0; }

private:
  juce::AbstractFifo fifo{Capacity};
  std::array<T*, Capacity> slots{};
};

Обмен наборами коэффициентов фильтра:

struct Coefficients {
  float b0 = 1.f, b1 = 0.f, b2 = 0.f, a1 = 0.f, a2 = 0.f;
};

class CoefficientsExchange {
public:
  explicit CoefficientsExchange(std::unique_ptr<Coefficients> initial)
      : active{initial.release()} {}

  ~CoefficientsExchange() {  // аудиопоток уже остановлен
    update();
    while (auto* waiting = toAudio.pop())
      delete waiting;
    delete active;
  }

  // Поток сообщений: новый набор заменяет ещё не отправленный
  void publish(std::unique_ptr<Coefficients> next) {
    pending = std::move(next);
    update();
  }

  // Поток сообщений, ещё и по таймеру: отправить набор, удалить отработавшие
  void update() {
    while (auto* old = toDelete.pop())
      delete old;
    if (pending != nullptr && toAudio.push(pending.get()))
      pending.release();  // теперь объектом владеет очередь
  }

  // Аудиопоток, в начале processBlock
  const Coefficients& current() noexcept {
    if (toDelete.hasFreeSpace())
      if (auto* next = toAudio.pop())
        toDelete.push(std::exchange(active, next));
    return *active;
  }

private:
  std::unique_ptr<Coefficients> pending;
  Coefficients* active;
  PointerFifo<Coefficients, 8> toAudio;
  PointerFifo<Coefficients, 8> toDelete;
};

У каждого набора в любой момент один владелец, как требует правило владения из статьи «Кто владеет объектом». Пока набор не отправлен, им владеет pending в потоке сообщений. Когда указатель попал в очередь, release() снимает обязанность удалить объект с unique_ptr, и владельцем становится ячейка очереди, как между release() и addParameter при передаче параметра процессору. Аудиопоток забирает указатель, делает его активным и возвращает прежний активный набор во вторую очередь. Удаляет его update() уже в потоке сообщений. Рисунок 2 показывает этот путь.

Почему код не теряет наборы и не удаляет их в аудиопотоке:

• current() сначала проверяет, есть ли место в toDelete. Если поток сообщений давно не вызывал update() и очередь заполнена, аудиопоток не берёт новый набор: старый некуда деть, а удалять его самому нельзя. Звук ещё блок-другой идёт со старыми коэффициентами.
• Если заполнена toAudio, publish оставляет набор в pending, и его отправит следующий вызов update(). Новый publish заменяет неотправленный набор: при быстром повороте ручки промежуточные наборы удаляются в потоке сообщений, а последний обязательно дойдёт до звука.
• update() нужно вызывать регулярно, например из juce::Timer с периодом 50–100 мс, иначе отработавшие наборы будут копиться в toDelete.
• Деструктор удаляет всё, что осталось в очередях. Он рассчитан на то, что аудиопоток уже не вызывает current(): так и есть, если объект обмена — поле процессора, а хост удаляет процессор после остановки обработки.

Мы проверили схему программой из двух потоков: один в цикле вызывает current() из функции с [[clang::nonblocking]], другой отправляет 20 000 наборов подряд и затем ещё 200 раз вызывает update(). Сборки с RealtimeSanitizer, ThreadSanitizer (ищет гонки данных) и AddressSanitizer (ищет обращения к удалённой памяти) ошибок не нашли, а последним аудиопоток увидел последний отправленный набор.

Инструменты владения JUCE

У JUCE есть собственные классы владения. Они встречаются в коде фреймворка и в примерах, поэтому их полезно узнавать. Таблица 2 сравнивает их со стандартными аналогами.

OwnedArray хранит указатели и удаляет объекты, когда их убирают из массива через remove, clear или вместе с самим массивом. Удобно держать в нём, например, голоса синтезатора (synth voice)?голос синтезатора (synth voice) — Набор генераторов и обработки, который звучит одной нотой: источники, микшер, фильтр, усилитель и огибающая. Одноголосный синтезатор играет одну ноту одновременно., созданные при подготовке:

juce::OwnedArray<Voice> voices;  // поле процессора; Voice — свой класс голоса

void prepareToPlay(double sampleRate, int) override {
  voices.clear();  // удалит прежние голоса
  for (int i = 0; i < 8; ++i)
    voices.add(std::make_unique<Voice>(sampleRate));
}

В processBlock перебирать voices можно, а вызывать clear или remove — нет: это delete в аудиопотоке.

Component::SafePointer нужен, когда компонент может исчезнуть раньше, чем к нему обратятся. Типичный случай — отложенный вызов через juce::MessageManager::callAsync. В примере курса LongRunningTask фоновый поток сообщает прогресс так:

juce::MessageManager::callAsync(
    [this, newProgress]() { progress = newProgress; });

Лямбда выполнится позже, в потоке сообщений. В учебном приложении компонент живёт, пока открыто окно, и это допустимо. Но редактор плагина хост закрывает когда угодно, и если он удалён раньше, чем дошла очередь сообщения, this станет висячим указателем (dangling pointer)?висячий указатель (dangling pointer) — Указатель или ссылка на уже удалённый объект. Обращение через него — неопределённое поведение.. SafePointer обнуляется при удалении компонента, и перед обращением его проверяют:

juce::MessageManager::callAsync(
    [safeThis = juce::Component::SafePointer{this}, newProgress] {
      if (safeThis != nullptr)
        safeThis->progress = newProgress;
    });

WeakReference делает то же для любого класса, который объявил JUCE_DECLARE_WEAK_REFERENCEABLE; SafePointer построен на нём. Документация предупреждает, что он не потокобезопасен. Кроме того, при создании первой ссылки на объект класс выделяет память под общий узел, через который ссылки узнают об удалении. Поэтому оба класса — инструменты потока сообщений.

ReferenceCountedObject — базовый класс со встроенным атомарным счётчиком, а ReferenceCountedObjectPtr увеличивает и уменьшает его. Когда счётчик доходит до нуля, объект выполняет delete this в том потоке, где исчезла последняя ссылка. Так устроены, например, коэффициенты фильтров juce::dsp::IIR::Coefficients: если присвоить фильтру новые коэффициенты прямо в processBlock, старые могут удалиться в аудиопотоке. Правило то же, что для shared_ptr: последнюю ссылку отпускают в потоке сообщений.

Детектор утечек

Каждый класс учебного плагина заканчивается макросом:

// PluginProcessor.h
JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR(PluginProcessor)

Он объединяет два макроса. JUCE_DECLARE_NON_COPYABLE запрещает копирование, а JUCE_LEAK_DETECTOR добавляет в класс поле juce::LeakedObjectDetector. У детектора есть общий для всего класса счётчик: конструктор поля увеличивает его, деструктор уменьшает. При завершении программы, когда уничтожаются статические объекты, детектор проверяет счётчик, и если объекты класса остались, печатает сообщение и останавливает отладчик через jassertfalse. Работает это только в отладочной сборке: макрос JUCE_CHECK_MEMORY_LEAKS включается вместе с JUCE_DEBUG, а в выпускной сборке поле не добавляется вовсе.

Вот что напечатала отладочная сборка, когда мы создали процессор учебного плагина через new и не удалили:

*** Leaked objects detected: 1 instance(s) of class PluginProcessor
JUCE Assertion failure in juce_LeakedObjectDetector.h:116
*** Leaked objects detected: 2 instance(s) of class AudioBuffer
*** Leaked objects detected: 1 instance(s) of class AbstractFifo
*** Leaked objects detected: 1 instance(s) of class AudioParameterChoice
...
*** Leaked objects detected: 4 instance(s) of class StringArray

Один потерянный объект дал 15 сообщений: вместе с процессором остались его поля, параметры и их внутренние объекты. Искать причину стоит с самого внешнего класса, обычно своего, а не класса JUCE. Типичные причины такие:

• объект создан через new, и указатель потерян или не передан владельцу;
• два объекта с подсчётом ссылок ссылаются друг на друга, и счётчики никогда не доходят до нуля;
• объект хранится в статической или глобальной переменной и ещё жив, когда JUCE завершает работу: документация называет этот случай отдельно, хотя утечки здесь нет.

Если счётчик ушёл ниже нуля, детектор печатает «Dangling pointer deletion»: объектов удалено больше, чем создано, то есть какой-то указатель удалён дважды. Ошибка могла случиться раньше, чем её заметили.

Самопроверка

Источники

• Bencina R. Real-time audio programming 101: time waits for nothing. в списке литературы → — почему аудиоколбэк не должен выделять память, брать блокировки и ждать ОС; инверсия приоритетов; предварительное выделение.
• Doumler T. Using locks in real-time audio processing, safely. в списке литературы → — std::atomic для чисел, очередь с одним писателем и читателем для потока данных, неизменяемые объекты, почему try_lock у std::mutex небезопасен.
• Timur Doumler. Сообщение на форуме JUCE, 12 марта 2019 — отказ от схемы с std::shared_ptr и пулом освобождения из доклада «C++ in the Audio Industry», CppCon 2015.
• LLVM. RealtimeSanitizer — флаг -fsanitize=realtime, атрибуты [[clang::nonblocking]] и [[clang::blocking]], параметры RTSAN_OPTIONS; Clang 20.1.0 Release Notes — появление санитайзера.
• cppreference. std::atomic<std::shared_ptr> — гонка данных при одновременном доступе к одному shared_ptr, is_always_lock_free определяется реализацией; libstdc++ 14, shared_ptr_atomic.h и Microsoft STL, memory — is_always_lock_free = false; libc++ C++20 Status — P0718R2 не реализован.
• Alex. Learn C++. Уроки 22.6 «std::shared_ptr» и 22.7 «Circular dependency issues with std::shared_ptr, and std::weak_ptr». в списке литературы → — общее владение и циклические ссылки; 19.1 «Dynamic memory allocation with new and delete».
• JUCE. tremolo-juce-course — учебный плагин официального курса JUCE; фрагменты из complete/tremolo_plugin: PluginProcessor.h, PluginProcessor.cpp, Tremolo.h, SampleFifo.h, BypassTransitionSmoother.h, LfoVisualizer.cpp, и примеры complete/examples/GuiAndAudioThreadIdPrinting, LongRunningTask.
• JUCE. Заголовок AudioProcessor 9.0.3 — processBlock в аудиопотоке, prepareToPlay и подсказка о размере блока; AudioProcessorParameter — вызовы слушателей из аудиопотока.
• JUCE 9.0.3: OwnedArray, WeakReference, ReferenceCountedObject, LeakedObjectDetector, AbstractFifo, Component::SafePointer, AudioBuffer::setSize.

Фрагменты кода учебного плагина взяты из папки complete репозитория tremolo-juce-course (JUCE 8.0.12, C++23). Пример с std::vector, PointerFifo и CoefficientsExchange проверены сборкой Homebrew Clang 22.1 с RealtimeSanitizer, а обмен — также с ThreadSanitizer и AddressSanitizer; processBlock учебного плагина проверен под RealtimeSanitizer консольной программой с JUCE 8.0.12.