[Jack-Devel] Notifications timing

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] Notifications timing

termtech
Our app uses inter-thread messaging to safely time, to the RT thread,
 critical modifications, instead of using say non-blocking atomic-safe
 lists and so on.

I read Jack1 notifies the client from the RT thread, and Jack2 uses a
 separate notification thread.

So it seems with Jack1, say inside a port connect callback, we /could/
 directly modify our local structures (routing lists) which our process
 callback depends on, without delay and safe and since it's all done
 in the same thread.

But with Jack2, what is the situation?
If the above operation is not a good idea with Jack2, how can we avoid
 delay associated with say, messaging another thread just to have that thread
 message our RT audio thread to do some safe modifications? (We do this now.)
Dangerous that our process callback might come along and attempt to use
 our local structures before we 'handled' the notification in another thread?
Will the process callback 'interrupt' the notification thread or occur very
 (too) close to it?

Thanks for any clarification.
Tim.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Notifications timing

Paul Davis


On Mon, Nov 17, 2014 at 11:04 PM, Tim E. Real <[hidden email]> wrote:
Our app uses inter-thread messaging to safely time, to the RT thread,
 critical modifications, instead of using say non-blocking atomic-safe
 lists and so on.

I read Jack1 notifies the client from the RT thread, and Jack2 uses a
 separate notification thread.

So it seems with Jack1, say inside a port connect callback, we /could/
 directly modify our local structures (routing lists) which our process
 callback depends on, without delay and safe and since it's all done
 in the same thread.

Your understanding there is correct.
 

But with Jack2, what is the situation?


I'll leave that to someone else, since I've so often gotten my descriptions of Jack2 incorrect.
 


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Notifications timing

termtech
On November 17, 2014 11:10:05 PM you wrote:

> On Mon, Nov 17, 2014 at 11:04 PM, Tim E. Real <[hidden email]> wrote:
> > Our app uses inter-thread messaging to safely time, to the RT thread,
> >  critical modifications, instead of using say non-blocking atomic-safe
> >  lists and so on.
> >
> > I read Jack1 notifies the client from the RT thread, and Jack2 uses a
> >  separate notification thread.
> >
> > So it seems with Jack1, say inside a port connect callback, we /could/
> >
> >  directly modify our local structures (routing lists) which our process
> >  callback depends on, without delay and safe and since it's all done
> >  in the same thread.
>
> Your understanding there is correct.

(Whoa you're fast. Seconds after I posted, the reply is there and the
 question is still not, after several minutes!)

> > But with Jack2, what is the situation?
>> If the above operation is not a good idea with Jack2, how can we avoid
>> delay associated with say, messaging another thread just to have that
>> thread message our RT audio thread to do some safe modifications?
>> (We do this now.)

I could try eliminating that intermediate thread and create a messaging
 ring buffer directly from the notification thread to our RT process callback.
The very next process callback will grab the messages, so it's safe
 and as fast as necessary.
That way it'll work transparently with both Jack1 and Jack2, and it
 won't have to block or wait.

>> Will the process callback 'interrupt' the notification thread or occur very
>> (too) close to it?
Still, would like to know if that is true or even a valid statement.
Thanks.

>
> I'll leave that to someone else, since I've so often gotten my descriptions
> of Jack2 incorrect.


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org