Re: jackmidi: api cleanup

On Thu, Apr 05, 2007 at 02:12:48PM +0200, Stéphane Letz
wrote:

> The final solution seems quite elegant now, and I have
implemented  
> and tested it, but I don't see the point of keeping the
"status"  
> parameter in jack_thread_wait anymore.
> What would be the meaning of "status" now?

Whatever is the meaning of the process_callback() return
code.
It has exactly the same role: it indicates the 'status' of
the
user code whenever control passes from user code to
library.

Using the 'waiting' interface means that the calling
direction is
reversed. Compare these:

Pure callback mode:

   - process_callback() always returns without calling
jack_thread_wait().
   -> the library is calling the user code.

Pure waiting mode:
 
   - process_callback() never returns but always calls
jack_thread_wait().	
   -> the user code is calling the library.

The conclusion of the previous 'thinking steps' is that the
two
can be seamlessly merged: a client could even mix both modes

depending on the circumstances, and jack wouldn't feel any
difference. 

Reversing the calling direction means:

  function argument becomes return code
  return code becomes function argument

Hence the return code of the callback must be the argument
of
jack_thread_wait, and vice versa.

One thing I've ignored so far: would jack_thread_wait() 
require a jack_client_t* argument to be 'implementable' ?

This symmetry between the two modes would indicate that if
the
client pointer isn't required when process_callback()
returns
then it shouldn't be required either when
jack_thread_wait()
is called.

-- 
FA

Follie! Follie! Delirio vano è questo !



------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

Le 5 avr. 07 à 15:08, Fons Adriaensen a écrit :

> On Thu, Apr 05, 2007 at 02:12:48PM +0200, Stéphane Letz
wrote:
>
>> The final solution seems quite elegant now, and I
have implemented
>> and tested it, but I don't see the point of keeping
the "status"
>> parameter in jack_thread_wait anymore.
>> What would be the meaning of "status"
now?
>
> Whatever is the meaning of the process_callback()
return code.
> It has exactly the same role: it indicates the 'status'
of the
> user code whenever control passes from user code to
library.
>
> Using the 'waiting' interface means that the calling
direction is
> reversed. Compare these:
>
> Pure callback mode:
>
>    - process_callback() always returns without calling 

> jack_thread_wait().
>    -> the library is calling the user code.
>
> Pure waiting mode:
>
>    - process_callback() never returns but always calls 

> jack_thread_wait().	
>    -> the user code is calling the library.
>
> The conclusion of the previous 'thinking steps' is that
the two
> can be seamlessly merged: a client could even mix both
modes
> depending on the circumstances, and jack wouldn't feel
any
> difference.
>
> Reversing the calling direction means:
>
>   function argument becomes return code
>   return code becomes function argument
>
> Hence the return code of the callback must be the
argument of
> jack_thread_wait, and vice versa.

But the callback return code is also used as a way to
"stop" processing.
So what would be the behaviour of:

int process(jack_nframes_t nframes, void *arg)
{
	while (1) {
		SomeProcess1();
		nframes  = jack_thread_wait(client, 0);   	<== should
mean process  
continue??
		SomeProcess2();
		nframes  = jack_thread_wait(client, -1); 	<== should
mean process  
stops??
	}

	return 0;
}

The problem I see is how the user-code (process) is going to
stop  
processing... if it is not using the "status"
parameter of   
jack_thread_wait, then why keeping it?

Should we have something like:

int process(jack_nframes_t nframes, void *arg)
{
	while (1) {
		SomeProcess1();
		nframes  = jack_thread_wait(client);
		if (nframes == 0)    <=== would mean : library code
detected an  
error condition (like server has quitted...)
			return -1;
		SomeProcess2();
		nframes  = jack_thread_wait(client); 	
		if (nframes == 0)    <=== would mean : library code
detected an  
error condition (like server has quitted...)
			return -1;
		......
	}

	return 0;
}

>
> One thing I've ignored so far: would
jack_thread_wait()
> require a jack_client_t* argument to be 'implementable'
?

Yes, It has to access client data structure (thread....)
>
> This symmetry between the two modes would indicate that
if the
> client pointer isn't required when process_callback()
returns
> then it shouldn't be required either when
jack_thread_wait()
> is called.
>

I like symmetry also but I'm not sure it can completely be
done.

Stephane




------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On Thu, 2007-04-05 at 15:08 +0200, Fons Adriaensen wrote:
> On Thu, Apr 05, 2007 at 02:12:48PM +0200, Stéphane Letz
wrote:
> 
> > The final solution seems quite elegant now, and I
have implemented  
> > and tested it, but I don't see the point of
keeping the "status"  
> > parameter in jack_thread_wait anymore.
> > What would be the meaning of "status"
now?
> 
> Whatever is the meaning of the process_callback()
return code.
> It has exactly the same role: it indicates the 'status'
of the
> user code whenever control passes from user code to
library.
> 
> Using the 'waiting' interface means that the calling
direction is
> reversed. Compare these:
> 
> Pure callback mode:
> 
>    - process_callback() always returns without calling
jack_thread_wait().
>    -> the library is calling the user code.
> 
> Pure waiting mode:
>  
>    - process_callback() never returns but always calls
jack_thread_wait().	
>    -> the user code is calling the library.

Just a random thought:

Would it be beneficial/possible for the 'wait' call and the
'notify jack
we're done' call, so the thread can do something in the
interim?  e.g.

while (true) {
	jack_wait()

	read_input()
	process_things()
	deliver_output()

	jack_done()

	do_some_other_stuff()
}


do_some_other_stuff() must still adhere to realtime
requirements of
course.  This might be useful for doing things that need to
be
synchronous with the audio thread, but jackd itself doesn't
need to
waste time waiting on, like signalling a UI or performing
some
calculations for the next cycle.

-DR-



------------------------------------------------------------
-------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
chance to share your
opinions on IT & business topics through brief
surveys-and earn cash
http://www.techsay.com/default.
php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el