[nama] Re: More on buffering and priority (was: Re: Latency compensation)
- From: "S. Massy" <lists@xxxxxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Wed, 2 May 2012 01:06:15 -0400
Hello,
It's getting late here, so my wits aren't all passing muster, but here
are a few thoughts.
1) I've never used nama without jack, have you?
2) Jack offers built-in extra latency compensation via the -I and -O
options, and I think it should be the preferred way of handling this
particular issue.
3) Based on this, I don't think we need worry about -z:multitrack.
4) It makes sense to set the buffersize (-b) ourselves, so we always
know for certain what it is and can compensate for it.
5) We probably want to disable all buffering when recording.
(rtlowlatency)
6) We can allow some buffering in monitor mode. (rt)
7) Theoretically, we might want very large buffering when performing
certain operations such as caching and mixdown to avoid any possible
xrun. *However,* it is worth noting that a project with inserts using
other jack clients (and even more so the soundcard) would still need to
run real-time during mixdown.
I think that's about it in the pearls of wisdom department.
The e-mail you quote regarding sensible buffering parameters does not
really apply to nama because 1) it focuses about the single operation
of recording a lot of audio to disk reliably and 2) it's 7 years old.
Running a stable RT kernel (2.6.33.7.2-rt30) with jackd using a period
size of 128 frames, I can run ecasound with -b:128 all night and, so
long as the system doesn't come under stress, I don't experience any
xruns. On a modern system, it really seems like overkill to use a
buffersize over 1024 samples.
Cheers,
S.M.
--
Other related posts:
