Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Paul Davis schrieb: On Tue, May 19, 2009 at 8:33 AM, Krzysztof Foltman w...@foltman.com wrote: A better way: allow only JACK-legacy or JACK-DBUS to be installed at the same time. Situations where both jackd and jackdbus need to be used on the same system are rare enough to ignore them. 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. couldn't jackdbus also install a ligh wrapper jackd that translates cmd-line args to dbus calls? Stefan 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Perhaps someone who knows could explain briefly how reliable the dbus daemon is in terms of frequency of calls made in and out, and the timing involved. For example, does the daemon make calls continually in and out, much like a dongle in commercial software, and does it do so in an ordered fashion? Or does the daemon only serve to switch things on and off? Alex. -- Parchment Studios (It started as a joke...) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
alex stone wrote: Perhaps someone who knows could explain briefly how reliable the dbus daemon is in terms of frequency of calls made in and out, and the timing involved. 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tuesday 19 May 2009 23:05:51 Danni Coy wrote: Learning new ways of doing things takes time and effort. Outside of this discussion, I think this is an important thing to keep in mind. Let me explain it this way: It irks me when people change things gratuitously and force me to spend my time learning essentially the same things again when I could spend that time learning new things. If things need to be changed, fine and dandy. I have no problem with that. But please don't obsolete a whole bunch of my hard earned knowledge for no reason other than *fashion*. all the best, drew ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, 19 May 2009 10:38:24 +0200, Stéphane Letz l...@grame.fr wrote: 4) A possible proposed solution was to define 2 completely separated packages for jack2 : the classic one would package the jackd incarnation and allow Qjackctl and legacy control applications to be used with it. The D-Bus one would package the jackdbus incarnation, and provide D-Bus bas control applications (patchage, ladi tools). The problem of this strategy is that..., it is a kind of complete failure regarding the way jack is supposed to be distributed. It may even get worse if a new jackosc incarnation (a one that would allow to control the server using OSC) appears a some point in the future... And we will all agree that this would be a packaging disaster. I package jack for gentoo pro-audio, and I really don't know how I'd handle this one. 5) Another idea would be improve the choice of auto-start strategy by providing a runtime choice for that: a way for the user to select between the classic, D-Bus, OSC, strategy once globally for a given working session... To me, this one is the cleanest of all, and would allow to keep auto-start for those who like it with the flavor of their choice (and eventually disable it for those who don't ?) 5) Another idea would be be to completely drops the auto-start strategy...This way we don't have multiple strategy anymore, and solve most of the problems... but loose a feature. Last resort but if it comes down to this, I can handle my idea of auto-start directly inside LADITools using dbus calls. although it wouldn't be as good as the any client can auto-start jack paradigm. Marc-Olivier Barre. -- Participez au black-out anti-HADOPI : http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, May 19, 2009 10:32, Stéphane Letz wrote: (there are two 5)'s above but i'll refer to the first one) i vote for the 5) auto-start strategy. user selects which one he/she prefers. the default should be classic and i would add fallback to d-bus and/or osc whatever. i still fail to see the problem of honoring .jackdrc if it exists on your home directory. ie. if .jackdrc exists then do the classic auto-start; if not, check d-bus service; etc. byee -- rncbc aka Rui Nuno Capela rn...@rncbc.org But since some applications like Qjackctl or Ardour write this .jackdrc file in a possible hidden way for the average user, then the system possibly goes back in the classic auto-start strategy, without any knowledge of that. qjackctl can already opt to not write any .jackdrc. ardour may vary. i would assume it to use the jack control api in a near future. the same would apply to qjackctl. then everybody will be happy again ;) i was asking for a default strategy, call it auto, which will try classic first, then d-bus, then whatever. the main question, at least in my mind, is all about *which* settings will be used to auto-start the server, isn't it? an explicit command line, as in classic, should *always* take precedence over the settings in any internal configuration database, which i think the d-bus honors instead and that latter behavior is being the root of all d-bus evil. scnrt ;) cheers -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Le 19 mai 09 à 12:37, Rui Nuno Capela a écrit : On Tue, May 19, 2009 10:32, Stéphane Letz wrote: (there are two 5)'s above but i'll refer to the first one) i vote for the 5) auto-start strategy. user selects which one he/she prefers. the default should be classic and i would add fallback to d-bus and/or osc whatever. i still fail to see the problem of honoring .jackdrc if it exists on your home directory. ie. if .jackdrc exists then do the classic auto-start; if not, check d-bus service; etc. byee -- rncbc aka Rui Nuno Capela rn...@rncbc.org But since some applications like Qjackctl or Ardour write this .jackdrc file in a possible hidden way for the average user, then the system possibly goes back in the classic auto-start strategy, without any knowledge of that. qjackctl can already opt to not write any .jackdrc. ardour may vary. i would assume it to use the jack control api in a near future. the same would apply to qjackctl. then everybody will be happy again ;) i was asking for a default strategy, call it auto, which will try classic first, then d-bus, then whatever. the main question, at least in my mind, is all about *which* settings will be used to auto-start the server, isn't it? an explicit command line, as in classic, should *always* take precedence over the settings in any internal configuration database, which i think the d-bus honors instead and that latter behavior is being the root of all d-bus evil. scnrt ;) cheers -- My feeling is that is we choose the runtime auto-start strategy, then we should not mix anything concerting setting management. Each incarnation of server has it's own view of setting management and this has to stay completely separated from any other view. If the used chose classic auto-start strategy (that would stay the default yes) then he is supposed to know that he has to use classic control tools (Qjackctl..). If the user chose D-Bus auto-start strategy, then he knows he has to use D-Bus aware control tools only and so on... Stephane ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Some env variable or similar would be a lot better, but it's also important that this doesn't interfere with the manual start of jackd in any way, so you can have it autostart with dbus, kill it, start it manually without dbus. Regards, Philipp ___ Concerning implementation, we already have a JACK_NO_START_SERVER env variable that allows to globally disable the auto-start feature. We could possibly define a new JACK_AUTOSTART_MODE (or whatever) that could take classic, dbus or osc... Stephane ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, 2009-05-19 at 11:37 +0100, Rui Nuno Capela wrote: the main question, at least in my mind, is all about *which* settings will be used to auto-start the server, isn't it? an explicit command line, as in classic, should *always* take precedence over the settings in any internal configuration database, which i think the d-bus honors instead and that latter behavior is being the root of all d-bus evil. scnrt ;) If jackdbus migrated the settings from .jackdrc the first time it is run that would probably save a lot of hassle. Damon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tuesday 19 May 2009 05:44:13 Stéphane Letz wrote: Le 19 mai 09 à 11:30, Fons Adriaensen a écrit : On Tue, May 19, 2009 at 10:38:24AM +0200, Stéphane Letz wrote: 5) Another idea would be improve the choice of auto-start strategy by providing a runtime choice for that: a way for the user to select between the classic, D-Bus, OSC, strategy once globally for a given working session... I will be writing an OSC layer (on top of the existing interfaces) because I badly need a soluting for scriptable (i.e. non-interactive) remote control of jackd. It will be non-invasive and just use the existing jackd/libjack without modifying anything. There will be no such thing as an 'OSC autostart strategy'. IMHO dbus could be just the same. This would mean that any advantages it may bring will be there only if app writers start using it *explicitly* by directly calling dbus instead of a jackd/libjack C API function. Which just means that dbus will have to prove its value in the market instead of being forced onto everyone, and that is a Good Thing (TM). Support for accessing dbus could even be integrated in libjack (or some new library) as long as it just adds ew calls and does not modify the action of any existing C API call. Ciao, -- FA It seems you really don't want to see that using this jack_client_open does a fork+exec call to launch jackd with the ./ jackdrc file has been completely *hard coded* in libjack from day one! And is a really strong constraint for any possible new way of controlling the server. The discussion is now: do we keep this hard coded thing in libjack or do we try to relax it a bit ? Doesn't my idea of having the new way check for the old way on start and translate between the two solve this issue? (And write the old way file on new way changes. Also wouldn't having a commandline switch: jackd --way new|old|dbus|osc|classic|whatever do the job? (speaking from vast fields of ignorance here I know.) Stephane all the best, drew ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, 2009-05-19 at 11:32 +0200, Stéphane Letz wrote: But since some applications like Qjackctl or Ardour write this .jackdrc file in a possible hidden way for the average user, then the system possibly goes back in the classic auto-start strategy, without any knowledge of that. a) very few jackd users are unaware of hidden .files b) it works! what could possibly be wrong with that? /j ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Felipe Sateler fsate...@gmail.com writes: Stéphane Letz wrote: My feeling is that is we choose the runtime auto-start strategy, then we should not mix anything concerting setting management This sounds weird to me. There should be only one canonical configuration file for jack, independent of how it was started. What canonical means? Something achieved through massacre? Or something achieved through evolution? -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpUZKUy9P8iA.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, May 19, 2009 at 8:33 AM, Krzysztof Foltman w...@foltman.com wrote: A better way: allow only JACK-legacy or JACK-DBUS to be installed at the same time. Situations where both jackd and jackdbus need to be used on the same system are rare enough to ignore them. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Stéphane Letz wrote: Le 19 mai 09 à 12:37, Rui Nuno Capela a écrit : On Tue, May 19, 2009 10:32, Stéphane Letz wrote: (there are two 5)'s above but i'll refer to the first one) i vote for the 5) auto-start strategy. user selects which one he/she prefers. the default should be classic and i would add fallback to d-bus and/or osc whatever. i still fail to see the problem of honoring .jackdrc if it exists on your home directory. ie. if .jackdrc exists then do the classic auto-start; if not, check d-bus service; etc. byee -- rncbc aka Rui Nuno Capela rn...@rncbc.org But since some applications like Qjackctl or Ardour write this .jackdrc file in a possible hidden way for the average user, then the system possibly goes back in the classic auto-start strategy, without any knowledge of that. qjackctl can already opt to not write any .jackdrc. ardour may vary. i would assume it to use the jack control api in a near future. the same would apply to qjackctl. then everybody will be happy again ;) i was asking for a default strategy, call it auto, which will try classic first, then d-bus, then whatever. the main question, at least in my mind, is all about *which* settings will be used to auto-start the server, isn't it? an explicit command line, as in classic, should *always* take precedence over the settings in any internal configuration database, which i think the d-bus honors instead and that latter behavior is being the root of all d-bus evil. scnrt ;) cheers -- My feeling is that is we choose the runtime auto-start strategy, then we should not mix anything concerting setting management. Each incarnation of server has it's own view of setting management and this has to stay completely separated from any other view. If the used chose classic auto-start strategy (that would stay the default yes) then he is supposed to know that he has to use classic control tools (Qjackctl..). If the user chose D-Bus auto-start strategy, then he knows he has to use D-Bus aware control tools only and so on... While this may work in the short term in terms of saving valuable resources for other more important tasks I think you already know that is in not acceptable in the medium to long term as it will just confuse the f out of the average user requiring them to know the difference between the competing standards. Tooltips might help here but there are plenty who don't know how to read a tooltip also. However if the goal is to have this problem completely fixed and transparent before the average user is expected to use the system then proceed as outlined above as it is reasonable from an end user pov to set limits as such in the short term. -- Patrick Shrkey Boost Hardware Ltd. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Paul Davis wrote: 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. The current state is that it starts the unintended version of jackd, and confuses almost everyone in the process. Or fails to start the server at all, because DBUS version is already running in background, confusing everyone else. In my opinion, plain refusal to start with incompatible version is less dangerous, because it gives the end users a necessary information (about different pieces of software being incompatible). The users may then decide if they prefer the proven-but-possibly-dead-end tool set (qjackctl and friends) or still-experimental-but-promising tool set (laditools etc). The current model is misleading. In some cases it doesn't tell when the system works differently to what user intended. In other cases, it doesn't explain the primary cause for the server failing to start. My reaction to this kind of software is to uninstall it as quickly as possible. 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. Well, the damage is already done, see Fons' email and probably dozens of people who had the same experience but never bothered to report it. I think people who spent some time with Linux audio have plenty of experience with incompatible parallel APIs - OSS vs ALSA, ALSA vs JACK, JACK MIDI vs ALSA sequencer, raw MIDI vs sequencer MIDI. That's Linux Audio SNAFU. At least when you have JACK MIDI vs ALSA seq MIDI problem, nothing is pretending to work, the apps just don't see each other's MIDI ports (+/- a2jmidid, but that's for advanced users). On the other hand, this two conflicting JACK executables that appear to be compatible but aren't, and they may be picked randomly in some instances is a whole new thing, and nobody is used to it yet ;) Krzysztof ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Krzysztof Foltman wrote: Mixing those two models on one system is more trouble than it's worth - there are no benefits whatsoever, and any extra code to convert settings from one version to another is only adding to bloat and resulting bugginess. I don't even know why is it possible to install both versions of jackd at the same time, while client library only supports starting one of them. Ideally, jackdbus shouldn't even allow jackd binary to exist in $PATH (and vice versa), to prevent the exact kind of situation that Fons is experiencing. This is an inherently non commercial way of looking at things. The commercial viewpoint is that we have to look after the existing customers and maintain a usable version that doesn't enforce too much extra effort on their part. However we have the opportunity to completely bypass that step so if the new phase can be made accessible with very little (as in no) learning curve for existing users then we should be able to move forward without any pain. Patrick Shirkey Boost Hardware Ltd Krzysztof ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Krzysztof Foltman wrote: Paul Davis wrote: 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. The current state is that it starts the unintended version of jackd, and confuses almost everyone in the process. Or fails to start the server at all, because DBUS version is already running in background, confusing everyone else. In my opinion, plain refusal to start with incompatible version is less dangerous, because it gives the end users a necessary information (about different pieces of software being incompatible). The users may then decide if they prefer the proven-but-possibly-dead-end tool set (qjackctl and friends) or still-experimental-but-promising tool set (laditools etc). The current model is misleading. In some cases it doesn't tell when the system works differently to what user intended. In other cases, it doesn't explain the primary cause for the server failing to start. My reaction to this kind of software is to uninstall it as quickly as possible. 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 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. Well, the damage is already done, see Fons' email and probably dozens of people who had the same experience but never bothered to report it. I think people who spent some time with Linux audio have plenty of experience with incompatible parallel APIs - OSS vs ALSA, ALSA vs JACK, JACK MIDI vs ALSA sequencer, raw MIDI vs sequencer MIDI. That's Linux Audio SNAFU. At least when you have JACK MIDI vs ALSA seq MIDI problem, nothing is pretending to work, the apps just don't see each other's MIDI ports (+/- a2jmidid, but that's for advanced users). On the other hand, this two conflicting JACK executables that appear to be compatible but aren't, and they may be picked randomly in some instances is a whole new thing, and nobody is used to it yet ;) Krzysztof ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, May 19, 2009 at 08:40:58PM +0700, Patrick Shirkey wrote: Krzysztof Foltman wrote: Ideally, jackdbus shouldn't even allow jackd binary to exist in $PATH (and vice versa), to prevent the exact kind of situation that Fons is experiencing. 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Fons Adriaensen wrote: Ideally, jackdbus shouldn't even allow jackd binary to exist in $PATH (and vice versa), to prevent the exact kind of situation that Fons is experiencing. 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. I'm not talking about forced removal of the previously installed program. More like refusal to install at all if you try to install it in parallel to existing JACK-legacy installation. And the D-Bus JACK and Classic JACK mixture variant on http://trac.jackaudio.org/wiki/JackDbusPackaging should be clearly marked as dangerously confusing (and not used by any distributions). It's like installing two different slightly incompatible versions of libc in such a way that they are picked randomly, and expecting the whole system to work properly. It's not supposed to work, and allowing such installations is asking for complaints like the one that started this thread. Or like starting (in parallel) two different HTTP servers trying to bind to the same address and port. Package managers have a way to specify a conflict between two packages if they are replacements of each other, and I don't see anyone describing that as malware. Krzysztof ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Patrick Shirkey wrote: 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. Useful doesn't conflict with dead end. Steam-powered trains were certainly useful in 19th century, yet I think they were sufficiently proven to be a dead end. Krzysztof ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tuesday 19 May 2009 15:03:28 Fons Adriaensen wrote: On Tue, May 19, 2009 at 02:06:05PM -0400, drew Roberts wrote: 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. Indirectly that amounts to limiting my choice for setting $PATH. 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.) The idea that a single app should have any impact on such things is IMHO near to unthinkable. More generally, this sort of thing is pure Big Brother, and I don't need one, no matter how good his intentions may be. The two other examples I mentioned were not chosen randomly. We now have file systems that are not in /etc/fstab being mounted from X init scripts, doesn't matter if you want them or not and even root can't remove them, and device permissions set by display managers. Both are examples of braindead ways to do things, both originate from the same source. Dbus ties jackd to the desktop and is just one more example of the same insane evolution. 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. Ciao, all the best, drew ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
Stéphane Letz wrote: It seems you really don't want to see that using this jack_client_open does a fork+exec call to launch jackd with the ./jackdrc file has been completely *hard coded* in libjack from day one! And is a really strong constraint for any possible new way of controlling the server. The discussion is now: do we keep this hard coded thing in libjack or do we try to relax it a bit ? I would vote for using some kind of environment variable control for the auto-start behavior... ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tuesday 19 May 2009 16:13:10 Krzysztof Foltman wrote: Fons Adriaensen wrote: Both are examples of braindead ways to do things, both originate from the same source. Dbus ties jackd to the desktop and is just one more example of the same insane evolution. 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. So, what is making him think it is true? (Fons, can you tell Krzysztof? Perhaps he is the one I saw make this claim before. I don't remember.) Krzysztof all the best, drew ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
drew Roberts wrote: 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.) Knowing that even experienced programmers like Fons and experienced packagers like the one responsible for the unnamed reputable distribution, couldn't make it work in absence of this kind of checks, I'd definitely say anti-foot-gun measures are a good thing. 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. If you know what you're doing (or if you at least think you know), there's always the source. Nobody is going to hide it in Palladium-protected RSA-encrypted double-obfuscated layer of code. Or... hey, that's a great idea! At least that makes it more likely that the people who try to change it *really* know what they're doing ;) Krzysztof ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, May 19, 2009 at 05:07:13PM -0400, drew Roberts wrote: 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? 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, 2009-05-19 at 21:03 +0200, Fons Adriaensen wrote: Both are examples of braindead ways to do things, both originate from the same source. Dbus ties jackd to the desktop and is just one more example of the same insane evolution. Indeed. I might be way off base, but what is wrong with the old school approach to changing daemons settings by getting it to re read a config file on SIGUSR1? Handle stdout by providing a couple of arguments that specify where to write the output (Think named pipes setup by whatever control interface cares). Dbus XML for what should be a minimal system daemon running with RT priority? WTF? I have some reasonably mission critical things going on with jackd, the last thing I need on those boxes (one of which does not even have an X server) is integration with the desktop. Regards, Dan. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Wed, 20 May 2009 07:32:51 am Dan Mills wrote: On Tue, 2009-05-19 at 21:03 +0200, Fons Adriaensen wrote: Both are examples of braindead ways to do things, both originate from the same source. Dbus ties jackd to the desktop and is just one more example of the same insane evolution. Indeed. I might be way off base, but what is wrong with the old school approach to changing daemons settings by getting it to re read a config file on SIGUSR1? Handle stdout by providing a couple of arguments that specify where to write the output (Think named pipes setup by whatever control interface cares). Dbus XML for what should be a minimal system daemon running with RT priority? WTF? 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.
