[Jack-Devel] port disconnection callbacks (JackPortConnectCallback)

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

[Jack-Devel] port disconnection callbacks (JackPortConnectCallback)

Matt Flax
Hi there,

I have registered a callback for port (dis)connections.

When my client connects its ports, the JackPortConnectCallback indicates
this occurance with the 'connect' variable = 1

When my client finishes playing, it stops by returning a non-zero number
from the audio processing function. If I stop the client in this manner,
then my JackPortConnectCallback doesn't get called.

I can see that the port has been disconnected from the client's inputs
and outputs.

I would expect that when the system disconnects those ports it calls the
JackPortConnectCallback with the 'connect' variable = 0

Is this the expected behaviour ?

Here is the version info :
jackdmp 1.9.10

thanks
Matt
_______________________________________________
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: port disconnection callbacks (JackPortConnectCallback)

Stéphane Letz
This is not clear for me if this is suppose to happen…

Le 9 oct. 2014 à 02:53, Matt Flax <[hidden email]> a écrit :

> Hi there,
>
> I have registered a callback for port (dis)connections.
>
> When my client connects its ports, the JackPortConnectCallback indicates this occurance with the 'connect' variable = 1
>
> When my client finishes playing, it stops by returning a non-zero number from the audio processing function. If I stop the client in this manner, then my JackPortConnectCallback doesn't get called.
>
> I can see that the port has been disconnected from the client's inputs and outputs.

What happens in the current jack2 implementation is that the RT thread is stopped, the client is marked "inactive", and this is probably what make the connecting begin inactive also.

>
> I would expect that when the system disconnects those ports it calls the JackPortConnectCallback with the 'connect' variable = 0
>
> Is this the expected behavior ?

Since this happens on in library side for now (RT thread is stopped…) there isn't anything in place to "signal" back the sever for what happens.
>
> Here is the version info :
> jackdmp 1.9.10
>
> thanks
> Matt

Probably we are in the "grey zone" here which means : something not completely well specified/designed/implemented.

Stéphane

_______________________________________________
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: port disconnection callbacks (JackPortConnectCallback)

Matt Flax
On 09/10/14 15:51, Stéphane Letz wrote:

> This is not clear for me if this is suppose to happen…
>
> Le 9 oct. 2014 à 02:53, Matt Flax <[hidden email]> a écrit :
>
>> Hi there,
>>
>> I have registered a callback for port (dis)connections.
>>
>> When my client connects its ports, the JackPortConnectCallback indicates this occurance with the 'connect' variable = 1
>>
>> When my client finishes playing, it stops by returning a non-zero number from the audio processing function. If I stop the client in this manner, then my JackPortConnectCallback doesn't get called.
>>
>> I can see that the port has been disconnected from the client's inputs and outputs.
> What happens in the current jack2 implementation is that the RT thread is stopped, the client is marked "inactive", and this is probably what make the connecting begin inactive also.
>
>> I would expect that when the system disconnects those ports it calls the JackPortConnectCallback with the 'connect' variable = 0
>>
>> Is this the expected behavior ?
> Since this happens on in library side for now (RT thread is stopped…) there isn't anything in place to "signal" back the sever for what happens.
>> Here is the version info :
>> jackdmp 1.9.10
>>
>> thanks
>> Matt
> Probably we are in the "grey zone" here which means : something not completely well specified/designed/implemented.

I understand what you are saying - the grey zone !
Something is disconnecting the ports. How would any object which is
monitoring ports, such as qjackctl or JackPortMonitor know that the
connection status has changed ?
Is there an alternative way to get notifications when  ports are
disconnected ?

Matt

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

_______________________________________________
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: port disconnection callbacks (JackPortConnectCallback)

Paul Davis


On Thu, Oct 9, 2014 at 2:55 AM, Matt Flax <[hidden email]> wrote:


I understand what you are saying - the grey zone !
Something is disconnecting the ports. How would any object which is monitoring ports, such as qjackctl or JackPortMonitor know that the connection status has changed ?
Is there an alternative way to get notifications when  ports are disconnected ?

they don't use a process callback.

stephane, this behaviour seems clearly wrong to me. given that a client without a process callback can receive the connect/disconnect callbacks, it doesn't seem right that a client which has just returned non-zero from its process callback would simply stop receiving them. does that seem right to you?

i thought jack2 delivered all non-process callbacks in a separate thread?
 

_______________________________________________
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: port disconnection callbacks (JackPortConnectCallback)

Stéphane Letz

Le 9 oct. 2014 à 13:49, Paul Davis <[hidden email]> a écrit :

>
>
> On Thu, Oct 9, 2014 at 2:55 AM, Matt Flax <[hidden email]> wrote:
>
>
> I understand what you are saying - the grey zone !
> Something is disconnecting the ports. How would any object which is monitoring ports, such as qjackctl or JackPortMonitor know that the connection status has changed ?
> Is there an alternative way to get notifications when  ports are disconnected ?
>
> they don't use a process callback.
>
> stephane, this behaviour seems clearly wrong to me. given that a client without a process callback can receive the connect/disconnect callbacks, it doesn't seem right that a client which has just returned non-zero from its process callback would simply stop receiving them. does that seem right to you?

