shutdown hook when attempting to connect non-running Jack
Carl H Janson
Hello group
The Jack client we made receives a shutdown hook if a connection attempt is made towards a Jack server that is not started. OSX. Is this as it should be ?
Kind regards
Carl Henrik Janson
Neil C Smith
> Hello group
>
>
>
> The Jack client we made receives a shutdown hook if a connection attempt is
> made towards a Jack server that is not started. OSX. Is this as it should be
> ?
>
Simply put, yes! This is the behaviour of both current server
implementations. The JavaDoc for shutdown() should probably be more
specific that this method may be called by the server even if
configure() has not been called (ie. if server fails to start). It is
safer to ensure shutdown() is called than to never call it.
Best wishes,
Neil
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
Carl H Janson
to filter away shutdown hooks that are really connection rejections during
initialisation process, in that class? This "connect reject" result is never
the less subject to a catch in our client since JackAudioServer throws an
exception ?
Rgds
Carl
Best wishes,
--
JAudioLibs - http://code.google.com/p/java-audio-utils/
You received this message because you are subscribed to the Google
Groups "JAudioLibs" group.
To post to this group, send email to jaudi...@googlegroups.com
To unsubscribe from this group, send email to
jaudiolibs+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jaudiolibs?hl=en?hl=en
Neil C Smith
Simply put, no. You're assuming that the client and the code that runs the server are the same thing, whereas they may be in completely different packages / modules. It should be easy enough to differentiate the different cases within your client code.
Best wishes,
Neil
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
(sent while mobile through GoogleMail)
Carl H Janson
Yes, this is easy to differentiate and not a big issue at all, but this way of doing it causes a defilement of Jack control intelligence, not? For my enhanced understanding only, can you please exemplify what you mean with “the code that runs the server” ?
Thanks,
Carl
Neil C Smith
> Yes, this is easy to differentiate and not a big issue at all, but this way
> of doing it causes a defilement of Jack control intelligence, not?
I have no idea what you mean here!
> For my
> enhanced understanding only, can you please exemplify what you mean with
> “the code that runs the server” ?
>
>
The code that calls run() on the (Jack)AudioServer may have no
knowledge or access to the AudioClient implementation. Therefore
catching the Exception thrown there does not mean you can adequately
dispose the client, as you are assuming.
Praxis (for which this code is originally developed) makes a lot of
use of the Service Provider Interface model, as does the NetBeans
platform on which it is based. The AudioServer API is designed to
cater for the fact that the AudioServer implementation, the
AudioClient implementation and the code which manages the audio thread
and calls run() all come from different packages where the specific
implementations may be private.
Carl H Janson
Thanks for your response. I think we have a satisfactory solution for our
needs, but nevertheless; a couple of remarks below.
Carl
-----Original Message-----
From: jaudi...@googlegroups.com [mailto:jaudi...@googlegroups.com] On
Behalf Of Neil C Smith
Sent: 19. januar 2012 10:28
To: jaudi...@googlegroups.com
Subject: Re: [jaudiolibs] shutdown hook when attempting to connect
non-running Jack
On 19 January 2012 08:49, Carl H Janson <c...@hdsoundlab.com> wrote:
> Yes, this is easy to differentiate and not a big issue at all, but this
way
> of doing it causes a defilement of Jack control intelligence, not?
I have no idea what you mean here!
[Carl Henrik ] I looked up the word defilement on Google translate, and got
"uncleaniness" or something like that. I think "spread" is a better word for
what I was trying to say. I was imagining defilement to mean something
neutral like "forking". Sorry! But to respond:
Since the audioClient (a SoundPimp class implementing AudioClient) may
receive the exact same shutdown hook in at least two states, namely after
"sudden Jack malfunction" and if "unable to connect to Jack at all", there
could be a need for an interpreter (intelligence) that keeps track of this,
so as to create precise user interaction from the shutdown callback that is
ambiguous because it is invariant.Further:
The connect is implicit in the run(). One alternative is to run() which in
itself requires a try catch, then do a connectRequest, then await
accept/reject-with-a-reason, then at other times receive a shutdown hook
when things go awry. Thus, keeping as much handling of connections as
possible in the AudioClient. No big deal!
> For my
> enhanced understanding only, can you please exemplify what you mean with
> "the code that runs the server" ?
>
>
The code that calls run() on the (Jack)AudioServer may have no
knowledge or access to the AudioClient implementation.
[Carl Henrik ] Confirmative, normal case to my understanding. I just want
AudioServer to deliver, keep me out of practical details to the extent
possible, so to speak.
Therefore
catching the Exception thrown there does not mean you can adequately
dispose the client, as you are assuming.
[Carl Henrik ] I am not sure if I am assuming that, but one could say that
this is dependent on how SoundPimp interacts with the user. An exception
received as a result after run() will probably work just fine as input to
creation of a user GUI dialog with these instructions:
"Could not connect to the Jack Audio system. Have you remembered to start
the JackPilot ? After that, click the refresh button on the SoundPimp
dashboard..."
It means this solution is not auto-recovery but require manual user action.
Then in the other situation; sudden shutdown, the GUI message could be
different from that example, e.g. "connection was lost, please follow these
guidelines to restart things...."
To keep more than strictly necessary "surveillance" out of SoundPimp
callback class, since this is already a part of AudioServer, something like
the enum State {} of class AudioServer adequately describing what event took
place, could perhaps be part of AudioClient interface ?
Praxis (for which this code is originally developed) makes a lot of
use of the Service Provider Interface model, as does the NetBeans
platform on which it is based. The AudioServer API is designed to
cater for the fact that the AudioServer implementation, the
AudioClient implementation and the code which manages the audio thread
and calls run() all come from different packages where the specific
implementations may be private.
[Carl Henrik ] yes. I am tempted to take a closer look at the use of NB as
general platform as time may allow. Interesting concept you have there. I
also look forward to taking a look on Praxis!
Neil
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
--