[LAU] Session management with NSM

[J. Liles]

On Tue, Sep 2, 2014 at 2:50 PM, Philipp Überbacher <murks at tuxfamily.org>
wrote:

> On Tue, 2 Sep 2014 14:31:59 -0700
> "J. Liles" <malnourite at gmail.com> wrote:
>
> > On Tue, Sep 2, 2014 at 1:00 PM, Philipp Überbacher
> > <murks at tuxfamily.org> wrote:
> >
> > > On Tue, 2 Sep 2014 19:42:16 +0100
> > > Harry van Haaren <harryhaaren at gmail.com> wrote:
> > >
> > > > On Mon, Sep 1, 2014 at 6:44 PM, J. Liles <malnourite at gmail.com>
> > > > wrote:
> > > > > This is something that would go into the .desktop files of
> > > > > applications as a capability
> > > >
> > > > Cool: then its time to make it work in the UI, and after that
> > > > bug-report every app that is useful with NSM and doesn't have it
> > > > in its .desktop.
> > >
> > > Agreed, I think it's doable. It is little work per-program. I think
> > > it would be sensible to check how real the performance issue is,
> > > but the mtime check Len suggested plus some caching would take care
> > > of it most of the time if the performance issue is real at all.
> > >
> > > > > Certainly I have no intention of adding any qjackctl like
> > > > > configuration features.
> > > > Which also isn't what I'm suggesting
> > >
> > > I agree here too. All I imagine is something that is able to start
> > > jack before everything else, nothing more than that. On the UI side
> > > it could be a simple field where you enter the jackd command you
> > > want to use for this session.
> > >
> >
> > The whole idea of killing and restarting JACK is totally incompatible
> > with session 'switch' functionality. All clients would have to be
> > killed, JACK killed, JACK restarted, and clients restarted. Probably
> > even if the configuration isn't different, as it would be a PITA to
> > try to model JACK's state in that way.
> >
> > To me, this looks like creating problems and complexity for no real
> > benefit. If autostart doesn't work, then that's a JACK problem and
> > should be fixed there. Or--just don't rely on autostart in the first
> > place. IMHO that's more of a workaround to allow 'desktop' type use
> > of JACK apps (probably with auto-connect as well) and doesn't apply
> > to a production workflow.
>
> I have the feeling that we are talking past each other for some reason.
>
> You kill and start all programs anyway if you switch sessions, why not
> jack as well? It would only be natural. To be honest, I did not
> consider the killing jack part so far.
>
> How would you go about things as it is now if you want to switch
> between sessions that require different sample rates?
> You would close session one, kill jack, restart jack with the settings
> required for session two and start session two. Why not include that in
> the session management? It seems like the logical thing to do.
>
> I do not want to rely on autostart, I want to explicitly start jack
> with specific per-session settings as part of the session management.
>
> I hope that makes things a bit clearer.
>

I do not do that though. NSM is the only session manager to support live
'switch'ing of sessions--no programs have to be restarted that support the
'switch' functionality (all the non stuff does).

The only reason I can think of that you'd want to swtich to a session with
a different sample rate is if you're swtiching between e.g. making music
and doing cinema sound track or somesuch and there are many other things
you'd likely want to change for that as well.

I think it's stretching quite a bit to argue that this (including JACK's
setup in the session) is necessary functionality.

To make my position clear, let me define an example of my workflow:

1. Make coffee
2. Start JACK with the desired parameters for the type of work I'm planning
to do. E.g. buffer size
3. Run NSM
4. Open session and work on it.
5. Switch to other (related sessions) [why would these be at any other
sample rate
6. If I need to alter JACK's parameters, stop session, run e.g.
jack_bufsize, reopen session
7. Get work done instead of dreaming up ways to implement complicated
features nobody actually needs

But wait, there's more...

Now I want to work on the road, so I sync the relevant sessions to my
laptop. My laptop has a different sound card and requires different JACK
settings (and it much more limited in ability to achieve low latencies).

In my workflow, this presents no problem. If I implemented this JACK
configuration feature, then I would have CREATED a problem where there were
none before.


Hopefully you can see why I'm not interested in implementing this feature.






>
> Regards,
> Philipp
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20140902/a7ed3686/attachment-0001.html>