Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: =?iso-8859-1?Q?St=E9phane_Letz?= <letz <at> grame.fr>
Subject: Re: non-callback API
Newsgroups: gmane.comp.audio.jackit
Date: Thursday 21st April 2011 05:40:38 UTC (over 5 years ago)
Le 21 avr. 2011 à 00:03, Fons Adriaensen a écrit :

> On Wed, Apr 20, 2011 at 10:42:05PM +0200, Stéphane Letz wrote:
> 
>> I thin, the point of having jack_cycle_wait() and jack_cycle_signal()
was to be able to write:
>> 
>> 
>> while(true)
>> {
>> 	jack_cycle_wait()
>> 
>> 	// Do some work the require the new input buffers and produce output
buffers
>> 
>> 	 jack_cycle_signal()  // transfer control to next client in the graph
*ASAP* (especially important in a multi-core case when next clients can
start running)
>> 
>> 	// Possibly do some more work before suspending again until next cycle
>> 
>> }
> 
> 
> That is correct. But it should be possible to do exactly
> the same when using the callback mode:

I should check...
> 
> int process_callback(int nframes, void *arg)
> {
>    // Do some work.
>    // ...
>    // Input buffer are no longer required, output buffers
>    // are ready.
> 
>    jack_cycle_signal(); // Allows the next client to run.
> 
>    // Do some other work.
> 
>    return 0
> }
> 
> which mutatis mutandis is the equivalent of your example using
> the callback mode.
> 
> The only requirement for this to work is that returning from the
> callback and calling jack_cycle_wait() are exactly equivalent,
> that is either:
> 
> 1. They both require jack_cycle_signal() to be called before, or
> 
> 2. They don't, or
> 
> 3. They do the equivalent of jack_cycle_signal() if that was not
>   already called.
> 
> Currently, returning from the callback does the equivalent of
> calling jack_cycle_signal(), while calling jack_cycle_wait()
> doesn't (in my original proposal it did.). A clean implementation
> would give them exactly the same semantics, and to preserve the
> original callback API that would mean (3). In other words, using
> jack_cycle_signal() should be optional in either mode.
> 


But anyway I don't really see the point of your "clean" version.  The " set
process calllback" mode was the "historical" mode (classic, easy to
understand...), now we also have the "give you thread and use
jack_cycle_wait/jack_cycle_signal pair" that give all flexibility needed. 

I don't think we should break again the semantic, and the
jack_cycle_wait/jack_cycle_signal stuff has been there since1 or 2 years,
quite enough for any interested person to give valuable feedback....

Stephane
 
CD: 4ms