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

On Tue, 2 Sep 2014 14:31:59 -0700
"J. Liles" <malnourite@gmail.com> wrote:

> On Tue, Sep 2, 2014 at 1:00 PM, Philipp Überbacher
> <murks@tuxfamily.org> wrote:
>
> > On Tue, 2 Sep 2014 19:42:16 +0100
> > Harry van Haaren <harryhaaren@gmail.com> wrote:
> >
> > > On Mon, Sep 1, 2014 at 6:44 PM, J. Liles <malnourite@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@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user