[LAD] jack-session finally merged.

torbenh torbenh at gmx.de
Fri Apr 2 01:51:10 UTC 2010

On Thu, Apr 01, 2010 at 10:47:49PM +0200, Nick Copeland wrote:
> Hi Torben,
> A few questions that I cannot seem to dig out of the otherwise very useful
> diffs:
> What tools are available to test Jack session manager code? The examples
> only seemed to deal with the client side of things, not the actual session
> manager itself so I was wondering how the client code can be exercised.
> No interest in adding something like the following:
> enum JackSessionEventType {
>     JackSessionLoad = 4,
> Maybe this has already been discussed in which case just drop it. The
> interest was an ability to reload the same session settings without having
> to break down and restart all the apps - is there another way to do this as
> it looked a bit like the session files were only read by the client at init time.

it hasnt been discussed to very big extent.
but basically its not so easy to implement everywhere (some apps would
need to kill their jackclient which isnt possible.)

but i dont really see the big problem in killing an app and restarting
it right away.
most of the mapped memory will still sit in caches, and this will happen
pretty fast.

additionally it needs quite a lot of logic in the sessionmanager.

the SM can provide the same functionality with the means it has
currently. maybe it will take 1 second instead of half a second.

> I am a bit confused about the following from the seq24 diffs:
> +    Glib::ustring cmd( "seq24 --file \"${SESSION_DIR}file.mid\" --jack_session_uuid " );
> ...
> +    m_jsession_ev->command_line = strdup( cmd.c_str() );
> This is the command string used to start the app the next time around. What about
> other options that might have been given the first time around? If an app does not have
> them saved with the user settings then are pure runtime options lost? Is it the applications
> responsibility to ensure that the 'file' above contains all the parameters needed to start

yes it is. or it must rebuild the correct commandline.
but thats not too hard.

> the app in the same way? Just curious, it puts a bit more onus onto the app developer
> rather than the session manager.

how would the session manager handle this ?
it cant know what the correct options are to reload the app with a
session file.

> What does the UUID consist of?

currently its a number.
but treat it as a string.
its not specified what it really is.

torben Hohn

More information about the Linux-audio-dev mailing list