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

[Casey Shultz]

Thanks for the info Robin. I'm a bit unclear on how to start jackd2 and
Ardour 3 in synchronous mode. The "-S" doesn't show in the jackd
documentation that I have.

--
Casey Shultz
http://scifisurplus.com
--



On Sat, Jul 16, 2011 at 4:19 PM, Al Thompson <althompson58 at gmail.com> wrote:

> **
>
>
> -------- 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> <robin at gareus.org>  To: Al Thompson
> <althompson58 at gmail.com> <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.
>
> ciao,
> robin
>
>
> _______________________________________________
> Ardour-Users mailing list
> ardour-users at lists.ardour.org
> http://lists.ardour.org/listinfo.cgi/ardour-users-ardour.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-users-ardour.org/attachments/20110716/db929120/attachment-0002.htm>