Nelson Posse Lago | 1 Jul 04:23 2002
Picon

Re: framesPerCallback and other musings

On Thu, Jun 27 2002 at 12:51:01am +0200, Andy Lo-A-Foe wrote:

> To make a long story short, you need initial tripple or quadruple buffering
> in your process() routine to prevent the stream from stalling after the
> initial non-zero output.

And when on the next run JACK asks for 3000 frames instead of 300, you'll
have a click on the sound output... that is, apart from the introduced
delay implicit with this approach, which is not exactly what JACK aims at
(although acceptable in this scenario, I think), this model can only work
if nframes is guaranteed to be constant.

See ya,
Nelson
--
Earth First! We'll ruin the other planets later.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Andy Wingo | 1 Jul 05:06 2002
Picon

Re: framesPerCallback and other musings

On Sun, 30 Jun 2002, Nelson Posse Lago wrote:

> On Thu, Jun 27 2002 at 12:51:01am +0200, Andy Lo-A-Foe wrote:
>  
> > To make a long story short, you need initial tripple or quadruple buffering
> > in your process() routine to prevent the stream from stalling after the
> > initial non-zero output.
> 
> And when on the next run JACK asks for 3000 frames instead of 300, you'll
> have a click on the sound output... that is, apart from the introduced
> delay implicit with this approach, which is not exactly what JACK aims at
> (although acceptable in this scenario, I think), this model can only work
> if nframes is guaranteed to be constant.

Why don't we go ahead and state that nframes is constant? I mean, that's
how it is, currently. It's nicely controlled by the user as well. And it
can make some DSP stuff easier. I think we gain in simplicity and don't
lose very much flexibility.

Paul, what do you think?

wingo.

ps. I'll apply the Solaris patches tonight. Sorry about the delay,
Stefan, I had a temporary lapse in motivation ;)

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
(Continue reading)

Joern Nettingsmeier | 1 Jul 10:47 2002
Picon

Re: Re: xruns revisited...

Paul Davis wrote:
> 
> >yeah. works reliably down to 256 samples bufsize, 64 if i don't touch
> >the system.
> 
> **bufsize** or period size ?

period size, sorry.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Paul Davis | 1 Jul 14:09 2002
Picon

Re: framesPerCallback and other musings

>Why don't we go ahead and state that nframes is constant? I mean, that's
>how it is, currently. It's nicely controlled by the user as well. And it
>can make some DSP stuff easier. I think we gain in simplicity and don't
>lose very much flexibility.
>
>Paul, what do you think?

i think its fine. i think its also what ASIO does. it provides a nice
demarcation point between the possibly-event-affected frame count of
LADSPA/VST's callback, and the constant frame size of the JACK/ASIO
one.

--p

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Martijn Sipkema | 1 Jul 15:39 2002

Re: framesPerCallback and other musings

> >Why don't we go ahead and state that nframes is constant? I mean, that's
> >how it is, currently. It's nicely controlled by the user as well. And it
> >can make some DSP stuff easier. I think we gain in simplicity and don't
> >lose very much flexibility.
> >
> >Paul, what do you think?
>
> i think its fine. i think its also what ASIO does. it provides a nice
> demarcation point between the possibly-event-affected frame count of
> LADSPA/VST's callback, and the constant frame size of the JACK/ASIO
> one.

What does it gain? I'm not sure there is a problem with the nframes not
being constant. There might be situations/hardware where a non constant
nframes would be easier.

I would think it is best to not have nframes constant unless there is a very
good
reason to. Perhaps ASIO has constant buffer size, EASI does not. Also with
triple buffering, there might be an advantage to do 2 periods at a time when
late.
Is there really an advantage for DSP algorithms? example?

--martijn

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
(Continue reading)

Kai Vehmanen | 1 Jul 14:52 2002
Picon
Picon

Re: framesPerCallback and other musings

On Mon, 1 Jul 2002, Martijn Sipkema wrote:

>>>Why don't we go ahead and state that nframes is constant? I mean, that's
> What does it gain? I'm not sure there is a problem with the nframes not
> being constant. There might be situations/hardware where a non constant
> nframes would be easier.

Read my messages about this issue from about a week or so ago. Certain
types of apps must implement i/o with JACK in a less efficient way if they
want to support the non-const nframes interface. And yes, the apps could
be rewritten to get around this problem, but no, not all aps will get
rewritten even if nframes stays non-const.

--
 http://www.eca.cx
 Audio software for Linux!

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Martijn Sipkema | 1 Jul 17:56 2002

Re: framesPerCallback and other musings

