[ardour-dev] Strange Issue WIth Automation in ardour-0.9_beta11

[Paul Davis]

>I did some more investigation of the problem last night.  The CPU usage starts
>bursting up to 50% or so pretty soon after starting the automation record 
>(from beginning of session, BTW).  The bursts last longer and longer, until 
>at about 2 minutes the CPU is constantly being used.  The burstiness starts 
>quickly, and then slowly ramps up, and it seems like it hits plateaus as it 
>goes.  After a little bit of this, I stopped recording automation at this 
>point, saved the session, and looked at the automation file.  There were 
>around 1100 control points in the file, for both pan and gain.

that sounds about right.

>So then I started rummaging around the source.  Since this was my first 
>adventure looking at the ardour source code, I may be off in the weeds on 
>this, apologies in advance!  I started looking in 
>libs/ardour/automation_event.cc at AutomationList::add(ControlEvent *, 
>iterator, bool).  In it, it appears to make a call to lower_bound() on the 
>entire automation event list at line 182.  lower_bound() is implemented 
>essentially as a binary search, so its efficiency is lg(n).  So this might 
>explain the behavior I was seeing.  It would of hit 1024 automation points 

its good to be reminded of this. i tend to think of ::add() being
driven by GUI operation, where the O(logN) behaviour is
irrelevant. but i forget (sometimes) that its also driven by real-time
stuff as well. could you please file a short report on this in mantis,
so that its not forgotten? thanks

i suspect that we may need ::rt_add() for this, which will just build
up a list of events in a separate list, then add them when the
transport stops in an non-RT context.

--p