3 Sep
2014
3 Sep
'14
12:06 a.m.
On Tue, Sep 2, 2014 at 2:50 PM, Philipp Überbacher <murks(a)tuxfamily.org>
wrote:
On Tue, 2 Sep 2014 14:31:59 -0700
"J. Liles" <malnourite(a)gmail.com> wrote:
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.
On Tue, Sep 2, 2014 at 1:00 PM, Philipp
Überbacher
<murks(a)tuxfamily.org> wrote:
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.
On Tue, 2 Sep 2014 19:42:16 +0100
Harry van Haaren <harryhaaren(a)gmail.com> wrote:
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. On Mon, Sep 1, 2014 at 6:44 PM, J. Liles
<malnourite(a)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.
Regards,
Philipp
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user