Re: [LAU] Session management with NSM

From: J. Liles <malnourite@email-addr-hidden>
Date: Thu Sep 04 2014 - 03:27:11 EEST

On Wed, Sep 3, 2014 at 2:08 PM, Philipp Überbacher <murks@email-addr-hiddeng>
wrote:

> On Wed, 3 Sep 2014 20:27:11 +0100
> Harry van Haaren <harryhaaren@email-addr-hidden> wrote:
>
> > On Wed, Sep 3, 2014 at 7:57 PM, J. Liles <malnourite@email-addr-hidden> wrote:
> > > workflow that is already supported just fine by dealing
> > > with it 'manually'.
> > Yes, manually setting JACK before starting a session is the only and
> > best solution that scales. As you mentioned, transporting a session
> > to another machine would mean JACK's settings get borked: therefor
> > this is *not* something NSM should worry about, or implement.
>
> I completely disagree. Moving the session from one machine to another
> may be one use case, but a rather special one. At least it's not
> something I would do.
> On the other hand, remembering which jack settings are required for
> which session is something that NSM should remember for me.
> And given that I proposed the jackstart client as an optional client,
> something you can use or not use, same as jackconnect, your argument
> falls flat on its face since you could just not use the jackstart
> client and still handle jack manually.
>
> You would also not need to start all clients in a pre-defined order,
> you'd just need to make sure that jackstart starts before all others.
>

The complexity isn't much less if it's only one client. And then NSM needs
to know to treat that client specially...

>
> And be honest about one point: How many clients manage to 'live
> switch'? I guess that most don't. Even if they do, what's the cost? A
> few seconds at session switch time at most, which is completely
> negligible IMHO. I know that for you this is a feature that is
> important because other session management systems don't do it, but I
> seriously doubt that it matters for any other reason.
>

You can lead a horse to water...

People said the same thing about kernel suspend to RAM/disk. Yes, it took a
while to get everything working and there are still some drivers that don't
cooperate, but once you've seen the light you won't want to go back to
rebooting ever again. Seems like the dark ages now.

>
> Regards,
> Philipp
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Thu Sep 4 04:15:05 2014

This archive was generated by hypermail 2.1.8 : Thu Sep 04 2014 - 04:15:06 EEST