Strange Audio Rendering Phenomenon with Helm VST
malekinho8 opened this issue · 1 comments
Hello again @DBraun ,
I've been grappling with this strange behavior when trying to render audio with the Helm free VST. For my M1 Macbook Air, I could only get it to work with the .component plugin file, and what is strange is that when I run the code below:
engine = daw.RenderEngine(sample_rate=daw_settings['SAMPLE_RATE'], block_size=daw_settings['BLOCK_SIZE'])
# load the plugin
loaded_synth = load_plugin_with_dawdreamer(daw_settings['SYNTH_PLUGIN_PATH'], daw_settings['SYNTH_NAME'], engine)
# clear the midi notes
loaded_synth.clear_midi()
# generate a sound using the plugin (MIDI note, velocity, start sec, duration sec)
loaded_synth.add_midi_note(midi_piano_note, velocity, 0.0, midi_duration)
# load the plugin into the engine
engine.load_graph([(loaded_synth, [])])
# Render the sound
engine.render(target_audio_length)
It just exits without raising any exception or anything, just terminates the runtime. However, when I add a debug checkpoint at the engine.render()
line and step through it, it works with no problem. It only fails when I try to run the code straight through.
Do you have any idea off the top of your head for why this might be happening? I have the most up-to-date DawDreamer version (0.7.1), but I'm not sure if the version on PyPI incorporates the recent changes you've made on the FAUST processing side. Please let me know your thoughts whenever you get a chance, thanks!
Further traceback from C++ side when I try to render audio with Helm:
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1b9ea3264)
* frame #0: 0x00000001b9ea3264 caulk`caulk::semaphore::~semaphore() + 84
frame #1: 0x00000001b269e7ec AudioToolboxCore`std::__1::unique_ptr<auoop::PipeSubPool, std::__1::default_delete<auoop::PipeSubPool> >::reset(auoop::PipeSubPool*) + 44
frame #2: 0x00000001b269ed4c AudioToolboxCore`auoop::RenderPipeUser::~RenderPipeUser() + 744
frame #3: 0x00000001b26f974c AudioToolboxCore`-[AUAudioUnit_XPC internalDeallocateRenderResources] + 64
frame #4: 0x00000001b26ec9a8 AudioToolboxCore`int caulk::function_ref<int ()>::functor_invoker<AUv3InstanceBase::Uninitialize()::'lambda'()>(caulk::details::erased_callable<int ()> const&) + 40
frame #5: 0x00000001b26e4650 AudioToolboxCore`AUv3InstanceBase::NSExceptionBarrier(caulk::function_ref<int ()>) + 40
frame #6: 0x00000001b26ec974 AudioToolboxCore`AUv3InstanceBase::Uninitialize() + 44
frame #7: 0x00000001b2823e88 AudioToolboxCore`AUIB_Uninitialize(void*) + 200
frame #8: 0x00000001b2837694 AudioToolboxCore`AudioUnitUninitialize + 316
frame #9: 0x0000000129d5f5a8 dawdreamer.so`juce::AudioUnitPluginInstance::releaseResources() + 148
frame #10: 0x0000000129d5fe08 dawdreamer.so`juce::AudioUnitPluginInstance::prepareToPlay(double, int) + 56
frame #11: 0x0000000129c20c70 dawdreamer.so`RenderEngine::render(double, bool) + 1504
frame #12: 0x0000000129c7efdc dawdreamer.so`void pybind11::cpp_function::initialize<pybind11::cpp_function::cpp_function<bool, RenderEngine, double, bool, pybind11::name, pybind11::is_method, pybind11::sibling, pybind11::arg, pybind11::kw_only, pybind11::arg_v, char [124]>(bool (RenderEngine::*)(double, bool), pybind11::name const&, pybind11::is_method const&, pybind11::sibling const&, pybind11::arg const&, pybind11::kw_only const&, pybind11::arg_v const&, char const (&) [124])::'lambda'(RenderEngine*, double, bool), bool, RenderEngine*, double, bool, pybind11::name, pybind11::is_method, pybind11::sibling, pybind11::arg, pybind11::kw_only, pybind11::arg_v, char [124]>(bool&&, RenderEngine (*)(double, bool), pybind11::name const&, pybind11::is_method const&, pybind11::sibling const&, pybind11::arg const&, pybind11::kw_only const&, pybind11::arg_v const&, char const (&) [124])::'lambda'(pybind11::detail::function_call&)::__invoke(pybind11::detail::function_call&) + 376
frame #13: 0x0000000129be5708 dawdreamer.so`pybind11::cpp_function::dispatcher(_object*, _object*, _object*) + 3596
frame #14: 0x00000001000c1824 python3`cfunction_call + 60
frame #15: 0x00000001000633a8 python3`_PyObject_MakeTpCall + 336
frame #16: 0x0000000100068f98 python3`method_vectorcall + 604
frame #17: 0x000000010017a9d8 python3`_PyEval_EvalFrameDefault + 40296
frame #18: 0x00000001000649b8 python3`_PyFunction_Vectorcall + 548
frame #19: 0x00000001001999f8 python3`call_function + 148
frame #20: 0x0000000100172b74 python3`_PyEval_EvalFrameDefault + 7940
frame #21: 0x000000010016f204 python3`_PyEval_Vector + 532
frame #22: 0x00000001001e8220 python3`run_mod + 220
frame #23: 0x00000001001e7fc0 python3`pyrun_file + 156
frame #24: 0x00000001001e7a0c python3`_PyRun_SimpleFileObject + 316
frame #25: 0x00000001001e7374 python3`_PyRun_AnyFileObject + 216
frame #26: 0x000000010020baa0 python3`pymain_run_file_obj + 196
frame #27: 0x000000010020b32c python3`pymain_run_file + 72
frame #28: 0x000000010020a9cc python3`pymain_run_python + 340
frame #29: 0x000000010020a820 python3`Py_RunMain + 40
frame #30: 0x0000000100004820 python3`main + 56
frame #31: 0x00000001b069fe50 dyld`start + 2544
And a summary of the error from GPT4:
The bt
command in LLDB is used to print a backtrace of all stack frames, which can help identify where in the code the problem occurred. The backtrace you've provided shows that the execution stopped due to an EXC_BREAKPOINT
exception at caulk::semaphore::~semaphore()
, which seems to be part of the underlying system or possibly a library you're using.
As I can see from the backtrace, it seems like the issue is arising from dawdreamer
library, specifically from the RenderEngine::render(double, bool)
function. This function seems to be trying to release the resources allocated by an AudioUnit plugin when something goes wrong.
The AudioUnitPluginInstance::releaseResources()
method in dawdreamer.so
is being called, which seems to be trying to uninitialize an audio unit. This in turn leads to a call to caulk::semaphore::~semaphore()
, which is where the breakpoint is hit.
From this information, it looks like there might be a resource management issue at play. Your code seems to be trying to release resources (specifically, an audio unit) which have already been released or were never properly allocated. This is a common cause of errors in C++ code.
Please note that as an AI language model developed by OpenAI, my ability to diagnose the problem is limited to the information provided and my training data. It's best to consult with the maintainers of the dawdreamer
library or seek help from a software engineer experienced with the library and with debugging C++ code. They can provide more context-specific insights and debugging assistance.
Hope this helps. I'm going to keep trying to chip away at this but due to my limited C++ experience, I would greatly appreciate any insight or advice you might be able to provide to help guide me.
Best,
Malek