Confirmed. No sound and no spectogram with DF Room 3.2.2 in Reaper 6.18 and Ardour 6.5.
Confirmed. No sound and no spectogram with DF Room 3.2.2 in Reaper 6.18 and Ardour 6.5.
@sub26nico Please try 3.2.3 now, I think 3.2.2 was completely broken on Linux.
Confirmed working on Ardour 6.5.28. Nice job! Really looking forward to the next release.
Confirmed working on Ardour 6.5.28. Nice job! Really looking forward to the next release.
Thanks for testing it! I’m really hoping that we’ve finally cracked this old chestnut.
1 Like
Btw, are you no longer using riot.im for chatting about the reverbs? Would love to talk about what plans you have for v4 beyond the single plugin idea.
Oof, I should get back on there and pitch what I’m working on… There are just too many channels of communication these days, it’s hard to keep up with them all.
Yep, with 3.2.3, it works nicely, both in Ardour and Reaper. Thanks & congrats Michael.
1 Like
The new version does not solve the problem that after reloading a project with more than one DragonFly reverb, the DSP becomes very busy and playback has dropouts.
See Hiccups and DSP usage.
I can’t recreate that on my system. With 3.2.3 early reflections, room and hall on three different audio tracks, DSP hovers around 16% even after reloading the project.
So it seems the concurrency issue above may be unrelated to the room reverb’s NaN init bug.
@anon60445789 Do you have more than 2 cores in use for DSP, and multiple instances of the same plugin (e.g. two or more “room” reverbs) in the session ?
The issue also used to be erratic, not reliably reproducible.
Yes, I have all but one processor for DSP. And, yes, I tried adding the same plugin and also different plugins. Three instances of room gives me the same result of low DSP between 15-17%. For what it’s worth, this is the same in both Windows and Linux versions of Ardour using both VST and LV2.
FWIW, I’m using the LV2 version of DragonFly Room Reverb.
That’s what I’ve tested along with other configurations. I’m assuming there are others who have reported this same behavior?
Last year (Ardour5) I could get to 5 reverbs, after adding a sixth reverb (and restarting Ardour) the problems started.
Now I have it with two reverbs.
I’ll see if I can make some time tomorrow for some more experimenting.
Here is the report of some experimenting.
Removed (saved) all Ardour configs.
Brand new install (downloaded from Ardour site)
Run Ardour6 --new ./Scratch
Asks questions, all defaults.
Doesn’t open new project Scratch?
Quit
Install DragonFly reverbs in empty $HOME/tmp/lv2 directory
export LV2_PATH=$HOME/tmp/lv2
Run Ardour6 --new ./Scratch
Creates new project Scratch.
DSP: all but one processor (default)
Import 3 WAV files
Play OK, DSP: 3%
Add DragonFly Room to track 1
Play OK, DSP: 23%
Save and Quit
Restart Ardour
Play OK, DSP: 23%
Add DragonFly Room to track 2
Play OK, DSP: 24%
Save and Quit
Restart Ardour
Hickups, DSP: 100% (red)
Disable one of the reverbs: Play OK, DSP: 23%
Disable all reverbs: Play OK, DSP: 3%
Enable all reverbs: Play OK, DSP: 25%
Save and Quit
Restart Ardour
DSP: 100% (red)
Disable and re-enable one of the reverbs: Play OK, DSP: 25%
Add DragonFly Room to track 3
Play OK, DSP: 25%
Save and Quit
Restart Ardour
Hickups, DSP: 100% (red)
Disable one of the reverbs: Hickups, DSP: 100% (red)
Disable second of the reverbs: OK, DSP: 23% (red)
Enable all reverbs: OK, DSP: 23% (red)
Save and Quit
Conclusion: Ardour has no problem with multiple DragonFly Room reverbs, but the DSP maxes out when Ardour is restarted with more than one of the reverbs active.
When all (or all but one) of the reverbs are deactivated, DSP returns to normal. DSP stays normal when the reverbs are re-enabled. So the problem occurs when Ardour is started with, or opens, a project that has more than one DragonFly Room reverb active.
I can reproduce this at will, let me know if there is more information I can gather to help solving this problem.
@sciurius Please try this early alpha release of Dragonfly Reverb 4. CPU usage is not optimized yet, so performance won’t be amazing, but I want to know whether you experience similar high DSP load upon starting up your DAW:
Read more here: https://linuxmusicians.com/viewtopic.php?f=48&t=22431
Thanks, Michael!
I restored the project and everything. Added the new (alpha) reverbs, and started Ardour.
After changing the reverbs to v4 the DSP is higher (40-60%) but it works okay and I can restart without issues. I tried with up to 15 tracks with reverb.
The hard question is: Was there an issue with concurrency that you solved in v4, or was there an accidental issue that accidentally disappeared… To re-appear on the deadline day of a album production…
That’s a fair point. Before, I was just wrapping the freeverb3 library in these plugins, without really understanding what was happening inside the library. With v4, I’m pulling apart the library and rewriting it one function at a time, trying to understand what each piece does. Furthermore, I’m trying to develop a better capability to profile and debug the functionality therein, such that when these kinds of bugs happen, I will have better tooling to actually diagnose and fix them.
So no, I’m not certain why the CPU usage bug exists in v3 and earlier, but I’m hoping to have a better development process for working on such things with v4.
Unexpected high CPU usage (especially in reverbs) is normally symptomatic of denormal issues
This is a reasonably accessible read: https://www.earlevel.com/main/2019/04/19/floating-point-denormals/
@Michael_Willis, I realize I know next to nothing about plugin development (and what I know about denormals does not stretch much beyond the link I posted) but would this be useful?: https://carlh.net/plugins/torture.php. Not that I approve of torturing dragonflies in any shape or form 