Re: [Jack-Devel] automated jack settings test

PrevNext  Index
DateMon, 14 Nov 2011 20:03:08 +0000
From John Rigg <[hidden] at jrigg dot co dot uk>
To[hidden] at jackaudio dot org
In-Reply-ToScott Lavender [Jack-Devel] automated jack settings test
Follow-UpStéphane Letz Re: [Jack-Devel] automated jack settings test
On Sun, Nov 13, 2011 at 08:31:41PM -0600, Scott Lavender wrote:
> i had an idea for an application to help new users setup jack and i
> wanted some feedback.
> 
> the general thought is...
> 1. a user would start the application
> 2. pick an available audio interface to test
> 3. the program would test settings [1] against an "xrun condition" [2]
> 4. then determine the best setting by lowest stable recorded latency
> 5. set the lowest stable setting
> 
> [1] this could be brute force or following smart rules
> [2] not defined at this time and i'm sure everyone will argue what is
> proper but could be something arbitrary like 4 xruns over a 10 second
> time period or 0 xruns over 15 minutes, also this could even
> incorporate the 'rtevel' application or other test to invoke a load
> 
> okay, let me know why this wouldn't work.

It depends what you class as an xrun.

With my three Delta 1010s running as a combined device with pcm_multi,
jackd shows xruns that are not audible (and not reported by alsa_pcm).
I had to turn off xrun indication in Ardour 2 because there were hundreds of
xrun markers when recording. There were no audible glitches and no detectable
discontinuities in the sample values. By contrast, xruns that are actually
reported by alsa_pcm are always audible.

Given the above, testing jackd for xrun indications might not be
all that accurate unless you're looking at actual xruns reported by
alsa_pcm.

John
PrevNext  Index

1321300799.16323_0.ltw:2,a <20111114200308.GA3403 at localhost0 dot localdomain>