Just trying to get a clearer understand so hope these aren't too noob-ish.
If you have several processes wanting to send audio, does the callback go to all
of them at (essentially) the same time, or does Jack poll them?
If the former, is it the quickest to complete that gets processed first?
If
On Fri, Sep 19, 2014 at 09:44:44PM +0100, Will Godfrey wrote:
> Just trying to get a clearer understand so hope these aren't too noob-ish.
>
> If you have several processes wanting to send audio, does the callback go to
> all
> of them at (essentially) the same time, or does Jack poll them?
>
>
On Fri, 19 Sep 2014 20:58:58 +
Fons Adriaensen wrote:
> On Fri, Sep 19, 2014 at 09:44:44PM +0100, Will Godfrey wrote:
>
> > Just trying to get a clearer understand so hope these aren't too noob-ish.
> >
> > If you have several processes wanting to send audio, does the callback go
> > to al
On Fri, Sep 19, 2014 at 5:23 PM, Will Godfrey
wrote:
>
> Do the clients know when in the time frame they are actually called?
>
they can find out but they really shouldn't care
> 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
On Fri, Sep 19, 2014 at 5:32 PM, Paul Davis
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?
>>
>
note that nobody but the user can know that A is the time hog. A could be a
huge
On Fri, Sep 19, 2014 at 10:23:26PM +0100, Will Godfrey wrote:
> Assuming buffer size and sample rate give 10.7 mS overall.
>
> Do the clients know when in the time frame they are actually called?
They can find out if they want (and some like the zita-*2* ones do
in order to do their job the be
On Fri, 19 Sep 2014 17:36:00 -0400
Paul Davis wrote:
> On Fri, Sep 19, 2014 at 5:32 PM, Paul Davis
> 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?
> >>
> >
> not
On Fri, Sep 19, 2014 at 10:53:19PM +0100, Will J Godfrey wrote:
> It's probably not worth the effort, but I wondered if the client could attempt
> to be a 'good citizen' and take some form of remedial action.
I don't know of any that try to do this. But if a client would
want to, the most sensib
On Fri, 19 Sep 2014 22:06:32 +
Fons Adriaensen wrote:
> On Fri, Sep 19, 2014 at 10:53:19PM +0100, Will J Godfrey wrote:
>
> > It's probably not worth the effort, but I wondered if the client could
> > attempt
> > to be a 'good citizen' and take some form of remedial action.
>
> I don't kn
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. Otherwise there is an
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
On Sat, 20 Sep 2014 08:35:59 +
Fons Adriaensen 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 thou
On Sat, Sep 20, 2014 at 04:41:31PM +0100, Will Godfrey wrote:
> 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 c
On 09-20, Fons Adriaensen wrote:
> The thing to be avoided is code that e.g. generates a heavy load
> every fourth period and does almost nothing in the three periods in
> between. Or a synth that generates a peak load whenever a voice is
> started and much less while the note lasts. IIRC yoshi/zyn
On Sat, 20 Sep 2014, Will Godfrey wrote:
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
On Sat, Sep 20, 2014 at 1:07 PM, Len Ovens wrote:
> On Sat, 20 Sep 2014, Will Godfrey wrote:
>
> 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
On Sat, Sep 20, 2014 at 01:30:43PM -0400, Paul Davis wrote:
> On Sat, Sep 20, 2014 at 1:07 PM, Len Ovens wrote:
> > Is it possible to deal with this in two threads? In the case of generating
> > audio, there is no "waiting" for audio to come in to process and the
> > processing could start for t
On Sat, Sep 20, 2014 at 12:34:28PM -0400, Mark D. McCurry wrote:
> On 09-20, Fons Adriaensen wrote:
> > The thing to be avoided is code that e.g. generates a heavy load
> > every fourth period and does almost nothing in the three periods in
> > between. Or a synth that generates a peak load wheneve
On 09-20, Fons Adriaensen wrote:
> Having to do 256 1024-point FFTs just to start a note is insane.
> It almost certainly means there is something fundamentally wrong
> with the synthesis algorithm used.
I agree with that notion.
In typical patches something between 2-10 IFFTs is expected and even
Hi,
JACK knows the internal execution order of calls to client process()
methods, and it could measure the time.
A new option for jackd, like --measure that will log the calls and times
for each cycle in a compact format (that could be further analysed).
So it would be possible to get more inform
On Fri, 19 Sep 2014 23:30:50 +0100
Will Godfrey wrote:
> On Fri, 19 Sep 2014 22:06:32 +
> Fons Adriaensen wrote:
>
> > On Fri, Sep 19, 2014 at 10:53:19PM +0100, Will J Godfrey wrote:
> >
> > > It's probably not worth the effort, but I wondered if the client could
> > > attempt
> > > to b
On Sun, Sep 21, 2014 at 4:31 PM, Will Godfrey
wrote:
> ually...
>
> This might seem a bit obvious, but am I right in thinking that while jack
> collects the current inputs it is at the same time pushing out the
> *previous*
> bufferful of data - hence latency.
>
you're wrong. sort of.
the simpl
On Sun, 21 Sep 2014 16:51:26 -0400
Paul Davis wrote:
> On Sun, Sep 21, 2014 at 4:31 PM, Will Godfrey
> wrote:
>
> > ually...
> >
> > This might seem a bit obvious, but am I right in thinking that while jack
> > collects the current inputs it is at the same time pushing out the
> > *previous*
>
23 matches
Mail list logo
