[Ardour-Users] Fwd: Re: ardour 3.0 alpha season drawing to an end

Al Thompson althompson58 at gmail.com
Sat Jul 16 15:19:04 PDT 2011

-------- Original Message --------
Subject: 	Re: [Ardour-Users] ardour 3.0 alpha season drawing to an end
Date: 	Sat, 16 Jul 2011 23:14:01 +0200
From: 	Robin Gareus <robin at gareus.org>
To: 	Al Thompson <althompson58 at gmail.com>

Hi Al,

Did you intentionally post off-list? If not, feel free to forward this
to ardour-users at lists.ardour.org - it may be of interest for others, too.

On 07/16/2011 10:43 PM, Al Thompson wrote:
> On 07/16/2011 12:55 PM, Robin Gareus wrote:
>> They're related. Usually the x-run is first (and only a transient
>> condition) but popping up the log window, adding the message, scrolling
>> it to the bottom, etc increases the system load.  More x-runs, more of
>> the messages appear,.. even more system-load, more x-runs.. (until there
>> is one "JackActivationCount" message for each cycle) and
>> the jack-client (here: ardour3) is becoming unresponsive.
> This must be what is happening with mine.  Ardour  becomes totally
> unresponsive and consumes 100% of the processor for a few minutes (3 or
> more), and then settles back down.  This is with a session which has
> only two MIDI tracks I was playing with to try out the editor, and the
> whole session is only a couple of minutes long.  Up until it locks
> itself up, there is no sign of high resource usage.

Do you get "JackActivationCount" messages in ardour's Error-Log?

It's not a matter of track-count or session-length. It is a matter of
DSP (and CPU) load.

I can reproduce it by adding a couple of foo-yc20 organs (LV2synth)
which are rather CPU heavy. Just two or three MIDI tracks with a
foo-yc20 plugins each are usually enough to trigger the issue here.

Only [being patient and] disconnecting ardour from JACK resolves the
issue cleanly.

>>>> Alternatively, it won't ever show up in when running jackd2 in
>>>> synchroneous mode:
>>>>   launch jackd: jackd -S ...
>>>>   or with jackdbus : `jack_control eps sync true`
>>>     does this not disable one of the "features" of JACK2, i.e.
>>> asynchronous data flow (assuming one has some audio data moving in
>>> parallel)?
>> It does. However note that this "feature" also adds 1 cycle of latency.
>> YMMV.
> I've never played with the synchronous vs a sync setting.  Besides
> eliminating this boondoggle,

Note: updating to the latest jackdmp (version svn-r4491) will also
eliminate this. The "JackActivationCount" is no longer an error-message
and thus not printed into the ardour error-log.

> what will running in synchronous mode
> change, and what are the disadvantages?

In short: jack2-sync-mode is more Xrun prone, may consume more CPU, but
has less playback-latency - it's the same behaviour as jack1.

> Also, when you say "1 cycle" in this context, is it one cycle at the
> audio sample rate, 1 cycle of the timing source, or one CPU cycle?

1 cycle - here: one jack period ( '--period NUM' argument for jackd;
default 1024 samples).

>From http://www.grame.fr/~letz/jackdmp.html :

-=-=-=- <quote>
jackdmp can work in 2 different mode at the server level:

    * "synchronous" activation : in a given cycle, the server waits for
all clients to be finished (similar to normal jackd)

    * "asynchronous" activation : in a given cycle, the server does not
wait for all clients to be finished and use output buffer computed the
previous cycle. The "audible" result of this mode is that if a client is
not activated during one cycle, other clients may still run and the
resulting audio stream will still be produced (even if its partial in
some way). This mode usually result in fewer (less audible) audio
glitches in a loaded system.
-=-=-=- </quote>

The _default_ asynchronous mode has the drawback that the output is
delayed by one period - because it "plays" the output buffer computed in
the previous cycle instead of the one of the current cycle.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/private.cgi/ardour-users-ardour.org/attachments/20110716/c031588b/attachment.htm>

More information about the Ardour-Users mailing list