Main menu
You are here
Plugin performance on RaspberryPi 3
I am running qtractor on RaspberryPi3 for a while now. All packages are cross-build with Openembedded (Yocto-project build system). When I started this hobby project, I did not expect to get that far: Playing live on a multiple midi tracks setup at very acceptable latency (buffer size 128 samples) worked pretty fine - time to say thank you for qtractor/v1/qjackctl...
Now I started building/using effect plugins and get more and more X-Runs. I played around, tried to enhance qtractor's performance by ARM-NEON (patch sent out) but that did not lead to significant enhancement. It seems to me that adding (LV2) plug-ins is very demanding. Currently I use 'roomy' (http://openavproductions.com/artyfx/) and 'Calf Mono Input' (http://calf-studio-gear.org/) - a screenshot of the current arrangement is attached.
Long talk - now my question: Even very simple plug-ins as 'Calf Mono Input' - just panning a mono input to stereo output - cause qjackctl to report a performance demand increase of 3-5% per plug-in. This looks odd to me and I get the feeling something in my stack (qtractor/plugin/jack2) is not working as it could. So I am asking for pointers: Which part of the stack is responsible for adding plugins - which part of code should I look into?
Thanks in advance
Andreas
| Attachment | Size |
|---|---|
 Screenshot_2017-10-03_23-34-51.png | 56.13 KB |
re. Plugin performance on RaspberryPi 3
hi, many thanks for your kind support.
if you're are confident that only LV2 plugins have such an impact and while, for instance LADSPA ones are not like so, then you probably can try and test first whether the LV2 UI-related refresh routine is to blame: try moving the qtractorLv2Plugin::idleEditorAll() call in qtrarctorMainForm.cpp (lines 7338-7342) from the
fastTimerSlot()into theslowTimerSlot(), somewhere neer a similar call for DSSI plugins. You can also try the same move for the qtractorLv2Plugin::updateTimePost() call if you wish.test && tell.
cheers
ps. your patch has been merged to brand new branch neonx. Thanks.
Thanks for quick response
Thanks for quick response
1. Currently I inserted LV2 plugins only but will try other -> report result later
2. Will play around with functions/fast/slow threads and report later too. One question: Do you expect UI-refresh eating up processing time even if main-window and mixer window are open only?
re. Plugin performance on RaspberryPi 3
re. 2... One question: Do you expect UI-refresh eating up processing time even if main-window and mixer window are open only?
well, not that much, but hey, the Rpi is a hard-constrained platform anyway; the UI refresh routine is (must be) in place no matter the GUI is open/shown or not, otherwise some GUI-eccentric plugins may behave erratically (eg. Calf); same with time/transport update routine, although this one running slower will probably play havoc on plugins that are set to sync to host tempo(bpm) or transport position.
byee
Add new comment