Re: [Fwd: Re: [Zynaddsubfx-user] Jack support in zynaddsubfx - help]

[Robert J. <rob...@da...>]

tisdagen den 09 december 2003 21.52 skrev Louis van Dompselaar:
> >      I haven't had time to try any of the modifications being discussed
> > yet, but I'm concerned that all of this additional buffering might kill
> > the synth's usefulness for realtime MIDI performance.
>
> I have to admit that it is slightly less responsive than the original
> 1.4.3.  Probably because of the added nframes-size delay.
>
> Does anyone know how long a Jack period is?

The period is the same as the period that jack set on the soundcard
E.g. jackd -d alsa -p 512

Then the buffer will be 512 frames.

>
> >  I also worry that this new
> > implementation might make the synth vulnerable to CPU usage by other
> > processes - wouldn't heavy GUI activity, for instance, possibly choke the
> > audio output, if it isn't part of the realtime Jack thread?
>
> It would and it does.  Feeding it loads of MIDI note ons at a time
> produces audio drop-outs, probably because the MIDI thread is blocking
> the Jack feeder thread.  However, in 1.4.3, this would cause
> zombification.  So I agree the current patch isn't a solution,
> but at least zynaddsubfx keeps on running.

Right, so what has been added in reality is just larger buffers... in a 
lowlatency situation it would not work. No zombies but lots of dropouts...

>
> >      I haven't looked at the code for a couple of weeks now, but I wonder
> > whether we could implement some sort of cueing system, whereby changes to
> > the engine data (creation and destruction of notes, parameter changes,
> > etc.) could be cued in the main application thread, and then processed
> > during the next callback cycle.
>
> I agree with you that we might be looking at buffering the wrong
> data.  Instead of output data, we probably should be buffering input
> data, so that none of those events need to block the sound engine
> and mutexes can be removed from that.
>
> I had a quick look at the Ardour code which seems to be able to
> handle loads more cpu activity within a Jack cycle.  That does
> indeed seem to use a queue for non-realtime events.

And that queue ought to be a lock free ringbuffer, yes?

/Robert
>
> One would have to have a way of knowing how many of these
> events can be handled within a Jack callback though.
>
> Louis
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Zynaddsubfx-user mailing list
> Zyn...@li...
> https://lists.sourceforge.net/lists/listinfo/zynaddsubfx-user