> >>>Why don't we go ahead and state that nframes is constant? I mean,
that's
> > What does it gain? I'm not sure there is a problem with the nframes not
> > being constant. There might be situations/hardware where a non constant
> > nframes would be easier.
>
> Read my messages about this issue from about a week or so ago. Certain
> types of apps must implement i/o with JACK in a less efficient way if they
> want to support the non-const nframes interface. And yes, the apps could
> be rewritten to get around this problem, but no, not all aps will get
> rewritten even if nframes stays non-const.

Ah, so it's not so much that a fixed size audio blocks are needed for
algorithms
and better performance, only that a lot of applications have been written
with
fixed size blocks in mind and they are not likely to be ported to variable
sized blocks. Those applications ask for the block size when opening the
ports and use that throughout?

I'm not sure if there is a lot of audio hardware that uses fixed rate
interrupts.

Of course if nframes is changed to be constant now, new applications will
also use this and that's probably not a good thing, since I don't see why
this
would be better.

Then again, perhaps all these existing applications won't ever get ported
and
(Continue reading)

Paul Davis | 1 Jul 17:22 2002
Picon

Re: framesPerCallback and other musings

>> Read my messages about this issue from about a week or so ago. Certain
>> types of apps must implement i/o with JACK in a less efficient way if they
>> want to support the non-const nframes interface. And yes, the apps could
>> be rewritten to get around this problem, but no, not all aps will get
>> rewritten even if nframes stays non-const.
>
>Ah, so it's not so much that a fixed size audio blocks are needed for
>algorithms
>and better performance, only that a lot of applications have been written
>with
>fixed size blocks in mind and they are not likely to be ported to variable
>sized blocks. Those applications ask for the block size when opening the
>ports and use that throughout?
>
>I'm not sure if there is a lot of audio hardware that uses fixed rate
>interrupts.
>
>Of course if nframes is changed to be constant now, new applications will
>also use this and that's probably not a good thing, since I don't see why
>this
>would be better.

i am not certain you understand the proposal.

its not to make nframes "A CONSTANT". its to make it "constant during
jackd's lifetime". whatever the user requests when starting jackd as
the frames-per-cycle setting - this is what the clients will be passed
in their process callbacks.

that is, its not going to be a single value all the time, but any
(Continue reading)

Martijn Sipkema | 2 Jul 00:35 2002

Re: framesPerCallback and other musings

> >> Read my messages about this issue from about a week or so ago. Certain
> >> types of apps must implement i/o with JACK in a less efficient way if
they
> >> want to support the non-const nframes interface. And yes, the apps
could
> >> be rewritten to get around this problem, but no, not all aps will get
> >> rewritten even if nframes stays non-const.
> >
> >Ah, so it's not so much that a fixed size audio blocks are needed for
> >algorithms
> >and better performance, only that a lot of applications have been written
> >with
> >fixed size blocks in mind and they are not likely to be ported to
variable
> >sized blocks. Those applications ask for the block size when opening the
> >ports and use that throughout?
> >
> >I'm not sure if there is a lot of audio hardware that uses fixed rate
> >interrupts.
> >
> >Of course if nframes is changed to be constant now, new applications will
> >also use this and that's probably not a good thing, since I don't see why
> >this
> >would be better.
>
> i am not certain you understand the proposal.
>
> its not to make nframes "A CONSTANT". its to make it "constant during
> jackd's lifetime". whatever the user requests when starting jackd as
> the frames-per-cycle setting - this is what the clients will be passed
(Continue reading)

Paul Davis | 2 Jul 00:17 2002
Picon

Re: framesPerCallback and other musings

>> my own would be that this doesn't help apps coded around fixed size
>> i/o, because there is every chance that jackd won't be running with
>> their notion of the "correct" size ...
>
>I'm not sure I understand. Are you saying you don't think a fixed audio
>block size (as in constant during jackd's lifetime) won't help porting
>applications
>that expect a constant audio block size to jack? Because if so, why should
>jack use a constant audio block size then?

no, the point is that if you look at the internals of something like
Csound, Pd, jMax etc., they typically want to compute "their" notion
of a fixed block size every "cycle". with their current design, they
then feed that block via a blocking write call to the device
driver (possibly via their own internal buffering as well). 

under JACK, this changes. it either becomes:

       * they continue to compute "myframes" of data, then
            deliver it to an intermediate buffer; the libjack thread
	    pulls data from this intermediate buffer during the
	    process() callback.

OR

       * they compute "nframes" during the process() callback

even if "nframes" is constant, there is every chance that its not the
number they most want to use.

(Continue reading)


Gmane