Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Fons Adriaensen f...@kokkinizita.net writes: On Mon, May 18, 2009 at 10:50:01PM +0100, Krzysztof Foltman wrote: I don't see the problem, let alone OMG INTERCEPTING C API CALLS!!11! or eating babies. Well, the current implementation *does* intercept C API calls in order to divert them to dbus, it's not just an addition to the standard jackd. I never mentioned babies being eaten. As long as interface is same at C API level everything is fine. dbus cant and does not intercept any C API calls. The implementation of the jack_client_open(), only when compiled in dbus model, only when wants to start jack server, starts the jack server by *CALLING* libdbus function. That C level libdbus API call is then implemented by using the dbus IPC mechanism (sockets) and then gets into jackdbus process that executes the call. Nobody is intercepting jack.h API C level calls. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpxGqZN2rJDr.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] more jack/qjackctl madness : some comments
On Tue, May 19, 2009 at 10:03:28AM +0300, Nedko Arnaudov wrote: Fons Adriaensen f...@kokkinizita.net writes: Well, the current implementation *does* intercept C API calls in order to divert them to dbus, it's not just an addition to the standard jackd. I never mentioned babies being eaten. As long as interface is same at C API level everything is fine. dbus cant and does not intercept any C API calls. The implementation of the jack_client_open(), only when compiled in dbus model, only when wants to start jack server, starts the jack server by *CALLING* libdbus function. That C level libdbus API call is then implemented by using the dbus IPC mechanism (sockets) and then gets into jackdbus process that executes the call. Nobody is intercepting jack.h API C level calls. Nedko, you continue to contradict yourself. What you write above confirms that the jack_client_open() call is intercepted and its action modified. 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] more jack/qjackctl madness : some comments
Fons Adriaensen f...@kokkinizita.net writes: On Tue, May 19, 2009 at 10:03:28AM +0300, Nedko Arnaudov wrote: Fons Adriaensen f...@kokkinizita.net writes: Well, the current implementation *does* intercept C API calls in order to divert them to dbus, it's not just an addition to the standard jackd. I never mentioned babies being eaten. As long as interface is same at C API level everything is fine. dbus cant and does not intercept any C API calls. The implementation of the jack_client_open(), only when compiled in dbus model, only when wants to start jack server, starts the jack server by *CALLING* libdbus function. That C level libdbus API call is then implemented by using the dbus IPC mechanism (sockets) and then gets into jackdbus process that executes the call. Nobody is intercepting jack.h API C level calls. Nedko, you continue to contradict yourself. What you write above confirms that the jack_client_open() call is intercepted and its action modified. It is not intercepted. It is implemented. No hooking is made. jack_client_open() action is not modified. It behaves as expected, as documented in the API. jack server is autostarted. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpXWcDRelfok.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] more jack/qjackctl madness : some comments
On Tue, May 19, 2009 at 11:23:07AM +0300, Nedko Arnaudov wrote: It is not intercepted. It is implemented. No hooking is made. jack_client_open() action is not modified. It behaves as expected, as documented in the API. jack server is autostarted. It's not just a different implementation. It has side effects that the original call does not have (starting a daemon), and these side effects will have consequences later. If this is not true then the new implementation is actually useless. I would have no objection if you added e.g. jack_client_open_via_dbus() leaving the original call as it is. If that new call has some real benefits then client authors will use it. What you do now is forcing it down everybody's throat. Yesterday evening I had a visitor, a very fine musician who knows nothing about computers let alone programming. Seeing the discussion on #jack he asked me what this was all about. So I told him this little fiction: Someone sets up a firm that provides a free service: they enhance your life by removing things from your home and disposing of them. One day I return home and find some things have been removed. I go the manager of the free service and tell him: - Listen, I don't want you to enter my home and remove things uninvited. - But then I can't do my job ! - So you are thieves ? - No, no, no, we just provide a free service that enhances your life. 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] more jack/qjackctl madness : some comments
Fons Adriaensen f...@kokkinizita.net writes: On Tue, May 19, 2009 at 11:23:07AM +0300, Nedko Arnaudov wrote: It is not intercepted. It is implemented. No hooking is made. jack_client_open() action is not modified. It behaves as expected, as documented in the API. jack server is autostarted. It's not just a different implementation. It has side effects that the original call does not have (starting a daemon), and these side effects will have consequences later. If this is not true then the new implementation is actually useless. I would have no objection if you added e.g. jack_client_open_via_dbus() leaving the original call as it is. No and no again. jack clients dont care how jack server is started. they want it started so they can use it. period. they dont care about jack internal infrastructure. The whole point of abstrctions is to allow changing the implementation. As it is with jack1 and jack2. Why you dont want jack_client_open_jackdmp() ? Someone sets up a firm that provides a free service: they enhance your life by removing things from your home and disposing of them. One day I return home and find some things have been removed. I go the manager of the free service and tell him: - Listen, I don't want you to enter my home and remove things uninvited. - But then I can't do my job ! - So you are thieves ? - No, no, no, we just provide a free service that enhances your life. This is a BS, nobody is forcing you to use that. You have the free will. You can choose what to use. There is an option that you dont like. And nobody is telling you that it will enhance *your* life. It may enahnce my life. Or someone else's. But not yours. This is why it is optional. Even installing jack2 instead of jack1 is optional. You are free to use VAX if you like it. Nobody is forcing you to use something else. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpHa1XVhokkf.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, 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] more jack/qjackctl madness : some comments
Nedko Arnaudov wrote: Stéphane Letz l...@grame.fr writes: First we have to get a consensus on this runtime choice of auto-start strategy, then we'll have to find the best way to implement it. I was against mixed jack1/jack2 and i'm against the runtime choice now. IMHO it complicates things for user instead of simplifying it. It also complicates codebase and I think we can spend our efforts with something else instead. Still, if someone has the motivation to do runtime choice of auto-strategy - fine, i can live with it. The only important thing is that with jackdbus the default strategy must be autostarting through dbus. If it is not, by default jackdbus control apps will not work with jackdbus. Such setup will be pretty useless, eh? You will be isolating a whole lot of existing users by forcing a new paradigm on them before they are ready. Just look at Facebook for a good example of how this doesn't work. I think jack devs have to put the effort into making the transition to a more flexible system as subtle as possible rather than smacking people round the head with it. ___ Jack-Devel mailing list jack-de...@lists.jackaudio.org http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.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] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 12:10:45PM -0400, Paul Davis wrote: On Mon, May 18, 2009 at 11:57 AM, Rui Nuno Capela rn...@rncbc.org wrote: from where i stand, qjackctl does not need jackdbus support whatsoever. it's kind of the other way around, if i may say. and the way around is not about qjackctl per se, but to plain old good command-line jackd. i'd like to clarify (again) based on ongoing conversations in #jack. the issue that qjackctl could consider is not jackdbus, or dbus in general. its the JACK control API that was discussed at LAC 2008. right now, qjackctl simply claims to know how to start the JACK server, offers a dialog to let the user pick settings, and then constructs a set of command line arguments for jackd. this will continue to work forever, but it is less flexible than we would like (consider what happens every time JACK gets a new option added (or taken away). the control API allows a control application to query the jack server (actually, its really querying the library that contains the implementation of the jack server that the control app is linked with), and discover what the available parameters are etc. etc. the dbus stuff is really mostly orthogonal to this (i stress the mostly) - its just another example of a control app/system. there's no reason why qjackctl would or should want to interact with it. however, the one area where these things overlap is auto-start. this is because what it means to auto-start a JACK server differs in the following two scenarios: * vanilla JACK install - there is no jack control system in place or in use * with jackdbus - there is a daemon in place listening for requests to start/stop/reconfigure the server in the first scenario, the ~/.jackdrc file (if it exists) takes care of auto-start. but if jackdbus is in use, then auto-start means something really quite different. so please tell me why the dbus implementation CANT just read .jackdrc ? i am really pissed on all you guys trampling on legacy stuff. WHY cant jackdbus just use the .jackdrc if it does not find its own .xml config ? or check, whether .jackdrc is newer than the xml ? you always point at us saying we dont like dbus. its not about dbus. its about dbus people ignoring legacy. stop breaking legacy ! -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language ___ 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] more jack/qjackctl madness : some comments
torb...@gmx.de writes: so please tell me why the dbus implementation CANT just read .jackdrc ? i am really pissed on all you guys trampling on legacy stuff. It can. Nobody has implemented it. WHY cant jackdbus just use the .jackdrc if it does not find its own .xml config ? or check, whether .jackdrc is newer than the xml ? Because it is useless. It is useless because you will still have two configuration files. You are not solving the problem. qjackctl and ardour will save to jackdrc, jackdbus (or multiconfig object) will save to other file. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpAxqfpQQbIV.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] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 07:15:23PM +0300, Nedko Arnaudov wrote: Rui Nuno Capela rn...@rncbc.org writes: So you complain about qjackctl missing support for jackdbus? Having that will be nice :) from where i stand, qjackctl does not need jackdbus support whatsoever. it's kind of the other way around, if i may say. and the way around is not about qjackctl per se, but to plain old good command-line jackd. In jackdbus system qjackctl is unusable for starting and configuring the jack server (there is no jackd executable). However qjackctl can still be used to monitor xruns and DSP load and as a patchbay application. fwiw, qjackctl just runs the jackd server as documented and interfaces to libjack through its plain client api. it has been doing this for years and rightly so, imo. Yup I know that. And this is why it works as patchbay and monitor app when used with jackdbus. however, by having jackdbus in the picture and when everybody would think it would be the holy grail, it is breaking all that instead just because it wants to rule the game on its own. it's doing it with complete disregard to what long time qjackctl/jackd users have been thought. that's disgraceful to say the least. It is not breaking it is fixing issues. Or I'm wrong that qjackctl can't show messages generated by jackd when jackd is autolaunched by regular jack client application? Last time I checked those messages go to application's stdout (that is inherited from the parent process - the one of the normal jack client application). The issue that started this holy war is that dbus enabled package that contains also jackd got into the hands of Fons and ate his babies. The problem is already fixed in svn. qjackctl will not work when dbus is enabled unless both jackdbus and jackd are compiled and installed and after the packager ignores the warning text at configure time. qjackctl will not work because there will be not jackd executable installed. and why is this so complicated ? why not think a bit about legacy ? this i dont care for legacy attitude is the problem. and it does not help to say we think dbus eats babies. this is just a cheap excuse. we are pissed because you dont care. and i am starting to care less and less for all this shit too. i strongly believe that all this trouble is a matter or something that just has been overlooked on the jackdbus development, that is, a misinterpretation, a bug that can be squashed right away once it's perfectly identified. Unless you point to what is wrong nobody who knows how jackdbus system operates will understand what you mean. however, if all that is due on a jackdbus design decision instead, then i am sorry, i'll digress. a completely new qjackctl has to be written from the ground up. just don't ask me to do it, at least anytime soon :) I asked you to add support for jackdbus (there are qt dbus wrappers) more than a year ago. It was in December 2007 IIRC. Not that I hoped a lot even back then. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language ___ 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] more jack/qjackctl madness : some comments
torb...@gmx.de writes: On Mon, May 18, 2009 at 07:15:23PM +0300, Nedko Arnaudov wrote: however, by having jackdbus in the picture and when everybody would think it would be the holy grail, it is breaking all that instead just because it wants to rule the game on its own. it's doing it with complete disregard to what long time qjackctl/jackd users have been thought. that's disgraceful to say the least. It is not breaking it is fixing issues. Or I'm wrong that qjackctl can't show messages generated by jackd when jackd is autolaunched by regular jack client application? Last time I checked those messages go to application's stdout (that is inherited from the parent process - the one of the normal jack client application). The issue that started this holy war is that dbus enabled package that contains also jackd got into the hands of Fons and ate his babies. The problem is already fixed in svn. qjackctl will not work when dbus is enabled unless both jackdbus and jackd are compiled and installed and after the packager ignores the warning text at configure time. qjackctl will not work because there will be not jackd executable installed. and why is this so complicated ? why not think a bit about legacy ? this i dont care for legacy attitude is the problem. and it does not help to say we think dbus eats babies. this is just a cheap excuse. we are pissed because you dont care. and i am starting to care less and less for all this shit too. I care about legacy. I've implemented a2jmidid to support legacy ALSA seq stuff. I've tried to not obsolete legacy things. But when some part is not designed to cooperate and is not extendable you have to give up. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpgD3AtSXXfC.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...
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] [PATCH] kfusd against 2.6.29 kernel
I completely forgot to post the kfusd patch. I understand cuse will supersede
all this but some ppl out there may want to use kfusd in the mean time against
kernel 2.6.29.x
I warn you, there may be cleaner way to do this but it works. Some changes
might be due to some spacing or tabbing. Sorry about that. Note that I have no
clue when the kernel API changed after 2.6.24. So I you try it against say
2.6.27 or 2.6.28, it may not work at all. Here it is:
Here it is:
--- PATCH start --
diff -Naur fusd-kor/include/kfusd.h fusd-kor-new/include/kfusd.h
--- fusd-kor/include/kfusd.h2007-06-26 02:01:36.0 +0200
+++ fusd-kor-new/include/kfusd.h2009-05-19 07:40:27.549694054 +0200
@@ -44,6 +44,7 @@
#define __KFUSD_H__
#include fusd_msg.h
+#include linux/version.h
/* magic numbers for structure checking; unique w.r.t
* /usr/src/linux/Documentation/magic-number.txt */
@@ -125,7 +126,11 @@
char *dev_name;
struct CLASS *clazz;
int owns_class;
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,29)
struct class_device *class_device;
+#else
+ struct device *class_device;
+#endif
void *private_data; /* User's private data */
struct cdev* handle;
diff -Naur fusd-kor/kfusd/kfusd.c fusd-kor-new/kfusd/kfusd.c
--- fusd-kor/kfusd/kfusd.c 2008-01-31 22:38:53.0 +0100
+++ fusd-kor-new/kfusd/kfusd.c 2009-05-19 07:40:36.412703934 +0200
@@ -85,7 +85,7 @@
#define STATIC
/* Define this if you want to emit debug messages (adds ~8K) */
-#define CONFIG_FUSD_DEBUG
+/* #define CONFIG_FUSD_DEBUG */
/* Default debug level for FUSD messages. Has no effect unless
* CONFIG_FUSD_DEBUG is defined. */
@@ -126,8 +126,17 @@
#else
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,29)
+
#define CLASS_DEVICE_CREATE(a, b, c, d, e) class_device_create(a, b, c, d, e)
+#else
+
+#define CLASS_DEVICE_CREATE(a, b, c, d, e) device_create(a, b, c, d, e)
+#define class_device_destroy(a, b) device_destroy(a, b)
+
+#endif
+
#endif
#endif
@@ -150,8 +159,13 @@
static struct CLASS *fusd_class;
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,29)
static struct class_device *fusd_control_class_device;
static struct class_device *fusd_status_class_device;
+#else
+static struct device *fusd_control_class_device;
+static struct device *fusd_status_class_device;
+#endif
extern struct CLASS *sound_class;
@@ -725,8 +739,10 @@
/* fill the rest of the structure */
fusd_msg-parm.fops_msg.pid = current-pid;
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,29)
fusd_msg-parm.fops_msg.uid = current-uid;
fusd_msg-parm.fops_msg.gid = current-gid;
+#endif
fusd_msg-parm.fops_msg.flags = fusd_file-file-f_flags;
fusd_msg-parm.fops_msg.offset = fusd_file-file-f_pos;
fusd_msg-parm.fops_msg.device_info = fusd_dev-private_data;
@@ -1533,6 +1549,7 @@
}
static void fusd_client_mm_open(struct vm_area_struct * vma);
static void fusd_client_mm_close(struct vm_area_struct * vma);
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,29)
static struct page* fusd_client_nopage(struct vm_area_struct* vma, unsigned
long address, int* type);
static struct vm_operations_struct fusd_remap_vm_ops =
{
@@ -1540,6 +1557,16 @@
close: fusd_client_mm_close,
nopage: fusd_client_nopage,
};
+#else
+static int fusd_client_fault(struct vm_area_struct* vma, struct vm_fault
*vmf, int* type);
+static struct vm_operations_struct fusd_remap_vm_ops =
+{
+ .fault = fusd_client_fault,
+ .open = fusd_client_mm_open,
+ .close = fusd_client_mm_close,
+};
+#endif
+
struct fusd_mmap_instance
{
@@ -1631,13 +1658,14 @@
return -EPIPE;
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,29)
static struct page* fusd_client_nopage(struct vm_area_struct* vma, unsigned
long address,
int* type)
{
struct fusd_mmap_instance* mmap_instance = (struct fusd_mmap_instance*)
vma-vm_private_data;
unsigned long offset;
- struct page *page = NOPAGE_SIGBUS;
int result;
+ struct page *page = NOPAGE_SIGBUS;
offset = (address - vma-vm_start) + (vma-vm_pgoff PAGE_SHIFT);
// todo: worry about size
if(offset mmap_instance-size)
@@ -1662,9 +1690,46 @@
}
out:
return page;
+}
+#else
+static int fusd_client_fault(struct vm_area_struct* vma, struct vm_fault *vmf,
+ int* type)
+{
+ struct fusd_mmap_instance* mmap_instance = (struct fusd_mmap_instance*)
vma-vm_private_data;
+ unsigned long offset;
+ int result;
+ struct page *page = NULL;
+ offset = ((unsigned long)vmf-virtual_address - vma-vm_start) +
(vma-vm_pgoff PAGE_SHIFT);
+ // todo: worry about size
+ if(offset mmap_instance-size)
+ goto out;
+
+ down_read(mmap_instance-fusd_dev-task-mm-mmap_sem);
+ result = get_user_pages(mmap_instance-fusd_dev-task,
mmap_instance-fusd_dev-task-mm, mmap_instance-addr + offset, 1, 1, 0,
page, NULL);
+ up_read(mmap_instance-fusd_dev-task-mm-mmap_sem);
+
+
+ if(PageAnon(page))
+ {
+ RDEBUG(2, Cannot mmap anonymous pages. Be sure to allocate your shared
buffer with MAP_SHARED | MAP_ANONYMOUS);
+ return
[LAD] A picture...of the global mess
He all, A picture to try summary what I understand about we would like : - a new shared library called libjackontrol.so : is does implement the so called control API and a IPC mechanism to use it. - jackcontrol is an *always running deamon that defined an entry IPC point. jackcontrol get requests from control applications. jackcontrol can start a seprated server called jackserver (using a fork+exec) way. jackcontrol is a *unique* place where setting are handled. - jackd is a recoded control application that parse it's command line, and use the control IPC to speak to jackcontrol (then just quits). jackcontrol then start the jackserver whith the appropriate paramaters. - jackddbus is a D-Bus aware control application; It receive DBus requests and translate them to control IPC to speak to jackcontrol. jackcontrol then start the jackserver whith the appropriate paramaters - libjack.so speaks also to jackcontrol using the control IPC: an client that auto-start actually use this mecanism Does it helps? Stephane jackcontrol.pdf Description: Adobe PDF document ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [PATCH] oss2jack 0.25 for jack2
Following the kfusd patch, here is a small patch to make oss2jack work fine
against jack2.
It works against jack1 already because jack1's version of
jack_set_samplerate_callback() actually executes the callback function, while
jack2 does not do it right away. So I followed Stephane Letz's advice and call
jack_get_sample_rate() in oss2jack in jack_init() instead.
Please be aware that you may get a reject by applying due to screwed spacing. I
had some funny issues with this lately (and I use emacs for source code ...
weird).
-- PATCH start --
--- oss2jack-0.25.orig/src/oss2jack/oss2jack.c 2009-05-18 19:57:17.757704457
+0200
+++ oss2jack-0.25/src/oss2jack/oss2jack.c 2009-05-18 20:05:04.397724051
+0200
@@ -633,7 +633,7 @@
jack_set_error_function(jack_error);
- info-client = jack_client_new(oss-dsp);
+ info-client = jack_client_open(oss-dsp, JackNullOption, NULL);
if(info-client == NULL)
{
@@ -652,6 +652,9 @@
jack_set_sample_rate_callback(info-client, jack_srate, info);
jack_set_buffer_size_callback(info-client, jack_buffer_size, info);
+ /* initialize current sample rate for jack2 at startup */
+ (void)jack_srate(jack_get_sample_rate(info-client), info);
+
jack_on_shutdown(info-client, jack_shutdown, info);
info-last_frame_size = 64;
--- PATCH end --
Cheers!
J.
--- On Fri, 5/15/09, Lennart Poettering mz...@0pointer.de
wrote:
From: Lennart Poettering mz...@0pointer.de
Subject: Re: [LAD] [PATCH] kfusd against 2.6.29
kernel
To: linux-audio-dev@lists.linuxaudio.org
Date: Friday, May 15, 2009, 8:29 AM
On Fri, 15.05.09 05:21, James Warden
(warj...@yahoo.com)
wrote:
Hi,
I created a patch for kfusd (fusd-kor kernel
module)
because I
needed oss2jack to work again against kernel
2.6.29.x
I need to clean up the patch as it bulldozes the
old
kernel API. If
anyone is interested, I can post it here when I
clean
it up (some
time tonight or tomorrow). I already contacted
the
author of fusd
but I've got no reply so far.
Note that I am no kernel guru, I got inspired by
the
update to
module source drm_mm.c and tested oss2jack in a
2.6.29.2-rt10
environment against jack1_svn (latest). I need to
fix
something to
make it work with jack2 (some problem linked to
libsamplerate -
which is used in oss2jack - specifically in
src_process, the
src_ratio field of the passed data is out of
range).
Please note that cuse (which does mostly the same as
fusd)
is on its
way into the kernel:
http://lwn.net/Articles/296388/
Lennart
--
Lennart Poettering
Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/
GnuPG 0x1A015CC4
___
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] A picture...of the global mess
Stéphane Letz wrote: - jackd is a recoded control application that parse it's command line, and use the control IPC to speak to jackcontrol (then just quits). jackcontrol then start the jackserver whith the appropriate paramaters. Does it helps? And how does jackcontrol communicate with jackserver? ... over DBUS? *ducks* Krzysztof ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] A picture...of the global mess
Le 19 mai 09 à 16:32, Krzysztof Foltman a écrit : Stéphane Letz wrote: - jackd is a recoded control application that parse it's command line, and use the control IPC to speak to jackcontrol (then just quits). jackcontrol then start the jackserver whith the appropriate paramaters. Does it helps? And how does jackcontrol communicate with jackserver? ... over DBUS? *ducks* Krzysztof Well over an IPC (not Dbus) Note that we may remove the jackcontrol + jackserver separation by starting the server inside jackcontrol process. But then if the server crash, jackcontrlol is dead. This may be solved by an jackcontrol deamon automatic relaunch feature... 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] A picture...of the global mess
Stéphane Letz l...@grame.fr writes: He all, A picture to try summary what I understand about we would like : - a new shared library called libjackontrol.so : is does implement the so called control API and a IPC mechanism to use it. - jackcontrol is an *always running deamon that defined an entry IPC point. jackcontrol get requests from control applications. jackcontrol can start a seprated server called jackserver (using a fork+exec) way. jackcontrol is a *unique* place where setting are handled. - jackd is a recoded control application that parse it's command line, and use the control IPC to speak to jackcontrol (then just quits). jackcontrol then start the jackserver whith the appropriate paramaters. - jackddbus is a D-Bus aware control application; It receive DBus requests and translate them to control IPC to speak to jackcontrol. jackcontrol then start the jackserver whith the appropriate paramaters - libjack.so speaks also to jackcontrol using the control IPC: an client that auto-start actually use this mecanism Does it helps? Stephane As alternative diagram we already have the old one: http://www.marcochapeau.org/documentation/jackenv Instead of three IPC layers between pyjack(laditools now), you have only one. I like the architecture described in this diagram. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpH6nY2bATGq.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] more jack/qjackctl madness : some comments
On Tue, 2009-05-19 at 10:37 +0200, Fons Adriaensen wrote: Someone sets up a firm that provides a free service: they enhance your life by removing things from your home and disposing of them. One day I return home and find some things have been removed. I go the manager of the free service and tell him: - Listen, I don't want you to enter my home and remove things uninvited. - But then I can't do my job ! - So you are thieves ? - No, no, no, we just provide a free service that enhances your life. I have to say, I think this is really out of line, Fons. Implying free software developers are theives because they've changed something and you don't like it is quite extraordinary. I think a better analogy would be like so: Someone sets up a firm that provides and maintains free furniture, appliances, plumbing and electricity for anybody's home. One day, you come home and find half of your radiators don't work because someone has started upgrading the plumbing and hasn't finished yet. You go to the manager of the free service and tell him: - Listen, I don't want you to stop the radiators in my house from working. - That's fine, you're entirely free to install your own plumbing, or fix the plumbing we've installed for you. - I don't want to, you should do it for me and do it right dammit! signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Bob Ham wrote: On Tue, 2009-05-19 at 10:37 +0200, Fons Adriaensen wrote: Someone sets up a firm that provides a free service: they enhance your life by removing things from your home and disposing of them. One day I return home and find some things have been removed. I go the manager of the free service and tell him: - Listen, I don't want you to enter my home and remove things uninvited. - But then I can't do my job ! - So you are thieves ? - No, no, no, we just provide a free service that enhances your life. I have to say, I think this is really out of line, Fons. Implying free software developers are theives because they've changed something and you don't like it is quite extraordinary. I think a better analogy would be like so: Someone sets up a firm that provides and maintains free furniture, appliances, plumbing and electricity for anybody's home. One day, you come home and find half of your radiators don't work because someone has started upgrading the plumbing and hasn't finished yet. You go to the manager of the free service and tell him: - Listen, I don't want you to stop the radiators in my house from working. - That's fine, you're entirely free to install your own plumbing, or fix the plumbing we've installed for you. - I don't want to, you should do it for me and do it right dammit! Both metaphors are error coloured. If a community will do something together as an free alternative, than nobody can command to get something that fit to his needs so much tuned, as if he has paid for something. But it's stupid for a free alternative, if working stuff can become absolutely incompatible to older versions or cause major troubles for many used functions. I'm speaking in general, not especially for the different threads about the rc files and dbus. If people call attention to things that can cause trouble in the future or that cause trouble right now, than it's not clever to answer, that he should do it by himself, pay for something etc.. Ideas, different opinions or getting aware of something other people haven't noticed and refer to it, isn't an attack against the people that are working for free, especially not if it comes from people who do their self work without being paid. I'm using Linux since years (not rt-audio ;)) and the architecture of Linux has one big disadvantage. You might have a Linux that is fine, the times are changing and in addition you need an absolutely new application, but you don't need to update any of the applications you're using since years. You can't install the new application, because dependencies needs to be updated and that causes that also your perfect working applications needs to be updated. You do an update. The new applications is fine. The old, updated applications ... ... are fine ... but not all, some are broken ... ... others are fine for new work, but you can't load old projects any more ... ... other applications can't be installed any more ... etc. ... Sometimes a coder or a packer (packages builder?!) don't work as intensive with 'hi' application as the community does, so he can fail to see some issues. Resume: If something was fine, it's not an advantage if it gets broken. If something needs to be broken, because of the development, it shouldn't be released. We won't practise on stage, we practise in the rehearsal room. Sorry, I need to write this, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Bob Ham r...@bash.sh writes: On Tue, 2009-05-19 at 10:37 +0200, Fons Adriaensen wrote: Someone sets up a firm that provides a free service: they enhance your life by removing things from your home and disposing of them. One day I return home and find some things have been removed. I go the manager of the free service and tell him: - Listen, I don't want you to enter my home and remove things uninvited. - But then I can't do my job ! - So you are thieves ? - No, no, no, we just provide a free service that enhances your life. I have to say, I think this is really out of line, Fons. Implying free software developers are theives because they've changed something and you don't like it is quite extraordinary. I think a better analogy would be like so: Someone sets up a firm that provides and maintains free furniture, appliances, plumbing and electricity for anybody's home. One day, you come home and find half of your radiators don't work because someone has started upgrading the plumbing and hasn't finished yet. You go to the manager of the free service and tell him: - Listen, I don't want you to stop the radiators in my house from working. - That's fine, you're entirely free to install your own plumbing, or fix the plumbing we've installed for you. - I don't want to, you should do it for me and do it right dammit! Even better: Someone sets up a firm Foo that produces furniture, appliances, plumbing, etc. Someone sets up a firm Bar that provides and maintains free furniture, appliances, plumbing and electricity for anybody's home by using the prducts of firm Foo. One day, you come home and find half of your radiators don't work because someone has started upgrading the plumbing and hasn't finished yet. You go to the manager of the firm Foo and tell him: - Listen, I don't want you to stop the radiators in my house from working. - I don't. I have no control with out. Why you dont ask the manager of firm Bar? - But you produce it! - Yes, we produce toxic waste too. There are bacteria that eat it. I'm affraid the manager of firm Bar got impression that you eat toxic waste too. I'm sorry about situation. We will improve instructions about our toxic waste product but still, you have to request Bar to meet your requirements. Or stop using Bar and use Baz instead. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgp4kbu8rH33o.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] more jack/qjackctl madness : some comments
Ralf Mardorf ralf.mard...@alice-dsl.net writes: If something needs to be broken, because of the development, it shouldn't be released. We won't practise on stage, we practise in the rehearsal room. In open source world, with public source control repos each commit is a publish. So you got a camera in your rehearshal room. And the live stream is watched by whom likes your jaming. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpiCZR4wckIj.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] more jack/qjackctl madness : some comments
Ralf Mardorf wrote: Sometimes a coder or a packer (packages builder?!) don't work as intensive with 'hi' application as the community does, so he can fail to see some issues. 'hi' is missing an 's', it should be 'his' ... I guess my English is too broken, so there seems to be the need to correct this, otherwise nobody can understand what I was writing about. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, May 19, 2009 at 04:49:58PM +0100, Bob Ham wrote: I have to say, I think this is really out of line, Fons. Implying free software developers are theives because they've changed something and you don't like it is quite extraordinary. I did not imply such a thing. You are completely missing the point. -- 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] more jack/qjackctl madness : some comments
Nedko Arnaudov wrote: Ralf Mardorf ralf.mard...@alice-dsl.net writes: If something needs to be broken, because of the development, it shouldn't be released. We won't practise on stage, we practise in the rehearsal room. In open source world, with public source control repos each commit is a publish. So you got a camera in your rehearshal room. And the live stream is watched by whom likes your jaming. Watching the jam for free, you can learn a lot, but you don't get the music you might wish to get, you need to go to the concert for free or you need to download the recording for free AND the band can produce different new versions, but it should be possible to hear the first version of the concert in the future ... metaphors won't work ;). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Ralf Mardorf ralf.mard...@alice-dsl.net writes: Nedko Arnaudov wrote: Ralf Mardorf ralf.mard...@alice-dsl.net writes: If something needs to be broken, because of the development, it shouldn't be released. We won't practise on stage, we practise in the rehearsal room. In open source world, with public source control repos each commit is a publish. So you got a camera in your rehearshal room. And the live stream is watched by whom likes your jaming. Watching the jam for free, you can learn a lot, but you don't get the music you might wish to get, you need to go to the concert for free or you need to download the recording for free AND the band can produce different new versions, but it should be possible to hear the first version of the concert in the future ... metaphors won't work ;). The live stream is captured (public repo is persistent) and you can hear the first version in the future. ;) -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpmYsb2V8koB.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] more jack/qjackctl madness : some comments
On Tue, 2009-05-19 at 18:27 +0200, Fons Adriaensen wrote: On Tue, May 19, 2009 at 04:49:58PM +0100, Bob Ham wrote: I have to say, I think this is really out of line, Fons. Implying free software developers are theives because they've changed something and you don't like it is quite extraordinary. I did not imply such a thing. You are completely missing the point. Such is the danger of analogies. What was the point? -- Bob Ham r...@bash.sh signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Henry Gomersall wrote: On Tue, 2009-05-19 at 18:26 +0200, Ralf Mardorf wrote: I'm using Linux since years (not rt-audio ;)) and the architecture of Linux has one big disadvantage. You might have a Linux that is fine, the times are changing and in addition you need an absolutely new application, but you don't need to update any of the applications you're using since years. You can't install the new application, because dependencies needs to be updated and that causes that also your perfect working applications needs to be updated. I don't see how this is different to any system (Windows, Mac, Game Boy). The main difference being that you are actually free, yourself, to modify the code and keep it working. That is the point about being able to modify the code yourself. Henry The latest version of the Atari Cubase still can run sessions of the first version, sometimes you can't do this with Rosegarden between two versions (okay, I nearly does NO RT-AUDIO with Linux ;)). But the point isn't what is possible or impossible for other OS's. For Windows and Mac you can get the same open source applications, but not everybody want to work with the source code and set up the application by this way, most people needs a working tool. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Nedko Arnaudov wrote: Ralf Mardorf ralf.mard...@alice-dsl.net writes: Nedko Arnaudov wrote: Ralf Mardorf ralf.mard...@alice-dsl.net writes: If something needs to be broken, because of the development, it shouldn't be released. We won't practise on stage, we practise in the rehearsal room. In open source world, with public source control repos each commit is a publish. So you got a camera in your rehearshal room. And the live stream is watched by whom likes your jaming. Watching the jam for free, you can learn a lot, but you don't get the music you might wish to get, you need to go to the concert for free or you need to download the recording for free AND the band can produce different new versions, but it should be possible to hear the first version of the concert in the future ... metaphors won't work ;). The live stream is captured (public repo is persistent) and you can hear the first version in the future. ;) Metaphors don't work :D. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
Ralf Mardorf ralf.mard...@alice-dsl.net writes: The latest version of the Atari Cubase still can run sessions of the first version, sometimes you can't do this with Rosegarden between two versions (okay, I nearly does NO RT-AUDIO with Linux ;)). But the point isn't what is possible or impossible for other OS's. For Windows and Mac you can get the same open source applications, but not everybody want to work with the source code and set up the application by this way, most people needs a working tool. So you blame Steinberg for not releasing new versions of Ableton that will support Linux? ;) Or you blame gnome folks about new KDE being crap? :) -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpEsvqPG7UQT.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] more jack/qjackctl madness : some comments
Bob Ham wrote: On Tue, 2009-05-19 at 18:27 +0200, Fons Adriaensen wrote: On Tue, May 19, 2009 at 04:49:58PM +0100, Bob Ham wrote: I have to say, I think this is really out of line, Fons. Implying free software developers are theives because they've changed something and you don't like it is quite extraordinary. I did not imply such a thing. You are completely missing the point. Such is the danger of analogies. What was the point? Running gag: Metaphors don't work :D. I wish you all get your views reconciled. Tonight I'll try to make music with Linux again (by using jack). Good luck to you, good luck to myself, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, 2009-05-19 at 21:08 +0200, Fons Adriaensen wrote: On Tue, May 19, 2009 at 05:44:36PM +0100, Bob Ham wrote: Such is the danger of analogies. What was the point? Scroll back 100 messages, read everything and maybe you will grok it :-) I was reading through the thread when I encountered your fiction. It's the previous messages that brought me to the conclusion I came to about the point of the fiction. I was evidently wrong and I don't understand what the point actually was. -- Bob Ham r...@bash.sh signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] A picture...of the global mess
On Tue, May 19, 2009 at 04:49:07PM +0200, Stéphane Letz wrote: Note that we may remove the jackcontrol + jackserver separation by starting the server inside jackcontrol process. But then if the server crash, jackcontrlol is dead. This may be solved by an jackcontrol deamon automatic relaunch feature... Having a permanent jackd - a real daemon started as a service by the runlevel scripts - is the solution I'd prefer. You talk to it via libjack using the mechanisms already present in jack - sockets and shared memory. It is this jackd that will start a server, either requested explicitly by a control client, or as the result of a jack client using jack_client_open() to a nonexistant server. The latter is detected by jackd via the normal libjack paths. Servers should probably be separate processes (so they can be owned by a user). For those that want it this jackd can have a dbus control client, which could also be a daemon but this time started probably from the login scripts. What is gained is that there is ***no dbus inside jack*** It is this idea of using dbus for internal communication that I find utterly revolting. It creates a dependency on dbus (which is unnecessary) and on a session login (which is limiting its use), and it opens the gates for all sorts of sick desktop-zealot inspired persistence and stability risks. It's also just bad design, comparable to using a $3000 precision programmable voltage source in a circuit where a 10 cent zener diode would do. Or replacing a fixed cable by a switch matrix. Or talking to your wife via a lawyer. 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] more jack/qjackctl madness : some comments
On Tue, May 19, 2009 at 08:28:21PM +0100, Bob Ham wrote: Scroll back 100 messages, read everything and maybe you will grok it :-) I was reading through the thread when I encountered your fiction. It's the previous messages that brought me to the conclusion I came to about the point of the fiction. I was evidently wrong and I don't understand what the point actually was. Denial. The parrot is not dead. It's just a little bit tired. -- 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] more jack/qjackctl madness : some comments
On Tue, 2009-05-19 at 21:41 +0200, Fons Adriaensen wrote: On Tue, May 19, 2009 at 08:28:21PM +0100, Bob Ham wrote: Scroll back 100 messages, read everything and maybe you will grok it :-) I was reading through the thread when I encountered your fiction. It's the previous messages that brought me to the conclusion I came to about the point of the fiction. I was evidently wrong and I don't understand what the point actually was. Denial. The parrot is not dead. It's just a little bit tired. Heh, yeah I get that analogy :-) I can see where you were going with the fiction now, too. signature.asc Description: This is a digitally signed message part ___ 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.
