Re: [LAD] Some questions about the Jack callback

On Sat, 20 Sep 2014 08:35:59 +0000
Fons Adriaensen <fons@email-addr-hidden> wrote:

> On Fri, Sep 19, 2014 at 11:16:38PM -0700, Len Ovens wrote:
>
> > On Fri, 19 Sep 2014, Will Godfrey wrote:
> >
> > >Say we have A, B & C in that order and B&C each take 3mS to return
> > >but A takes 6mS. Does C get booted out even though it was A that
> > >was the time hog?
> >
> > The expectation is that there is enough time to finish a,b and c
> > all the time.
>
> Which is also why clients should be designed to take the same time
> in each period. This time may depend on what the client is doing, e.g.
> on the number of active voices in a synth, but in all cases the work
> should be spread equally over all periods. In most cases that will
> not require anything special, the exception being clients that use
> block algorithms like an FFT.
>
> The worst offenders here are apps that were not designed as Jack
> apps in the first place, and use a large internal period size with
> some buffering in between. They will e.g. do nothing for a number
> of periods, then bunch all the work for those in a single one.
> Such apps should really run their DSP code in a lower priority
> thread. This will mean more latency, but at least that makes
> them usable.
>
> Ciao,

Hmm. I can see how consistent time benefits all processes in the chain, but
that presents me with a problem.

While getting to grips with Yoshimi I set up a microsecond timer in the function
that actually generates the data. To get a worst-case scenario I did this on my
office machine that's not specially set up for audio.

I configured jack for 512 frames/period, 2 periods/buffer and 48k, giving an
overall latency of 21.3mS

Running a moderately complex 12 part tune, the data 'build' time was varying
between about 1.8mS and 6.1mS per buffer. It dropped to less than 1mS when there
was no sound being produced.

That was a lot more variation than I was expecting but considering the variety
of calls that were being made, dependent on which voices were sounding and with
what effects, I don't know how this could be avoided.

I did another check for continuous sounds, and under those circumstances the
time didn't vary significantly. Also, I don't have anything to compare against.
These day Yoshi & Zyn give substantially similar timings.

As a final point, the actual transfer time was rock solid at approx 150uS under
all conditions - although I'd have been worried if it wasn't!

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev