Please see the Ardour web site at https://ardour.org/ for all documentation.

For information on building ardour: https://ardour.org/development.html

This fork of the Open-Source ARDOUR DAW (Digital Audio Workstation) project features additions made for my Master's thesis named Analyzing the Architecture of the Ardour Digital Audio Workstation and Designing a Multi-Threaded In-track Plugin Execution Model. The thesis will shortly be uploaded on the UvA website following its defence.

This project's goal was to execute track channels in parallel for N-channeled tracks, where N > 1 and to see whether we have speed-ups compared to the regular Ardour version.

It involved altering the regular Sequential configuration of plugins implemented as a list by creating a graph class (ProcessorGraph). Other changes have been made to accommodate this graph paradigm such as the addition of several attributes aiding in the execution of the graphs such as:

1. parents, children & dependencies_left attributes for the Processor class; necessary for keeping track of dependencies while executing the processor graph

2. awake_threads - signal which keeps track of currently working threads on the track; if a node in the graph has 2 children, we awaken the sleeping track helper thread and put it to sleep when the nodes converge to only one node again.

A helper function assigned to the helper thread also has been created (Route::run_helper_thread_plugin_insert_list), which processes plugins in parallel with the modified process_output_buffers function (the main track processor execution function).

In order to provide full control over plugin parallelisation, an addition over the frontend of the application was also made, particularly in the ProcessorBox class. This addition features an option to parallelise selected plugins in the ProcessorBox UI. Once this option is selected, when running the transport, the selected plugins will be either run in parallel, or if they were previously selected as "parallelisable" they will be changed to sequential processing.

Our project resulted in speedup for certain configurations, mainly when buffer size >= 1024, but we also had examples where our implementation was better than the regular ARDOUR version for certain parallelised plugins at >= 256 samples. The latter was the case when testing duplicated MONO plugins on STEREO tracks to accommodate for the channel count. Because our implementation parallelizes the plugin execution, it beat the duplicated MONO case.

Below are the results of the experiments we conducted, showing performance comparisons across different buffer sizes and plugin types:

256 samples	512 samples	1024 samples	2048 samples

256 samples	512 samples	1024 samples	2048 samples

256 samples	512 samples	1024 samples	2048 samples

• Slight performance improvements with buffer sizes >= 1024 samples for Parallelised plugin execution for most STEREO plugins tested
• Better performance at >= 256 samples for specific plugin configurations (MONO sequential duplicated delay runtime >= Parallelised MONO delay).
• Parallel channel execution best for non inter-channel dependent plugins and when buffer size > 512 samples => our implemented approach cannot be used in recording scenarios.