On Tue, May 19, 2009 at 8:33 AM, Krzysztof Foltman <wdev(a)foltman.com> wrote: there is a difficulty with this otherwise very clean approach. there are other applications that want to start (and potentially) stop jack. if a d-bus aware version of jack is installed instead of the non-dbus-aware one, then applications that do not use the control API for this will fail. ergo: installing the dbus aware version (potentially) breaks the operation of control apps that predate the control API. not the end of the world, but not good either. also, the current jack ecosystem is already deeply confused by the existence of jack1 and jack2, which have a few very subtle but important differences. adding yet another almost-the-same-but-different option is a PR disaster waiting to happen. --p

Krzysztof Foltman wrote: I agree that many people get confused at this point. However not many people are prepared to uninstall due to the associated issues with removing deps. Especially a dep as important as jack. It's also misleading to refer to the existing proven toolset which is quite useful to many professionals as "possibly dead end". That's verging on fud. Patrick Shirkey Boost Hardware Ltd

Paul Davis schrieb: couldn't jackdbus also install a ligh wrapper jackd that translates cmd-line args to dbus calls? Stefan

On Tue, May 19, 2009 at 08:40:58PM +0700, Patrick Shirkey wrote: Programs that do that kind of things have a name here: malware. I'm the boss on my system, and I will decide what goes into $PATH. Just as I decide which filesystems get mounted and where, and how permissions are set. Ciao. -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On Tuesday 19 May 2009 09:48:11 Fons Adriaensen wrote: Fons, I think some people have misunderstood some things you have said in this thread. In this case I think you misunderstood Patrick. (Or I did - not a bad possibility.) I think what he was saying was that jackdbus would check for jackd in $PATH and complain bitterly / refuse to sintall / whatever. Not that it would try and control what $PATH was set to. Or perhaps you got that and I misunderstood your objection. If there is proper understanding and objections / differences still remain, that is one thing. So often in life we are disagreeing with what we think people mean when if fact we may agree with what they actually mean. all the best, drew

Fons Adriaensen wrote: Not true. D-Bus-based jackd ties jackd to D-Bus. Nothing more, nothing less. You don't need a desktop or even X11 to have a session D-Bus. Krzysztof

On Tuesday 19 May 2009 15:03:28 Fons Adriaensen wrote: I am not so sure. (But I am open to being convinced.) If I write two programs which I know cannot coexist and I set it so that the newer one checks for the existence of the older one and pitches a hissy fit if a person tries to install both, is it really a problem. (I am not saying that I think this would be the ideal solution by the way.) I think I saw someone say that the dbus jack could be used without a desktop. (Is that the case? Anyone?) If so and it is indeed now tied in for your setup where it doesn't need to be, should we try and run down who is responsible for the tie in? In general though, I agree with you. I don't like people needlessly deciding one what people will and will not want to do and then needlessly deciding that they will prevent them from doing what they don't need to do. I have done some pretty odd things in my time for my own reasons and have been quite happy with the results, all things considered. all the best, drew

On Tue, May 19, 2009 at 05:07:13PM -0400, drew Roberts wrote: You cculd start a session dbus instance. Having to do that just to enable an app to talk to itself seesm a bit over the top. It could as well be requiring a web server to read a page it generated itself for itself. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On Wed, 20 May 2009 07:32:51 am Dan Mills wrote: The daemon itself is still a minimal system with RT priority. The part that has changed is the control part - which doesn't run with RT Priority. (that is my understanding anyways). This will not affect app developers unless your app tries to control jack. That means qjackctl, patchage and applicitions that try to start jack if they can't find it (ardour, others?) some of the command line utilities like jack connect. DBus is designed in such a way that it makes communicating with graphical applications easy but I am not aware of any dependence on a graphical environment. You can commands to a dbus aware application on the command line via the use of the dbus-send command this can be incorporated into shell scripts and the like. The syntax is bit verbose you can get some idea by using the dbus-monitor command to see what is being sent currently by your system. Pretty much all modern Linux systems use HAL + DBus + udev to configure hardware (especially finding new hardware that is plugged into a running system). Unless you are specifically removing this functionality then dbus will be on your system and running what is known as the 'system bus' whether you are in a graphical shell or a text based one. I would like to know what specific configurations Fons is working with and what specific objections he has to dbus - at the moment it sounds more emotive than objective. Is the objection the overhead of running a dbus session bus, That dbus has some specific limitations that the existing jack control methods don't have or is it that the current system is working perfectly and no change is necessary. Learning new ways of doing things takes time and effort. As far as I can see the specific problem occurred because somebody used an experimental package on a distro (the official jack version on Jaunty the current Ubuntu release unless I am very much mistaken is not a jack2 version). This package specifically contained the dbus version of jack which is not the recommended version. This version would not play with a graphical app that does not understand the dbus version of jack. Presumably the dbus version is only really for testing at the moment and should only really find it's way into most users hands once the whole toolchain is there. Once that happens it shouldn't make a real difference to the majority of users other than the config file being moved from one place to another and the format changing. For which I suggest a command line utility that can explicitly be used to convert the current file format to the new one. Users who have written a large amount of custom shell scripts may be affected. But I haven't heard anything about tools like jack-connect being removed and even if that were the case it would be pretty easy to replace them with shell scripts that use the dbus-send command. If Jack is not broken and doesn't need fixing. Why can't I stop jack reconfigure it and have all my jack apps auto-reconnect when the jack server comes back up. (or better yet - reconfigure the server without stopping it). Why can't I take a snapshot of everything running in jack and have be able to recall that snapshot including applications, connections, files that were open and positions within those files. KDE has been able to do this for the most part for a long time now (connections don't make sense in KDE and documents and positions only works in apps that support this ). In short why doesn't LASH work satisfactorily yet? I know I can write scripts to achieve a lot of that really isn't the best solution in this case. It's a good solution for setting up a general pipeline for creating music. But not for loading up an individual song you are working on. Unless you use exactly the same process for each song. Why can't I specify which ports to autoconnect to including no ports? -- The fellow sat down at a bar, ordered a drink and asked the bartender if he wanted to hear a dumb-jock joke. "Hey, buddy," the bartender replied, "you see those two guys next to you? They used to be with the Chicago Bears. The two dudes behind you made the U.S. Olympic wrestling team. And for your information, I used to play center at Notre Dame." "Forget it," the customer said. "I don't want to explain it five times."

alex stone wrote: It is quite high latency, mostly due to single-process userspace switch point. It performs reasonably well as long as overall message frequency is rather low. It can also efficiently push quite large messages through. But it is poor on handling high frequency of messages. Each message passing involves extra context switches to and from daemon and also copies of the message.

drew Roberts wrote: When KF explained it further, the impression I got was that you would have: /usr/lib/jack-x.y.z/jackd /usr/lib/jacdmp-q.r.s/jackd And then this: /usr/bin/jackd --> is a link to /whichever/one/root/has/picked Examples of this include Qt3/Qt4 install practices, and the Debian 'alternatives' system. -gabriel