On Tue, 2 Sep 2014 14:31:59 -0700 "J. Liles" <malnourite@xxxxxxxxx> wrote: > On Tue, Sep 2, 2014 at 1:00 PM, Philipp Überbacher > <murks@xxxxxxxxxxxxx> wrote: > > > On Tue, 2 Sep 2014 19:42:16 +0100 > > Harry van Haaren <harryhaaren@xxxxxxxxx> wrote: > > > > > On Mon, Sep 1, 2014 at 6:44 PM, J. Liles <malnourite@xxxxxxxxx> > > > 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. Regards, Philipp _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
