From 5925ee0b7cc8eeee9918123dd501c547a7def23c Mon Sep 17 00:00:00 2001 From: Robin Gareus Date: Mon, 4 Oct 2021 22:30:08 +0200 Subject: [PATCH] Prevent processing until buffersize change is complete This fixes async callback from CoreAudio via AudioDeviceAddPropertyListener. Apparently in rare cases it can happen that the property listener calls back concurrently with processing on M1 machines using Rosetta. https://pastebin.com/upvc9LTc Thread 44 vs. Thread 32 May also be caused by plugin(s) taking a long time to change buffersize. Processing continues even though the buffersize callback has not yet completed. PS. I have not been able to reproduce this on an Intel machine, even with excessive buffersize changes. However since buffersize changes cannot (usually) happen concurrently with processing, taking the lock is reasonable. --- libs/ardour/audioengine.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/libs/ardour/audioengine.cc b/libs/ardour/audioengine.cc index 1d79b03cc8..d66cad079b 100644 --- a/libs/ardour/audioengine.cc +++ b/libs/ardour/audioengine.cc @@ -210,6 +210,7 @@ AudioEngine::sample_rate_change (pframes_t nframes) int AudioEngine::buffer_size_change (pframes_t bufsiz) { + Glib::Threads::Mutex::Lock pl (_process_lock); set_port_buffer_sizes (bufsiz); if (_session) {