Yep, what @seablade said. Take your time, take care of yourself first and then tame that dragon(fly).
@x42 Is it possible for one plugin to be a bad actor and invade heap memory allocated by another plugin, maybe through bad pointer math or a buffer overflow?
I’m doing a deep dive, taking apart freeverb3 and rewriting it one function at a time. I am particularly scrutinizing how it implements buffers and feedback variables, because this bug could be caused if anything goes wrong with those.
So far I haven’t found anything that looks suspect. I’m wondering if operating systems do anything to protect memory between different .so/.dynlib/.dll libraries that are used within the same process.
I hate casting blame, and I’m still looking for a root cause in the dragonfly plugins, but it is really suspicious that some people report that they never experience this problem, and others repeatedly experience it. As for myself, I had one Ardour project in which Dragonfly Room would regularly explode, but I lost it to a hard drive crash and I don’t think that I had a backup. In my other projects I haven’t experienced this bug in a long time, probably a couple of years.
Yes, a plugin runs in the same memory space as the host and all other plugins.
This is also how processing works. Audio/MIDI buffers are memory allocated by the host, and the plugins writes there. The address space is shared.
Maybe this note to an Ardour crash could be of use in tracking down the issue. The crash reported there seems reproducible, and is at least related to the Dragonfly Room Reverb.
Thanks @Oliver_Grimm, I’m working on a prototype of Dragonfly Reverb 4, which will have all of the algorithms available in one plugin. I already have the early reflections and plate algorithms implemented, and the room algorithm is next. When I have that working, could I send you the next alpha release and have you try to reproduce the bug in your Ardour session?
Sure, happy to help.
I did boil it down now to a session with only one Dragonfly Room Reverb on the Master Bus and an empty track, without any other plugins. It crashes each time I stop playback if the reverb is activated.
And freshly discovered: it only happens when I have the Ardour option ‘Silence plugins when the transport is stopped’ enabled.
Another thing that may or may not be of importance: I have selected all ‘Denormals’ options in Ardour.
And finally, just now I had the ‘horrible attack noise’ that was mentioned by others. It occurred in that empty session. - I better stop experimenting now…
@Oliver_Grimm Thanks, I’m really glad to hear that you have it narrowed down to a session without any other plugins. That means it is definitely a problem in Dragonfly Room.
Wow. This is a great development. I’d also be happy to test an alpha if that’s useful.
EDIT: I can’t seem to reproduce the bug with the Plate, but the Room one crashes every time. So I’m not so sure anymore of my statement below. Sorry for any confusion.
(I just wanted to add my 2 cents, been following this thread because I had the same problem described by others here. I did have only Plate reverb in my mix though, not Room. The “attack” ( ) happened when stopping playback, and I also have “Silence plugins when…” option enabled.
I you want, I’ll try to reproduce the bug with Plate ?)
That is perhaps a clue. In that case Ardour can call
deactivate(); activate(); potentially concurrently with processing. That’s not allowed per the LV2 spec (fixed just now in Ardour 6.3-317-gf7cb1b0b48).
Then again it won’t explain why issues happen at session-load. Plugins are only silenced on a Play -> Stop transition.
I went ahead and tried to reproduce the bug with the Plate, but I guess I was wrong in my earlier assumption. Plate seems to work (edited my post).
The Room reverb however, makes Ardour crash every single time I try. The only thing I get out of system logs is :
RT-1-(nil): segfault at 0 ip 00007fa56c4dd2c3 sp 00007fa58c081380 error 4 in DragonflyRoomReverb_dsp.so[7fa56c4c7000+19000]
But maybe this is the particular bug that’s fixed in Ardour Nightly now ?
Indeed the crash I reported above related to ‘Silence plugins when the transport is stopped’ does not occur anymore with Ardour 6.3-317-gf7cb1b0b48.
Something I found curious and did not see mentioned in this threat before, is that I only ever observed this behavior of hall and room reverb at first playback after an initial start up of a session when I had the dry level of the plugins down to 0%. My personal workaround has been to leave it at 1% when using reverb on a bus and the issue did not occur for me. Can others confirm that? Hope it helps to narrow down the underlying cause. Great sounding reverb btw
That’s interesting ! I ONLY use the DragonFly reverbs on Aux Busses so I systematically set the Dry level to 0%
I’ll give your idea a shot
me too, dry at 0, never had any issue, maybe I’m just lucky
Me too: started a couple of weeks ago with dry at 0 (Hall) and now with this knowledge on the table I can positively recall: since then these noice-bursts! But only in one specific session, other sessions (also Hall) where I also set the dry on 0 haven’t blasted (yet?).
Wow… zero is definitely broken, at least on some platforms. There is a discussion in a recent pull request in which I learned that on some platforms, NaN is equal to zero, which seems completely bonkers to me and definitely breaks an assumption that I made when initializing the plugins.
Even though I’m busily working on v4, I’m going to try to carve out some time to fix this on v3 and hopefully it will resolve the explosions that people are experiencing.
Oof… floating point numbers are “fun”.
Here’s my fix in case anybody wants to take a look:
I’m working on building a new release, hopefully it will be available later today.
Giving them a test run now!
The new release is up: https://github.com/michaelwillis/dragonfly-reverb/releases/tag/3.2.3, this should fix the bad behavior that people experienced when sliders or dials were set to zero. It might fix the explosions of sound that have been threatening eardrums.
Edit: Changed download link to 3.2.3, since 3.2.2 was broken.