Re: [LAD] accepted use of sync callback

On Sat, Mar 26, 2011 at 07:50:12PM +0100, torbenh wrote:
> On Sat, Mar 26, 2011 at 04:45:51PM +0100, Lieven Moors wrote:
> > Hi Paul,
> >
> > Thanks for your reply.
> > I'm not sure my program would satisfy the realtime constraint.
> > But I'll have a look at both options again...
>
> using the sync callback to detect a skip in the transport is
> not adequate usage of it.
> an arpegiator is NOT a slow sync client. so... do not use the sync_cb !!!!
>

That's what I suspected...
I guess I will have to learn how to be a good slave :-)

Thanks,

lieven

>
> >
> > Greets,
> >
> > lievenmoors
> >
> >
> >
> > On Sat, Mar 26, 2011 at 11:18:20AM -0400, Paul Davis wrote:
> > > On Sat, Mar 26, 2011 at 11:08 AM, Lieven Moors <lievenmoors@email-addr-hidden> wrote:
> > > > Hi everybody,
> > > >
> > > > I have a question.
> > > >
> > > > I'm trying to figure out how to deal with transport locate changes
> > > > in my arpeggiator "flarps". I am generating MIDI events only when
> > > > necessary, so I'm not able to rewind the state of the program.
> > > > I only keep track of Note-off messages, because they can be sent
> > > > out in the future, to allow overlapping notes. All the MIDI notes
> > > > are calculated relative to each other. So I keep track of time
> > > > internally.
> > > >
> > > > So I only need to know the first frame of the period,
> > > > when somebody does a jack_transport_locate, and I need to know
> > > > when this happens so I can initialize the program state.
> > > >
> > > > My question is, if it would be acceptable to use the sync callback
> > > > to do this, because strictly speaking, my client wouldn't be a
> > > > slow sync client.
> > >
> > > its entirely appropriate.
> > >
> > > > Is there a more preferable way to do this, or should I do major
> > > > redesign, and use the time jack provides with each period directly.
> > >
> > > if you can do this in a way that still more or less meets the realtime
> > > constraint:
> > >
> > > T = F(nframes) + C
> > >
> > > (that is, time per process cycle is a linear function of the nframes
> > > value, plus a constant)
> > >
> > > then simply doing it in every process call is fine. if not, then use
> > > the sync callback.
> > _______________________________________________
> > Linux-audio-dev mailing list
> > Linux-audio-dev@email-addr-hidden
> > http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
> --
> torben Hohn
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Mar 27 04:15:01 2011