No, I'm not saying that… just saying the client is "deactivated"...

>
> i thought jack2 delivered all non-process callbacks in a separate thread?
>  
Yep…

So maybe we should go back to the initial question; what is the client supposed to do when the process callback does not return 0?

Stéphane
_______________________________________________
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: port disconnection callbacks (JackPortConnectCallback)

Paul Davis


On Thu, Oct 9, 2014 at 8:32 AM, Stéphane Letz <[hidden email]> wrote:

Le 9 oct. 2014 à 13:49, Paul Davis <[hidden email]> a écrit :

>
>
> On Thu, Oct 9, 2014 at 2:55 AM, Matt Flax <[hidden email]> wrote:
>
>
> I understand what you are saying - the grey zone !
> Something is disconnecting the ports. How would any object which is monitoring ports, such as qjackctl or JackPortMonitor know that the connection status has changed ?
> Is there an alternative way to get notifications when  ports are disconnected ?
>
> they don't use a process callback.
>
> stephane, this behaviour seems clearly wrong to me. given that a client without a process callback can receive the connect/disconnect callbacks, it doesn't seem right that a client which has just returned non-zero from its process callback would simply stop receiving them. does that seem right to you?

No, I'm not saying that… just saying the client is "deactivated"...

>
> i thought jack2 delivered all non-process callbacks in a separate thread?
>
Yep…

So maybe we should go back to the initial question; what is the client supposed to do when the process callback does not return 0?

it is equivalent to having no process callback registered. the documentation in the header is slightly ambgious because it describes the behaviour of the callback rather than the registration:

/**
 * Tell the Jack server to call @a process_callback whenever there is
 * work be done, passing @a arg as the second argument.
 *
 * The code in the supplied function must be suitable for real-time
 * execution. That means that it cannot call functions that might
 * block for a long time. This includes all I/O functions (disk, TTY, network),
 * malloc, free, printf, pthread_mutex_lock, sleep, wait, poll, select, pthread_join,
 * pthread_cond_wait, etc, etc.
 *
 * @return 0 on success, otherwise a non-zero error code, causing JACK
 * to remove that client from the process() graph.
 */
int jack_set_process_callback (jack_client_t *client,
                   JackProcessCallback process_callback,
                   void *arg) JACK_OPTIONAL_WEAK_EXPORT;

so a client that has never called jack_set_process_callback() and a client that did but has returned non-zero from the process callback are semantically equivalent.
 

Stéphane


_______________________________________________
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: port disconnection callbacks (JackPortConnectCallback)

Stéphane Letz

Le 9 oct. 2014 à 14:57, Paul Davis <[hidden email]> a écrit :

> return 0 on success, otherwise a non-zero error code, causing JACK


When this is the documentation of the "jack_set_thread_init_callback" …

The documentation of jack_set_process_thread is " * @return 0 on success, otherwise a non-zero error code."

==> so?

Stéphane
_______________________________________________
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: port disconnection callbacks (JackPortConnectCallback)

Paul Davis


On Thu, Oct 9, 2014 at 9:04 AM, Stéphane Letz <[hidden email]> wrote:

Le 9 oct. 2014 à 14:57, Paul Davis <[hidden email]> a écrit :

> return 0 on success, otherwise a non-zero error code, causing JACK


When this is the documentation of the "jack_set_thread_init_callback" …

The documentation of jack_set_process_thread is " * @return 0 on success, otherwise a non-zero error code."

==> so?

this is why i said the documentation was ambiguous because it doesn't make it clear that the "@return" text describes the behaviour of the process callback, *not* jack_set_process_callback().


_______________________________________________
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: port disconnection callbacks (JackPortConnectCallback)

Matt Flax
On 10/10/14 00:12, Paul Davis wrote:


On Thu, Oct 9, 2014 at 9:04 AM, Stéphane Letz <[hidden email]> wrote:

Le 9 oct. 2014 à 14:57, Paul Davis <[hidden email]> a écrit :

> return 0 on success, otherwise a non-zero error code, causing JACK


When this is the documentation of the "jack_set_thread_init_callback" …

The documentation of jack_set_process_thread is " * @return 0 on success, otherwise a non-zero error code."

==> so?

this is why i said the documentation was ambiguous because it doesn't make it clear that the "@return" text describes the behaviour of the process callback, *not* jack_set_process_callback().


Let me try to understand a little of what's going on here ....

Is the original problem that the real time thread (which processes audio) is receiving a non-zero return from a client - which indicates to stop processing that client. At this point, the client's ports are disconnected by the real time thread.

The non-realtime thread is the one which executes port (dis)connection callbacks ... this non-realtime thread has no way of knowing that the real time thread has had a client change.

Matt

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