On Tue, 2007-12-18 at 16:56 +0200, Nedko Arnaudov wrote: libjack needs to start the server automatically just like it does now. How does that work with the D-Bus control thing? --ll

Nedko Arnaudov wrote: In normal situations, this jackd process (the launcher) would be only short-lived (less than a second). It might hang for some reason, because of faulty driver or something else, but then it would be a rare exception, not a rule. Plus, it's no worse than what would happen in non-dbus jack (where jackd would be present in process list, but would not respond). If the "jackd in engine mode" (jackd started with --dbus) is running, applications are able to connect, aren't they? Or maybe you should describe your "jackd process running, apps can't connect" scenario in more detail, in case I got it wrong? Basically, what turn of events results in jackd running but not responding to events? Krzysztof

Krzysztof Foltman &lt;wdev(a)foltman.com&gt; writes: There is no such thing as starter process implemented. By me - for sure. From what I've understood from Dave's patch - by him too. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

Krzysztof Foltman &lt;wdev(a)foltman.com&gt; writes: From what i've understood of Dave's patch, it enables jackd executable to start jackdbus thing (same executable). I.e. no separate launcher executable. jack controller dbus object is... controller, not server. it allows you to mange jack server. This includes starting stopping jack server and also configureing it. Some terms explained: * jack server is the what is seen by jack clients (audio/midi, through libjack). * jack controller is a dbus object that can start jack server * jackd is the name of the executable starting jack server and parsing commandline arguments to configure both engine and driver * jackdbus is the name of the executable providing jack controller dbus object. it can start jack server, amoung other things it can do. Discalimer: this is how it works now, not how Dave made it work. You can have jackdbus process running and server stopped. And this happens when you have jack controller dbus object activated but server not started. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

Krzysztof Foltman &lt;wdev(a)foltman.com&gt; writes: yes, this is what i mean will work no particular disadavantages, i agree. Some more thoughts: - this seems like trying to push something square into round hole. But if that will help, then it may be worth to implement it - non-technically competent users should not use process list and assume things they dont understand by definition. - technically competent users should *read* how things are working. - i bet that most techincally competent users will get confused by changing process name on the fly - dbus is there to simplify things not complicate them. users should determine if server is working by using their control/monitor app. this means looking at tray icon by Marc, or dockapp by me, or calling jack_control status and examining the result (it has return value tha can be checked too). - Using process list is poor man approach when things are not working as expected. This implies techically competent user anyway. - this is a political issue that i personally think should be handled by distro packagers (power users, super technically competent). -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

On Dec 18, 2007 6:09 PM, Nedko Arnaudov &lt;nedko(a)arnaudov.name&gt; wrote: Alpha release comming soon I hope. I also hope (and that's why I'm working hard on this) that trying Nedko's patch with these applets will make it clearer for everyone how cool a feature a dbus control interface can be. Although I like very much (and use) Rui's qjackctl, the simplycity brought by dbus cannot be ignored. The new logfile feature is also very interesting in my opinion. cheers ;-) __________________ Marc-Olivier Barre, MarcO'Chapeau.

On Tue, 2007-12-18 at 18:24 +0200, Nedko Arnaudov wrote: It just does whatever jackdbus did when run as jackd --dbus. If that means it's running as some separate launcher thing that isn't in fact jackd, then that'll need fixing. It /appears/ to work as it should anyway I don't see why there is confusion or debate involved here to be honest. This separate executable thing is just plain weird from the user perspective. Making everything more complicated and requiring users to take a day course in weird d-bus lingo to start jack isn't progress: jack_control start If that doesn't start jackd, it doesn't do what it should. That aside, everything else about the d-bus stuff looks pretty good -DR-

Fons Adriaensen &lt;fons(a)kokkinizita.net&gt; writes: So you failed to understand how it works, thus how jackdbus differes From jackd, and yet you think it should work in some other way? :D Or I've misunderstood you? Exactly the reason to not destroy existing well working application (jackd) is the main reason I made jackdbus separate app. The useful feature is one you mentioned, to separate control interface. It also adds the logfile thing. Also it adds settings persistence on jack side, so you dont need to have cryptic ~/.jackdrc file, edited either by hand or by control app that needs to know what jackd options are (moving target, also depends on drivers used). Actually I think both settings persistence and logfile can be used by jackd too, but this will probably not happen anytime soon. At least for settings persistence, Paul told me once that it is probably post 1.0 (guess when is that :D). I we had server lib, to be reused by both jackd and jackdbus, jackdbus could be made completely separate app, it will not need compile time access to jack sources. Unfortunately, I dont think this can be made easily and in non-intrusive way. Can you explain what you mean by solving things at desktop level? -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

Fons Adriaensen &lt;fons(a)kokkinizita.net&gt; writes: Well I use mixed approach, hide things for unexperienced users and make it just work, while still allow diagnostics using log file, process list, etc for advanced users. Main purpose is not to make it easy for unexperienced users, but to make it more usable for advanced users, i.e. log file and separate control interface. The ease of use for unexperienced users comes with tools that are (already!) built upon the control/monitor interface. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

On Wed, 2007-12-19 at 23:55 +0100, Fons Adriaensen wrote: Straightforward via being a toy. You can't express anything that isn't a command line option in it, and you can only set up a single jack configuration. A single line with a command in it isn't a configuration file, it's a shell script with the hashbang missing ;) Jack needs a /real/ configuration file. One good example of something to go there is port aliases, and setting (or un-setting) the default auto-connect ports (voila, the old auto connect problem solved). -DR-

Dave Robillard &lt;dave(a)drobilla.net&gt; writes: It is not, it is a feature that allows you to change settings. This can be (and is usually) done with stopped server. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>