Re: [LAD] [Jack-Devel] more jack/qjackctl madness
> To whom it may concern: (again) > > Jackdmp 1.9.2, Qjackctl 0.3.4 > > I do the following: > > - Log in. > - Start a jack app. > - The app starts jackd, but using the wrong card, > and things don't work as expected. > > Questions: > > 1. Which parameters are used for such an autostart ? > Certainly not the ones in ~/.jackdrc, these would > have been correct. > 2. Qjackctl also ignores ~/.jackdrc, so what is the > purpose of this file ? > > - I terminate the app. Check with ps, there is no > more jackd running. > - I start qjackctl. It immediately shows a running > jackd, but his has restarted the previous wrong one. > - Click Stop, Start in qjackctl. Get the same wrong > jackd again. > - Verify qjackctl's Setup window. This shows the > settings for the right jackd, while it is running > another one. > > This is *madness* > > One more: you can't terminate qjackctl without > terminating jackd as well. Why not ? Killing > qjackctl does the right thing. > > A request to the jackdmp and qjackctl devs: > >PLEASE REMOVE THAT DBUS MADNESS > > Ciao, > Fons, I really appreciate your feedback..., but AFAICS Qjackctl is *absolutely* not using the DBUS layer! With jackdmp/jack2 compiled with default settings (that is *not* using the --dbus at configure step), then it should absolutely behave as jack1 was behaving. And I guess Rui can better answer the points concerning "~/.jackdrc," and son on. Stéphane ___ 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
On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen wrote: > A request to the jackdmp and qjackctl devs: > >PLEASE REMOVE THAT DBUS MADNESS Hi Fons, As long as there's a compile time switch, I don't see how dbus could ever be a problem for those who don't want to use it... and for those who do, I can tell you it works pretty well. Cheers, 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] more jack/qjackctl madness
On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane Letz wrote: > I really appreciate your feedback..., but AFAICS Qjackctl is *absolutely* > not using the DBUS layer! Then please tell what this is: (ps -ef output) fons 2444 1 0 10:43 ?00:00:00 /usr/bin/jackdbus auto Killing this makes qjackctl behave normally again, and allows me to start the server configured in it Setup window instead of getting a different one. > And I guess Rui can better answer the points concerning "~/.jackdrc," and > son on. Qjackctl is not involved in autostarting jackd, so I repeat the first question: Which parameters are used for such an autostart ? Certainly not the ones in ~/.jackdrc, these would have been correct. Given the usual convention of "APPNAME" using "~/APPNAMErc" for default settings, why does jackd not do this ? I know the file is created by qjackctl, but qjackctl completely ignores the settings there, so the file is cleary not meant for its own use. 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
Le 17 mai 09 à 10:57, Fons Adriaensen a écrit : > On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane Letz wrote: > >> I really appreciate your feedback..., but AFAICS Qjackctl is >> *absolutely* >> not using the DBUS layer! > > Then please tell what this is: (ps -ef output) > > fons 2444 1 0 10:43 ?00:00:00 /usr/bin/jackdbus auto > > Killing this makes qjackctl behave normally again, > and allows me to start the server configured in it > Setup window instead of getting a different one. > >> If you compile jack2 *without* dbus support (that is the *default* compilation setting) then this should never happen. ./waf configure ./waf build sudo ./waf install 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] more jack/qjackctl madness
On Sun, May 17, 2009 at 09:50:55AM +0200, MarcO'Chapeau wrote: > On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen > wrote: > > A request to the jackdmp and qjackctl devs: > > > >PLEASE REMOVE THAT DBUS MADNESS > > Hi Fons, > > As long as there's a compile time switch, I don't see how dbus could ever > be a problem for those who don't want to use it... Compile time ? I'm a simple user installing things from a reputable distro. > and for those who do, I can tell you it works pretty well. Are you serious ? When jackd is autostarted by an app (with the wrong settings, a separate problem), it creates a dbus daemon that seems to prevent qjackctl to start jackd with the right settings. The result is a jackd that does not any way correspond the the setup in qjackctl, and there is no way to escape from this, except by manually killing the daemon. Do you call that 'working pretty well' ? When qjackctl starts displaying ports that don't exist anymore and does not display those that do exist (no problem with jack-0.116.1) do you call that 'working pretty well' ? I'd call it completely broken. 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
On Sun, 17 May 2009 11:23:03 +0200, Fons Adriaensen wrote: > On Sun, May 17, 2009 at 09:50:55AM +0200, MarcO'Chapeau wrote: > >> On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen >> >> wrote: >> > A request to the jackdmp and qjackctl devs: >> > >> >PLEASE REMOVE THAT DBUS MADNESS >> >> Hi Fons, >> >> As long as there's a compile time switch, I don't see how dbus could ever >> be a problem for those who don't want to use it... > > Compile time ? I'm a simple user installing things from > a reputable distro. > >> and for those who do, I can tell you it works pretty well. > > Are you serious ? > > When jackd is autostarted by an app (with the wrong > settings, a separate problem), it creates a dbus daemon > that seems to prevent qjackctl to start jackd with > the right settings. The result is a jackd that does > not any way correspond the the setup in qjackctl, and > there is no way to escape from this, except by manually > killing the daemon. Do you call that 'working pretty > well' ? > > When qjackctl starts displaying ports that don't > exist anymore and does not display those that > do exist (no problem with jack-0.116.1) do you > call that 'working pretty well' ? > > I'd call it completely broken. Ok. a few things here: - dbus is not the default compile time config option. Your distro should probably disable it (until it's stable and shiny) - When dbus is active, it is indeed not backwards compatible with the legacy autostart feature... I agree it might need fixing - The behavior you describe with ports is indeed a bug and needs fixing And for the record, "fixing a mess" doesn't always need to be "deleting all the features that might create it". 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] more jack/qjackctl madness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fons Adriaensen schrieb: > On Sun, May 17, 2009 at 09:50:55AM +0200, MarcO'Chapeau wrote: > >> On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen >> wrote: >>> A request to the jackdmp and qjackctl devs: >>> >>>PLEASE REMOVE THAT DBUS MADNESS >> Hi Fons, >> >> As long as there's a compile time switch, I don't see how dbus could ever >> be a problem for those who don't want to use it... > > Compile time ? I'm a simple user installing things from > a reputable distro. > >> and for those who do, I can tell you it works pretty well. > > Are you serious ? > > When jackd is autostarted by an app (with the wrong > settings, a separate problem), it creates a dbus daemon > that seems to prevent qjackctl to start jackd with > the right settings. The result is a jackd that does > not any way correspond the the setup in qjackctl, and > there is no way to escape from this, except by manually > killing the daemon. Do you call that 'working pretty > well' ? > > When qjackctl starts displaying ports that don't > exist anymore and does not display those that > do exist (no problem with jack-0.116.1) do you > call that 'working pretty well' ? > > I'd call it completely broken. > > Ciao, > Relax man. Seems to be a problem of your distribution, compiled everything in the package and don't let you choose. Contact the distributors of that package for help. If you're fed up with these binary distribution issues switch to a source based distribution like gentoo. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoP17QACgkQVC26eJ+o0+2vAQCgi6xq/wYnoBigsbeC4kIJvb9v tXQAnRt33GpIv1hoITwSsEm/NO3JN0E9 =jKpc -END 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
Stéphane Letz wrote: >> To whom it may concern: (again) >> >> Jackdmp 1.9.2, Qjackctl 0.3.4 >> >> I do the following: >> >> - Log in. >> - Start a jack app. >> - The app starts jackd, but using the wrong card, >> and things don't work as expected. >> >> Questions: >> >> 1. Which parameters are used for such an autostart ? >> Certainly not the ones in ~/.jackdrc, these would >> have been correct. >> 2. Qjackctl also ignores ~/.jackdrc, so what is the >> purpose of this file ? >> >> - I terminate the app. Check with ps, there is no >> more jackd running. >> - I start qjackctl. It immediately shows a running >> jackd, but his has restarted the previous wrong one. >> - Click Stop, Start in qjackctl. Get the same wrong >> jackd again. >> - Verify qjackctl's Setup window. This shows the >> settings for the right jackd, while it is running >> another one. >> >> This is *madness* >> >> One more: you can't terminate qjackctl without >> terminating jackd as well. Why not ? Killing >> qjackctl does the right thing. >> >> A request to the jackdmp and qjackctl devs: >> >>PLEASE REMOVE THAT DBUS MADNESS >> >> Ciao, >> > > Fons, > > I really appreciate your feedback..., but AFAICS Qjackctl is > *absolutely* not using the DBUS layer! > > With jackdmp/jack2 compiled with default settings (that is *not* using > the --dbus at configure step), then it should absolutely behave as jack1 > was behaving. > > And I guess Rui can better answer the points concerning "~/.jackdrc," > and son on. > qjackctl only writes to ~/.jackdrc *iif* you opt to (see Setup/Misc/Save JACK audio server configuration). otherwise it *never* makes use of that file ie. it never auto-starts jackd implicitly; it only does start jackd explicitly if none is found running atm. if you really want several jackd server running simultaneously you'll have to take use of the JACK_DEFAULT_SERVER environment variable to tell qjackctl which server it will refer to. in fact, that is the only tricky way for you to have several qjackctl instances running as well. Stephane is right, qjackctl makes no use of the d-bus interface in jackaudio.org domain, although the latest in qjackctl cvs has some d-bus stuff of its own (rncbc.org domain) and only serves for starting/stopping qjackctl control--found useful for example to any system suspend/resume script you may think of. otoh, the only other jack application i know of that writes to ~/.jackdrc is ardour; have a look at your use case when starting jackd from behind ardour's open session dialog... cheera -- 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] more jack/qjackctl madness
On Sun, May 17, 2009 at 12:20:34PM +0200, MarcO'Chapeau wrote: > - dbus is not the default compile time config option. Your distro should > probably disable it (until it's stable and shiny) On this I agree. > - When dbus is active, it is indeed not backwards compatible with the > legacy autostart feature... I agree it might need fixing Very very nice. Good luck with it. > - The behavior you describe with ports is indeed a bug and needs fixing Seems to be qjackctl-0.3.4. Until this is fixed it is completely useless for me. > And for the record, "fixing a mess" doesn't always need to be "deleting all > the features that might create it". Depends on what these features are supposed to add. The only argument pro using dbus I'v heard so far is that it permits run-time discovery of new backends, internal clients and their parameters. If it were true, it's a very weak argument. We do have new backends every day do we ? The last one added I know of was more than two years ago. But it is bogus. The dbus server uses the existing control interface and it can't provide any info that can't be obtained there directly and with much less hassle. To get backend parameters, you can also just dlopen the backend.so and read them directly - there's a function for this, used by jackd for its help, and also by the control interface. Given the name of the backend it takes 10 lines of code to do this, which is 3 orders of magnitude less than all the dbus stuff required at both ends. Dbus assumes there is a local login, without that there is no session bus, and things don't work. Most of my audio machines are headless, there is no local login, but I still expect things to work, and that, IMHO, is not unreasonable. If it doesn't add any functionality that can be provided in simpler ways, and if it doesn't work in some perfectly legal use cases, there is no reason for having it. 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
On Sun, May 17, 2009 at 11:48:57AM +0100, Rui Nuno Capela wrote: > qjackctl only writes to ~/.jackdrc *iif* you opt to (see Setup/Misc/Save > JACK audio server configuration). otherwise it *never* makes use of that > file ie. it never auto-starts jackd implicitly; it only does start jackd > explicitly if none is found running atm. If the file is ignored by jackd, and by qjackctl, why does qjackctl write it at all ? > if you really want several jackd server running simultaneously I don't want that. I want to get rid of one that was started automatically, terminated, but restarted by dbus (why on earth ?) when I run qjackctl. The net result is that running qjackctl starts a server with parameters that have no relation at all to its setup (making it appear as if qjackctl has gone nuts), and starting the one corresponding to qjackctl's setup becomes impossible. It's very probably not qjackctl's fault. Two other things _are_: 1. I definitely want to be able to terminate qjackctl without stopping jackd, even if that jackd was started by qjackctl. This used to be possible. 2. Qjackctl-0.3.4 seems to have a bug handling the port creation and destruction callbacks, it continues to show ports that have been deleted and does not show some new ones. This happens when the delete/create calls are close together. Jack_evmon shows the right events in the right order, so it must be qjackctl getting it wrong. 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
On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen wrote: > The only argument pro using dbus I'v heard so far > is that it permits run-time discovery of new backends, > internal clients and their parameters. That's unfair. Read the archives. There are more arguments to that. > Dbus assumes there is a local login, without that > there is no session bus, and things don't work. > Most of my audio machines are headless, there is > no local login, but I still expect things to work, > and that, IMHO, is not unreasonable. It is not unreasonable. No one said you *had* to use dbus. This needs fixing and until it is fixed, packagers should be advised to disable dbus. > If it doesn't add any functionality that can be > provided in simpler ways, and if it doesn't work > in some perfectly legal use cases, there is no > reason for having it. The code for the legacy behavior might make jack a few lines lighter, but have you looked at qjackctl's code ? Starting jack via some pseudo command line scripting using Qt and c++ is not something I'd like to maintain. The thing is, Rui had no choice since it is the only way one could build a control application with the legacy jack. That's one of the things a control API is meant to change. 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] more jack/qjackctl madness
On Sun, May 17, 2009 at 01:43:55PM +0200, MarcO'Chapeau wrote: > The code for the legacy behavior might make jack a few lines lighter, but > have you looked at qjackctl's code ? Starting jack via some pseudo command > line scripting using Qt and c++ is not something I'd like to maintain. Starting a process in C/C++ is easy enough, and if Qt makes it difficult that's Qt's problem. Anyway, you don't need dbus, just provide a start() function in the control interface, accepting the options in a string, or as an argv[]. Why doesn't this exist ? Why do you have to go through all the movements of scanning parameters, types, ranges, setting them one by one, if you already know the command line (which will be the case in 99.99% of cases jack is started) ? -- 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
On Sun, 2009-05-17 at 14:17 +0200, Fons Adriaensen wrote: > Anyway, you don't need dbus, just provide a start() > function in the control interface, accepting the > options in a string, or as an argv[]. Why doesn't > this exist ? Why do you have to go through all the > movements of scanning parameters, types, ranges, > setting them one by one, if you already know the > command line (which will be the case in 99.99% of > cases jack is started) ? What I see as the most important thing, is that a client starting jack doesn't need to know how jack is supposed to be ran. This is why ~/.jackrc was made, but this causes several issues for me. The most important one of them being that the jackd server process is then connected directly to the client starting it. If that client quits, jackd dies (or leaves the client process hanging around until jackd is no longer needed). I hope to see from jack d-bus that clients will be able to tell the environment (through dbus) that "I want jack". The environment has a utility which is responsible for starting jack. This might be totally invisible to the user (which fits a lot of people), or it might be a more comprehensive tool like qjackctl. A tool that handles multiple jack configurations. I run jack frequently with 3 different sound cards with different parameters plus the dummy driver to do debugging. As for execv(char *path, char *argv[]). What Marc meant was that there could be (will be? is already) an API to give the client contorl over server parameters without teaching every app what command line parameters jackd has and how they're used. Sampo ___ 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
Fons Adriaensen wrote: > On Sun, May 17, 2009 at 11:48:57AM +0100, Rui Nuno Capela wrote: > >> qjackctl only writes to ~/.jackdrc *iif* you opt to (see Setup/Misc/Save >> JACK audio server configuration). otherwise it *never* makes use of that >> file ie. it never auto-starts jackd implicitly; it only does start jackd >> explicitly if none is found running atm. > > If the file is ignored by jackd, and by qjackctl, why > does qjackctl write it at all ? > >> if you really want several jackd server running simultaneously > > I don't want that. I want to get rid of one that was > started automatically, terminated, but restarted by > dbus (why on earth ?) when I run qjackctl. The net > result is that running qjackctl starts a server with > parameters that have no relation at all to its setup > (making it appear as if qjackctl has gone nuts), and > starting the one corresponding to qjackctl's setup > becomes impossible. It's very probably not qjackctl's > fault. > > Two other things _are_: > > 1. I definitely want to be able to terminate qjackctl > without stopping jackd, even if that jackd was started > by qjackctl. This used to be possible. > unfortunately, Qt4's class which is being used for wrapping the jackd process (QProcess) does kill it on its destructor. afaict, this behavior wasn't present in Qt3 and that's why there's no option to keep jackd running upon quitting qjackctl anymore. > 2. Qjackctl-0.3.4 seems to have a bug handling the port > creation and destruction callbacks, it continues to show > ports that have been deleted and does not show some new > ones. This happens when the delete/create calls are close > together. Jack_evmon shows the right events in the right > order, so it must be qjackctl getting it wrong. > this might just be a side-effect of the jack_port_t* reuse issue that i think has been discussed recently. qjackctl does not handle port (un)registration callbacks but does its book-keeping with this jack_port_t * handle as a unique key identifier. if, for instance, one client unregisters one given port and registers another in a quick sequence, it might just happen that the new port has the very same jack_port_t* address value which got just reclaimed and reused. alas, qjackctl assumes it's the very same port object as it keeps jack_port_t*s as its unique port identifiers, so nothing changes. i suppose i'll have to fix this soon. by properly handling port unregistration callbacks, which will be a novelty after 5+ years of doing just fine without on jack1 at least ;) 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] more jack/qjackctl madness
On Sun, May 17, 2009 8:07 am, Rui Nuno Capela wrote: > unfortunately, Qt4's class which is being used for wrapping the jackd > process (QProcess) does kill it on its destructor. afaict, this behavior > wasn't present in Qt3 and that's why there's no option to keep jackd > running upon quitting qjackctl anymore. Why not use QProcess::startDetached() ? -- G a b r i e l M B e d d i n g f i e l 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
On Sun, May 17, 2009 at 02:07:55PM +0100, Rui Nuno Capela wrote: > unfortunately, Qt4's class which is being used for wrapping the jackd > process (QProcess) does kill it on its destructor. afaict, this behavior > wasn't present in Qt3 and that's why there's no option to keep jackd > running upon quitting qjackctl anymore. First, you don't need Qt classes to start a process, so that's a bit weak. Second, I'd be surprise if Qt would not allow you to keep a process it created running. > > 2. Qjackctl-0.3.4 seems to have a bug handling the port > > creation and destruction callbacks, it continues to show > > ports that have been deleted and does not show some new > > ones. This happens when the delete/create calls are close > > together. Jack_evmon shows the right events in the right > > order, so it must be qjackctl getting it wrong. > > i suppose i'll have to fix this soon. by properly handling port > unregistration callbacks, which will be a novelty after 5+ years of > doing just fine without on jack1 at least ;) It shouldn't depend on jack being 1 or 2. 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
On Sunday 17 May 2009 05:24:04 Christian wrote: > Fons Adriaensen schrieb: > > On Sun, May 17, 2009 at 09:50:55AM +0200, MarcO'Chapeau wrote: > >> On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen > >> > >> > >> wrote: > >>> A request to the jackdmp and qjackctl devs: > >>> > >>>PLEASE REMOVE THAT DBUS MADNESS > >> > >> Hi Fons, > >> > >> As long as there's a compile time switch, I don't see how dbus could > >> ever be a problem for those who don't want to use it... > > > > Compile time ? I'm a simple user installing things from > > a reputable distro. > > > >> and for those who do, I can tell you it works pretty well. > > > > Are you serious ? > > > > When jackd is autostarted by an app (with the wrong > > settings, a separate problem), it creates a dbus daemon > > that seems to prevent qjackctl to start jackd with > > the right settings. The result is a jackd that does > > not any way correspond the the setup in qjackctl, and > > there is no way to escape from this, except by manually > > killing the daemon. Do you call that 'working pretty > > well' ? > > > > When qjackctl starts displaying ports that don't > > exist anymore and does not display those that > > do exist (no problem with jack-0.116.1) do you > > call that 'working pretty well' ? > > > > I'd call it completely broken. > > > > Ciao, > > Relax man. > Seems to be a problem of your distribution, compiled everything in the > package and don't let you choose. > Contact the distributors of that package for help. > If you're fed up with these binary distribution issues switch to a > source based distribution like gentoo. I think he wants to know why he has to. Why must this be a compile time option and not run time configurable? 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] more jack/qjackctl madness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 drew Roberts schrieb: > On Sunday 17 May 2009 05:24:04 Christian wrote: >> Fons Adriaensen schrieb: >>> On Sun, May 17, 2009 at 09:50:55AM +0200, MarcO'Chapeau wrote: On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen wrote: > A request to the jackdmp and qjackctl devs: > >PLEASE REMOVE THAT DBUS MADNESS Hi Fons, As long as there's a compile time switch, I don't see how dbus could ever be a problem for those who don't want to use it... >>> Compile time ? I'm a simple user installing things from >>> a reputable distro. >>> and for those who do, I can tell you it works pretty well. >>> Are you serious ? >>> >>> When jackd is autostarted by an app (with the wrong >>> settings, a separate problem), it creates a dbus daemon >>> that seems to prevent qjackctl to start jackd with >>> the right settings. The result is a jackd that does >>> not any way correspond the the setup in qjackctl, and >>> there is no way to escape from this, except by manually >>> killing the daemon. Do you call that 'working pretty >>> well' ? >>> >>> When qjackctl starts displaying ports that don't >>> exist anymore and does not display those that >>> do exist (no problem with jack-0.116.1) do you >>> call that 'working pretty well' ? >>> >>> I'd call it completely broken. >>> >>> Ciao, >> Relax man. >> Seems to be a problem of your distribution, compiled everything in the >> package and don't let you choose. >> Contact the distributors of that package for help. >> If you're fed up with these binary distribution issues switch to a >> source based distribution like gentoo. > > I think he wants to know why he has to. Why must this be a compile time > option > and not run time configurable? > > all the best, > > drew > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > > Uh right, didn't think of it that way. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoQIu8ACgkQVC26eJ+o0+3N5wCfVdJPb4PnKbDOFc2XUBjL39Jy RhYAoJ/lBBxD65VTxu92pFZmZJ0X0HPP =e6HK -END 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
On Sunday 17 May 2009 07:31:03 Fons Adriaensen wrote: > 1. I definitely want to be able to terminate qjackctl > without stopping jackd, even if that jackd was started > by qjackctl. This used to be possible. Indeed it did. I used to do it all the time. I have noticed I had problems with this recently but figured my forgetteror was working in high gear. It should certainly be possible to: 1. start qjackctl with a running jack and have it gain control over that jack and then be able to quit that qjackctl and leave jack running. 2. start qjackctl, start jack from qjackctl, quit qjackctl leaving jack running. Are either of these now impossible by design and if so, why? 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] more jack/qjackctl madness
Gabriel M. Beddingfield wrote: > On Sun, May 17, 2009 8:07 am, Rui Nuno Capela wrote: >> unfortunately, Qt4's class which is being used for wrapping the jackd >> process (QProcess) does kill it on its destructor. afaict, this behavior >> wasn't present in Qt3 and that's why there's no option to keep jackd >> running upon quitting qjackctl anymore. > > Why not use QProcess::startDetached() ? simply because QProcess::startDetached() sets the process loose of qjackctl control and all the IPC and inter-process sync facilities and notification signal/slots will be useless or no-ops in that way--you'd better start jackd from the command line if you take that route ;) seeya -- 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] more jack/qjackctl madness
On Sun, 17 May 2009, Rui Nuno Capela wrote: >> Why not use QProcess::startDetached() ? > > simply because QProcess::startDetached() sets the process loose of > qjackctl control and all the IPC and inter-process sync facilities and > notification signal/slots will be useless or no-ops in that way--you'd > better start jackd from the command line if you take that route ;) That makes sense. Capturing stdout/stderr in QJackCtl *is* helpful. Not sure what else is going on there. though. > > seeya > -- > 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] more jack/qjackctl madness
On Sun, May 17, 2009 11:43 am, Gabriel M. Beddingfield wrote: > > On Sun, 17 May 2009, Rui Nuno Capela wrote: > >>> Why not use QProcess::startDetached() ? >> >> simply because QProcess::startDetached() sets the process loose of >> qjackctl control and all the IPC and inter-process sync facilities and >> notification signal/slots will be useless or no-ops in that way--you'd >> better start jackd from the command line if you take that route ;) > > That makes sense. Capturing stdout/stderr in QJackCtl *is* helpful. Not > sure what else is going on there. > > though. ^^ (Grrr... e-mail sent before it was ready) It would be nice if were an option to start jackd detached, though. -- G a b r i e l M B e d d i n g f i e l 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
On Sun, May 17, 2009 at 05:04:28PM +0100, Rui Nuno Capela wrote: > simply because QProcess::startDetached() sets the process loose of > qjackctl control and all the IPC and inter-process sync facilities and > notification signal/slots will be useless or no-ops in that way--you'd > better start jackd from the command line if you take that route ;) So what ? It's perfectly possible to start a process and capture its stdout and stderr. What more IPC do you need ? Become a client and use the interfaces provided to clients. To kill the thing remember its pid and send a signal. 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
On Sun, 17 May 2009 12:14:26 -0400 drew Roberts wrote: > On Sunday 17 May 2009 07:31:03 Fons Adriaensen wrote: > > 1. I definitely want to be able to terminate qjackctl > > without stopping jackd, even if that jackd was started > > by qjackctl. This used to be possible. > > Indeed it did. I used to do it all the time. I have noticed I had > problems with this recently but figured my forgetteror was working in > high gear. > > It should certainly be possible to: > > 1. start qjackctl with a running jack and have it gain control over > that jack and then be able to quit that qjackctl and leave jack > running. > > 2. start qjackctl, start jack from qjackctl, quit qjackctl leaving > jack running. > > Are either of these now impossible by design and if so, why? > > all the best, > > drew Currently 1) is possible, don't know about jack2, gave up on it for the time being. Philipp ___ 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
I noticed some of the issues with qjackctl and am glad they got addressed now. One question is still open tough: Where does jack get it's options when it's auto-started by an application (not ardour, that's not an auto-start imho). Regards, Philipp ___ 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
hollun...@gmx.at wrote: > I noticed some of the issues with qjackctl and am glad they got > addressed now. > > One question is still open tough: > Where does jack get it's options when it's auto-started by an > application (not ardour, that's not an auto-start imho). > that's exactly the purpose of the ~/.jackdrc file: it contains the exact and complete jackd command line that should get auto-started. qjackctl can write to that file for you, meaning next time jackd gets auto-started by any other application it gets started with the very same options as last time set in qjackctl. otoh, ardour does almost the same but in advance: when jackd is not found currently running you're presented with the jack settings on the session open dialog, which then will take effect in ~/.jackdrc and thus to jackd when it gets immediately auto-started by ardour itself. 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] more jack/qjackctl madness
"MarcO'Chapeau" writes: > On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen > wrote: >> The only argument pro using dbus I'v heard so far >> is that it permits run-time discovery of new backends, >> internal clients and their parameters. > > That's unfair. Read the archives. There are more arguments to that. All features that jackdbus offers can be added without dbus. Using dbus was and still is the best way. It will be the best until there is better reusable model invented. Or if someone donates (development time) to implement such object model. Most important thing missing in jackd is the log file. Then you have other missing features: * no way several app to control single jack server. One needs to adopt it. * no runtime discovery of jack settings * no hierarchical settings file * complex patchbay API that results in complicated code in patchbay apps * multithread (for jack1 realtime too) threading model. (GUI) control patchbay app should be allowed to be single threaded and not required to handle graph change events in a realtime context. >> Dbus assumes there is a local login, without that >> there is no session bus, and things don't work. >> Most of my audio machines are headless, there is >> no local login, but I still expect things to work, >> and that, IMHO, is not unreasonable. > > It is not unreasonable. No one said you *had* to use dbus. This needs > fixing and until it is fixed, packagers should be advised to disable dbus. ATM headless and multiserver setups are not covered by jackdbus. This *can* be fixed with dbus model. Packagers tha have made the packages should have read this before enabling dbus: http://trac.jackaudio.org/wiki/JackDbusPackaging Maybe they did. I dont see why you Fons are attacking jackdbus because of packaging not matching your needs. -- Nedko Arnaudov pgpe49UcKihQf.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
Fons Adriaensen writes: > On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane Letz wrote: > >> I really appreciate your feedback..., but AFAICS Qjackctl is *absolutely* >> not using the DBUS layer! > > Then please tell what this is: (ps -ef output) > > fons 2444 1 0 10:43 ?00:00:00 /usr/bin/jackdbus auto > > Killing this makes qjackctl behave normally again, > and allows me to start the server configured in it > Setup window instead of getting a different one. Presence of jackbus process does not mean that jack server is started. It means that jack server may or may not be started. jackdbus service is there to allow in future creation of multiple jack servers. the easiest way to check whether jack server is started by jackdbus service is: jack_control status -- Nedko Arnaudov pgpKR5tgRqVyY.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
So again, i'll ask the question. Will we continue to have a Jack version minus the dbus infrastructure, once jack2 is released? Or are we destined to be dragged into a "compulsory" hybrid? I share Fon's concerns, and still don't understand why the dbus/pulse momentum is taking precedence over what has been up to now, a great audio solution for any user who wants to write and create music. I'm not a coder, but i'll ask the jack team, who i have a lot of respect for, to take a step back and have another look at the bigger picture again. Dbus may be a way into a partnership with Pulse, but that implies a degree of compulsory requirement for the user. And i don't think answering with "So don't use it" is an answer if there's a question over the persistence of Dbus and Pulse overriding the users intent. Fon's description of "Big Brother" seems more applicable, and less humorous, the more one thinks about this. Alex. p.s. I'm practical about software, so the Dbus "mantra" means nothing to me. On Mon, May 18, 2009 at 12:10 PM, Nedko Arnaudov wrote: > Fons Adriaensen writes: > >> On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane Letz wrote: >> >>> I really appreciate your feedback..., but AFAICS Qjackctl is *absolutely* >>> not using the DBUS layer! >> >> Then please tell what this is: (ps -ef output) >> >> fons 2444 1 0 10:43 ? 00:00:00 /usr/bin/jackdbus auto >> >> Killing this makes qjackctl behave normally again, >> and allows me to start the server configured in it >> Setup window instead of getting a different one. > > Presence of jackbus process does not mean that jack server is > started. It means that jack server may or may not be started. jackdbus > service is there to allow in future creation of multiple jack servers. > > the easiest way to check whether jack server is started by jackdbus > service is: > > jack_control status > > -- > Nedko Arnaudov > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > > -- 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] more jack/qjackctl madness
On Mon, May 18, 2009 at 01:23:20PM +0400, alex stone wrote: > Will we continue to have a Jack version minus the dbus infrastructure, > once jack2 is released? As an uninvolved observer I am wondering why the dbus control interface, if it is indeed only one of many potential interfaces using the c/c++ API, is not packaged separately as an optional add-on. If it is indeed a compile time option, the design is flawed IMHO. Generally, the new control API sounds like a good idea but why can't the new features be exposed as new command line tools without dbus dependency per default? So you want the dbus interface? Fine, just install jack-control-dbus or whatever. Or am I not getting it? Jan ___ 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
alex stone writes: > So again, i'll ask the question. > > Will we continue to have a Jack version minus the dbus infrastructure, > once jack2 is released? > > Or are we destined to be dragged into a "compulsory" hybrid? > > I share Fon's concerns, and still don't understand why the dbus/pulse > momentum is taking precedence over what has been up to now, a great > audio solution for any user who wants to write and create music. > > I'm not a coder, but i'll ask the jack team, who i have a lot of > respect for, to take a step back and have another look at the bigger > picture again. Dbus may be a way into a partnership with Pulse, but > that implies a degree of compulsory requirement for the user. > > And i don't think answering with "So don't use it" is an answer if > there's a question over the persistence of Dbus and Pulse overriding > the users intent. > > Fon's description of "Big Brother" seems more applicable, and less > humorous, the more one thinks about this. > > Alex. > > p.s. I'm practical about software, so the Dbus "mantra" means nothing to me. There are three packaging scenarios described in http://trac.jackaudio.org/wiki/JackDbusPackaging This document is created packagers can choose how to package jack. The mixed setup is can easily lead to user frustration and this is explained. I personally use the mixed setup but i know how the whole mixed system behaves and I need to start jackd occasionally. I wouldn't recommend packaging mixed setup. In ubuntu packages I've created jackdbus is separate package. jackd is separate package too. They both implement jack server virtual package. Packagers must choose between classic jackd or dbus-only scenarios unless they want to cause pain to their users. Some more things I've implemented in the ubuntu packaging... Only dbus control apps depend on jackdbus package. qjackctl depends on jackd package. So if you install qjackctl but dont want (or dont know about) jackdbus you get no dbus. If you install lpatchage or laditools you get dbus setup. Users don't care about jackd vs jackdbus. They care about the frontends. If they are used to qjackctl+jackd they will use that and will get no "dbus ate my babies" feeling. If they like ladi control apps, they will not use jackd. -- Nedko Arnaudov pgp0X7wVkPLf9.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
Jan Weil writes: > On Mon, May 18, 2009 at 01:23:20PM +0400, alex stone wrote: >> Will we continue to have a Jack version minus the dbus infrastructure, >> once jack2 is released? > > As an uninvolved observer I am wondering why the dbus control interface, > if it is indeed only one of many potential interfaces using the c/c++ > API, is not packaged separately as an optional add-on. If it is indeed a > compile time option, the design is flawed IMHO. Generally, the new > control API sounds like a good idea but why can't the new features be > exposed as new command line tools without dbus dependency per default? > So you want the dbus interface? Fine, just install jack-control-dbus or > whatever. > > Or am I not getting it? You are getting it but obviously the one who has put those packages in the "respected" repository is not getting it. I've packaged jack2 in the way you've mentioned. Of course those are for specific distro (ubuntu) and not real packages but draft packages that i've made to simplify work of real packagers when they take the maintainership. -- Nedko Arnaudov pgpFt0RbxCSlK.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
On Monday 18 May 2009 05:49:01 Jan Weil wrote: > If it is indeed a > compile time option, the design is flawed IMHO. Generally, the new > control API sounds like a good idea but why can't the new features be > exposed as new command line tools without dbus dependency per default? > So you want the dbus interface? Fine, just install jack-control-dbus or > whatever. > > Or am I not getting it? > > Jan I have asked similar questions with pretty much the same intent re the compile time issue twice now and don't recall seeing a response to either. Also, I have not seen anyone who is "championing" the dbus / pulse side of things explain what is happening to Fons. It almost seems like they are telling him he can't be seeing what he is reporting. So, dbus guys, how is it that dbus is (re)starting on qjackctl launch? (Fons, isn't that what you are saying?) And why is it starting a jackd with different parameters that are in the rc file and in the qjackctl setup config? How does dbus know what parameters to start jack with? Where is that configured? (Perhaps this will solve the issue, I don't recall this information passing before my eyes in this thread so far.) 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] more jack/qjackctl madness
drew Roberts writes: > How does dbus know what parameters to start jack with? Where is that > configured? (Perhaps this will solve the issue, I don't recall this > information passing before my eyes in this thread so far.) jackbus reads the configuration file and then start jack server through the control API. The configuration file is stored in ~/.config/jack/conf.xml (location conforming to the XDG Base Directory Specification). -- Nedko Arnaudov pgpFeIBAMoToM.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
On Mon, May 18, 2009 at 03:14:08PM +0300, Nedko Arnaudov wrote: > The configuration file is stored in > ~/.config/jack/conf.xml > (location conforming to the XDG Base Directory Specification). Frankly I don't give a damn for that spec, or in fact anything from that self-styled group of *** who have apparently never in their lives seen a computer without a running desktop, have no idea of how things are done on a Unix-like system, are the source of all misery I've been confronted with lately, and are slowly turning Linux into something worse than Windows (I mean freedesktop.org). To start with, jackd is not a desktop app, and Unix/Linux apps are traditionally configured using an ~/***rc file. 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
Fons Adriaensen writes: > On Mon, May 18, 2009 at 03:14:08PM +0300, Nedko Arnaudov wrote: > >> The configuration file is stored in >> ~/.config/jack/conf.xml >> (location conforming to the XDG Base Directory Specification). > > Frankly I don't give a damn for that spec, or in fact > anything from that self-styled group of *** who have > apparently never in their lives seen a computer without > a running desktop, have no idea of how things are done > on a Unix-like system, are the source of all misery I've > been confronted with lately, and are slowly turning Linux > into something worse than Windows (I mean freedesktop.org). > > To start with, jackd is not a desktop app, and Unix/Linux > apps are traditionally configured using an ~/***rc file. To be honest I dont care about the location of the file. It is fine with me and I'm not going to advocate XDG, it is a fight between you and them. -- Nedko Arnaudov pgpHmP1YLVQUg.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
On Sun, 2009-05-17 at 13:11 +0200, Fons Adriaensen wrote:
> On Sun, May 17, 2009 at 12:20:34PM +0200, MarcO'Chapeau wrote:
>
> > - dbus is not the default compile time config option. Your distro should
> > probably disable it (until it's stable and shiny)
>
> On this I agree.
(sorry for the delay, I just got back from a couple of weeks of no
internet access).
Yes, obviously you are not installing from a "reputable" distro. Sigh. I
shall rebuild and disable dbus, I thought at the time I built 1.9.2 it
would be an interesting option and did not realize all the problems it
could/would cause. Argh/sorry.
I have at the moment still 314 (pi??) more messages marked unread on the
jack list folder in my mail client so most probably this has been hashed
to death already...
Is there a way to disable the dbus functionality if jackmp is compiled
with it? ("jack_control exit"?) I'm far from understanding the whole
thing in detail...
-- Fernando
> > - When dbus is active, it is indeed not backwards compatible with the
> > legacy autostart feature... I agree it might need fixing
>
> Very very nice. Good luck with it.
>
> > - The behavior you describe with ports is indeed a bug and needs fixing
>
> Seems to be qjackctl-0.3.4. Until this is fixed it is completely
> useless for me.
>
> > And for the record, "fixing a mess" doesn't always need to be "deleting all
> > the features that might create it".
>
> Depends on what these features are supposed to add.
>
> The only argument pro using dbus I'v heard so far
> is that it permits run-time discovery of new backends,
> internal clients and their parameters.
>
> If it were true, it's a very weak argument. We
> do have new backends every day do we ? The last
> one added I know of was more than two years ago.
>
> But it is bogus. The dbus server uses the existing
> control interface and it can't provide any info
> that can't be obtained there directly and with
> much less hassle.
>
> To get backend parameters, you can also just dlopen
> the backend.so and read them directly - there's a
> function for this, used by jackd for its help, and
> also by the control interface.
> Given the name of the backend it takes 10 lines
> of code to do this, which is 3 orders of magnitude
> less than all the dbus stuff required at both ends.
>
> Dbus assumes there is a local login, without that
> there is no session bus, and things don't work.
> Most of my audio machines are headless, there is
> no local login, but I still expect things to work,
> and that, IMHO, is not unreasonable.
>
> If it doesn't add any functionality that can be
> provided in simpler ways, and if it doesn't work
> in some perfectly legal use cases, there is no
> reason for having it.
>
> Ciao,
>
___
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 Sun, May 17, 2009 at 1:49 PM, Stéphane Letz wrote: > After all these discussions on JACK2, D-Bus and Qjackctl issues, here are > some general comments: > > 1) JACK2 *default* compilation mode defines the same starting scheme at > JACK1 was doing. So (beside possible bugs) it is supposed to be completely > "interchangeable" with JACK1. It can be controled with Qjackctl as usual. > > 2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus based > control application... (jack_control is a simple python example of a control > application part of the package). Using JACK2 compiled in D-Bus with > Qjackctl is a "receipe for trouble", even if if can be done in some simple > use cases. (The point is that in this case the client auto-start feature > starts the "jackdbus" exe instead of "jackd" with all of the related > "settings" issues). > > 3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a Qjackctl > bug, so has to be fixed at the right place. > > I don't see right now any raisonable way to fix this mess, better than > adding even more complexity in the design... (Nedko any idea?) Otherwise I > guess the only way is to make this totally clear for packagers : 1) is the > standard way that maintains complete compatibility with legacy applications > and control applications. 2) is the "new" way to be used with new D-Bus > based control application (patchage ??)... So it would mean 2 separated > packages. this sounds like a mess. there is a control API. i believe it was agreed that the control API could be accessed directly (from C/C++ etc), or via other systems for which translators/layers were added (e.g. DBus). i can see no reason why anyone would want to use choose between a JACK server that can be controlled via either DBus or the control API but not both. what is going on? ___ 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
Le 17 mai 09 à 19:57, Paul Davis a écrit : > On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz wrote: >> After all these discussions on JACK2, D-Bus and Qjackctl issues, >> here are >> some general comments: >> >> 1) JACK2 *default* compilation mode defines the same starting >> scheme at >> JACK1 was doing. So (beside possible bugs) it is supposed to be >> completely >> "interchangeable" with JACK1. It can be controled with Qjackctl as >> usual. >> >> 2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus >> based >> control application... (jack_control is a simple python example of >> a control >> application part of the package). Using JACK2 compiled in D-Bus with >> Qjackctl is a "receipe for trouble", even if if can be done in >> some simple >> use cases. (The point is that in this case the client auto-start >> feature >> starts the "jackdbus" exe instead of "jackd" with all of the related >> "settings" issues). >> >> 3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a >> Qjackctl >> bug, so has to be fixed at the right place. >> >> I don't see right now any raisonable way to fix this mess, better >> than >> adding even more complexity in the design... (Nedko any idea?) >> Otherwise I >> guess the only way is to make this totally clear for packagers : >> 1) is the >> standard way that maintains complete compatibility with legacy >> applications >> and control applications. 2) is the "new" way to be used with new >> D-Bus >> based control application (patchage ??)... So it would mean 2 >> separated >> packages. > > this sounds like a mess. there is a control API. i believe it was > agreed that the control API could be accessed directly (from C/C++ > etc), or via other systems for which translators/layers were added > (e.g. DBus). i can see no reason why anyone would want to use choose > between a JACK server that can be controlled via either DBus or the > control API but not both. what is going on? The point is that when compiled in D-Bus mode, libjack behaves differently regarding the way it start the server: it does not use the fork+exec mode anymore but call the D-Bus service to start the server. This "simple" change is the source of all the problems we then see. 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] more jack/qjackctl madness : some comments
On Sun, May 17, 2009 at 2:04 PM, Stéphane Letz wrote: > > The point is that when compiled in D-Bus mode, libjack behaves differently > regarding the way it start the server: it does not use the fork+exec mode > anymore but call the D-Bus service to start the server. This "simple" change > is the source of all the problems we then see. so if i understand correctly, there is effectively a layer of indirection. rather than a request arriving via D-Bus leading to a normal fork-exec, it leads to D-Bus service request, which presumably (somewhere, sometime) leads to a fork-exec of the server? is this correct? ___ 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
Le 17 mai 09 à 20:10, Paul Davis a écrit : > On Sun, May 17, 2009 at 2:04 PM, Stéphane Letz wrote: >> >> The point is that when compiled in D-Bus mode, libjack behaves >> differently >> regarding the way it start the server: it does not use the fork >> +exec mode >> anymore but call the D-Bus service to start the server. This >> "simple" change >> is the source of all the problems we then see. > > so if i understand correctly, there is effectively a layer of > indirection. rather than a request arriving via D-Bus leading to a > normal fork-exec, it leads to D-Bus service request, which presumably > (somewhere, sometime) leads to a fork-exec of the server? is this > correct? "Show me the code" : http://trac.jackaudio.org/browser/jack2/trunk/jackmp/posix/ JackPosixServerLaunch.cpp It starts the D-Bus jackaudio service that actually starts "jackdbus" process with it's own logic (server settings save/restore and so on...) Hoppefully I described it right (Nedko again?) 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] more jack/qjackctl madness : some comments
On Sunday 17 May 2009 14:04:54 Stéphane Letz wrote: > The point is that when compiled in D-Bus mode, libjack behaves > differently regarding the way it start the server: it does not use > the fork+exec mode anymore but call the D-Bus service to start the > server. This "simple" change is the source of all the problems we > then see. > > Stephane Can someone explain why this *must* be a compile time option rather that an option in a config file? 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] more jack/qjackctl madness : some comments
On Sun, 17 May 2009 13:57:29 -0400, Paul Davis wrote: > On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz wrote: >> After all these discussions on JACK2, D-Bus and Qjackctl issues, here are >> some general comments: >> >> 1) JACK2 *default* compilation mode defines the same starting scheme at >> JACK1 was doing. So (beside possible bugs) it is supposed to be >> completely >> "interchangeable" with JACK1. It can be controled with Qjackctl as usual. >> >> 2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus based >> control application... (jack_control is a simple python example of a >> control >> application part of the package). Using JACK2 compiled in D-Bus with >> Qjackctl is a "receipe for trouble", even if if can be done in some >> simple >> use cases. (The point is that in this case the client auto-start feature >> starts the "jackdbus" exe instead of "jackd" with all of the related >> "settings" issues). >> >> 3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a >> Qjackctl >> bug, so has to be fixed at the right place. >> >> I don't see right now any raisonable way to fix this mess, better than >> adding even more complexity in the design... (Nedko any idea?) Otherwise >> I >> guess the only way is to make this totally clear for packagers : 1) is >> the >> standard way that maintains complete compatibility with legacy >> applications >> and control applications. 2) is the "new" way to be used with new D-Bus >> based control application (patchage ??)... So it would mean 2 >> separated >> packages. > > this sounds like a mess. there is a control API. i believe it was > agreed that the control API could be accessed directly (from C/C++ > etc), or via other systems for which translators/layers were added > (e.g. DBus). i can see no reason why anyone would want to use choose > between a JACK server that can be controlled via either DBus or the > control API but not both. what is going on? I can't tell about the c/c++ API since I'm not really using it. The issue here is with the legacy way of doing things: controlling jack from the command line and it's set of switches, playing with PIDs, redirecting some output... Legacy can't work well along control API. 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] more jack/qjackctl madness : some comments
On Sun, May 17, 2009 at 08:04:54PM +0200, Stéphane Letz wrote: > The point is that when compiled in D-Bus mode, libjack behaves differently > regarding the way it start the server: it does not use the fork+exec mode > anymore but call the D-Bus service to start the server. This "simple" > change is the source of all the problems we then see. That itself is not the source of the problems. The source is that even after the server that was started as explained above has been terminated, D-Bus leaves a daemon running that tries to be clever but gets it wrong. Which effectively blocks whatever the user wants to do, as it only allows to restart the previous server and even restarts it before anyone has asked for it. 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
Paul Davis writes: > On Sun, May 17, 2009 at 1:49 PM, Stéphane Letz wrote: >> After all these discussions on JACK2, D-Bus and Qjackctl issues, here are >> some general comments: >> >> 1) JACK2 *default* compilation mode defines the same starting scheme at >> JACK1 was doing. So (beside possible bugs) it is supposed to be completely >> "interchangeable" with JACK1. It can be controled with Qjackctl as usual. >> >> 2) JACK2 compiled in D-Bus is supposed to be controlled by a D-Bus based >> control application... (jack_control is a simple python example of a control >> application part of the package). Using JACK2 compiled in D-Bus with >> Qjackctl is a "receipe for trouble", even if if can be done in some simple >> use cases. (The point is that in this case the client auto-start feature >> starts the "jackdbus" exe instead of "jackd" with all of the related >> "settings" issues). >> >> 3) The port issue Fons told about in Qjackctl 0.3.4 seems to be a Qjackctl >> bug, so has to be fixed at the right place. >> >> I don't see right now any raisonable way to fix this mess, better than >> adding even more complexity in the design... (Nedko any idea?) Otherwise I >> guess the only way is to make this totally clear for packagers : 1) is the >> standard way that maintains complete compatibility with legacy applications >> and control applications. 2) is the "new" way to be used with new D-Bus >> based control application (patchage ??)... So it would mean 2 separated >> packages. > > this sounds like a mess. there is a control API. i believe it was > agreed that the control API could be accessed directly (from C/C++ > etc), or via other systems for which translators/layers were added > (e.g. DBus). i can see no reason why anyone would want to use choose > between a JACK server that can be controlled via either DBus or the > control API but not both. what is going on? > ___ > Jack-Devel mailing list > jack-de...@lists.jackaudio.org > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org > Using the "dbus ate my babies" matra is causing mess because other people don't think so. Using dbus interface in qjackctl would fix lot of this mess and this is the reason I asked Rui about that. Of course "dbus ate my babies" ppl would see usage of jackdbus in qjackctl as a bad thing. Does qjackctl support headless and multiserver jack setups? How headless setups work? When someone logins through ssh, does it access jackd server that runs as same user? -- Nedko Arnaudov pgpxStrb4eEat.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
hi Nedko, On Mon, May 18, 2009 09:17, Nedko Arnaudov wrote: > > Using the "dbus ate my babies" matra is causing mess because other > people don't think so. Using dbus interface in qjackctl would fix lot of > this mess and this is the reason I asked Rui about that. Of course "dbus > ate my babies" ppl would see usage of jackdbus in qjackctl as a bad thing. > main trouble, imo, is that jackdbus is currently not playing fair game with qjackctl wrt. jackd auto-start functionality. as noted in one my other post, qjackctl always issues jack_client_open() with *JackNoStartServer* option, which explicitly instructs on jack stack for *never* start jackd on its call. apparently, jackdbus lacks this call and starts jackd no matter what, giving us all the "ate my babies" mantra ;) so it seems like just a missing piece in the jackdbus implementation re. the jack api. it this stands true, i guess it should be easily fixed so that future jackdbus and legacy qjackctl can still live on together for many years to come ;) > Does qjackctl support headless and multiserver jack setups? > How headless setups work? When someone logins through ssh, does it > access jackd server that runs as same user? > well, of course, being qjackctl a X client, you can run qjackctl on the headless machine and render the GUI on your local X server (ie. your headtop, desktop, laptop, whatever) via ssh -X and DISPLAY trickery. if you add that to disparate JACK_DEFAULT_SERVER environment settings, you can have control of multiple jackd servers, either local or even remote. 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] more jack/qjackctl madness : some comments
"Rui Nuno Capela" writes: > hi Nedko, > > On Mon, May 18, 2009 09:17, Nedko Arnaudov wrote: >> >> Using the "dbus ate my babies" matra is causing mess because other >> people don't think so. Using dbus interface in qjackctl would fix lot of >> this mess and this is the reason I asked Rui about that. Of course "dbus >> ate my babies" ppl would see usage of jackdbus in qjackctl as a bad thing. >> > > main trouble, imo, is that jackdbus is currently not playing fair game > with qjackctl wrt. jackd auto-start functionality. > > as noted in one my other post, qjackctl always issues jack_client_open() > with *JackNoStartServer* option, which explicitly instructs on jack stack > for *never* start jackd on its call. apparently, jackdbus lacks this call > and starts jackd no matter what, giving us all the "ate my babies" mantra > ;) > > so it seems like just a missing piece in the jackdbus implementation re. > the jack api. it this stands true, i guess it should be easily fixed so > that future jackdbus and legacy qjackctl can still live on together for > many years to come ;) libjack does not start jack server if JackNoStartServer is specified. This behaviour is same for both jackd autolaunching and dbus jack server starting through activation. Presense of the jackdbus process *DOES NOT MEAN* that jack server is started. It looks like fair game to me. >> Does qjackctl support headless and multiserver jack setups? >> How headless setups work? When someone logins through ssh, does it >> access jackd server that runs as same user? >> > > well, of course, being qjackctl a X client, you can run qjackctl on the > headless machine and render the GUI on your local X server (ie. your > headtop, desktop, laptop, whatever) via ssh -X and DISPLAY trickery. if > you add that to disparate JACK_DEFAULT_SERVER environment settings, you > can have control of multiple jackd servers, either local or even remote. Of course instead of (or together with) DISPLAY trickery one can use DBUS_SESSION_BUS_ADDRESS and achieve the same effect. I.e. jackdbus operation in headless mode. Moreover, one can have non-X11 mode (without ssh X11 forwarding). The bad news is that ssh has built in support for X11 forwarding but has no support for dbus. Looks like feature request for openssh :D -- Nedko Arnaudov pgpHVLqqEib74.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 12:15:10PM +0300, Nedko Arnaudov wrote: > libjack does not start jack server if JackNoStartServer is > specified. This behaviour is same for both jackd autolaunching and dbus > jack server starting through activation. Presense of the jackdbus > process *DOES NOT MEAN* that jack server is started. It looks like fair > game to me. This is definitely *not* true. Presence of the 'jackdbus auto' daemon results in a jackd starting whenever qjackctl is started, and the author of that app has already reported that qjackctl explicitly requests no autostart when trying to become a jack client. -- 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 writes:
> On Mon, May 18, 2009 at 12:15:10PM +0300, Nedko Arnaudov wrote:
>
>> libjack does not start jack server if JackNoStartServer is
>> specified. This behaviour is same for both jackd autolaunching and dbus
>> jack server starting through activation. Presense of the jackdbus
>> process *DOES NOT MEAN* that jack server is started. It looks like fair
>> game to me.
>
> This is definitely *not* true. Presence of the 'jackdbus auto'
> daemon results in a jackd starting whenever qjackctl is
> started, and the author of that app has already reported
> that qjackctl explicitly requests no autostart when trying
> to become a jack client.
Fons I think we can both read C code, right?
From posix/JackPosixServerLaunch.cpp, line 166:
static int start_server(const char* server_name, jack_options_t options)
{
if ((options & JackNoStartServer) || getenv("JACK_NO_START_SERVER")) {
return 1;
}
#if defined(JACK_DBUS)
return start_server_dbus(server_name);
#else
jackd fork/exec stuff
presence of process with "jackdbus auto' commandline those not mean that
*server* is started. This is the dbus service, not the jack server
running.
--
Nedko Arnaudov
pgpfxCboeFzWw.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 10:15, Nedko Arnaudov wrote: > "Rui Nuno Capela" writes: > >> On Mon, May 18, 2009 09:17, Nedko Arnaudov wrote: >> >>> >>> Using the "dbus ate my babies" matra is causing mess because other >>> people don't think so. Using dbus interface in qjackctl would fix lot >>> of this mess and this is the reason I asked Rui about that. Of course >>> "dbus >>> ate my babies" ppl would see usage of jackdbus in qjackctl as a bad >>> thing. >>> >> >> main trouble, imo, is that jackdbus is currently not playing fair game >> with qjackctl wrt. jackd auto-start functionality. >> >> as noted in one my other post, qjackctl always issues >> jack_client_open() with *JackNoStartServer* option, which explicitly >> instructs on jack stack for *never* start jackd on its call. apparently, >> jackdbus lacks this call and starts jackd no matter what, giving us all >> the "ate my babies" mantra ;) >> >> >> so it seems like just a missing piece in the jackdbus implementation >> re. the jack api. it this stands true, i guess it should be easily fixed >> so that future jackdbus and legacy qjackctl can still live on together >> for many years to come ;) > > > libjack does not start jack server if JackNoStartServer is specified. This > behaviour is same for both jackd autolaunching and dbus jack server > starting through activation. Presense of the jackdbus process *DOES NOT > MEAN* that jack server is started. It looks like fair > game to me. > Nedko, that just doesn't seem to hold against what Fons has been reporting. are you implying that the jackdbus stack is ignoring any explicit jackd command line arguments and honoring what is in its own config file ??? imnsho, that's not plain wrong, that's terrorism! it does "ate all your babies" alright >:( nuff said? -- 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] more jack/qjackctl madness : some comments
On Mon, May 18, 2009 at 05:13:19PM +0300, Nedko Arnaudov wrote:
> Fons I think we can both read C code, right?
>
> From posix/JackPosixServerLaunch.cpp, line 166:
>
> static int start_server(const char* server_name, jack_options_t options)
> {
> if ((options & JackNoStartServer) || getenv("JACK_NO_START_SERVER")) {
> return 1;
> }
>
> #if defined(JACK_DBUS)
> return start_server_dbus(server_name);
> #else
>
> jackd fork/exec stuff
>
I can read this and it can mean different things.
- This code is not involved in what happens
- The value of the options argument is wrong.
> presence of process with "jackdbus auto' commandline those not mean that
> *server* is started. This is the dbus service, not the jack server
> running.
I know that. The fact remains that when the 'jackdus auto'
daemon is running a jackd is started whenever qjackctl is
started. You can go on to deny this, but that doesn't
change the facts.
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 writes:
> On Mon, May 18, 2009 at 05:13:19PM +0300, Nedko Arnaudov wrote:
>
>> Fons I think we can both read C code, right?
>>
>> From posix/JackPosixServerLaunch.cpp, line 166:
>>
>> static int start_server(const char* server_name, jack_options_t options)
>> {
>> if ((options & JackNoStartServer) || getenv("JACK_NO_START_SERVER")) {
>> return 1;
>> }
>>
>> #if defined(JACK_DBUS)
>> return start_server_dbus(server_name);
>> #else
>>
>> jackd fork/exec stuff
>>
>
> I can read this and it can mean different things.
>
> - This code is not involved in what happens
> - The value of the options argument is wrong.
It is involved in what happenes. At least from what I've got about the
problem you have.
You have installed jack package that does not work well with
qjackctl (dbus enabled one). Your application autostarted jack server
through dbus. But you havent configured it. QJackCtl is dbus
ignorant. You should not use qjackctl with jackdbus system. Unless you
know what you are doing. Or unless qjackctl gets jackdbus support.
jackdrc style commandline options for jackd are for jackd. They are not
used for jackdbus. They cant be used for jackdbus. Because of the object
activation works in all distributed object systems I know. This includes
DCOM and D-Bus.
>> presence of process with "jackdbus auto' commandline those not mean that
>> *server* is started. This is the dbus service, not the jack server
>> running.
>
> I know that. The fact remains that when the 'jackdus auto'
> daemon is running a jackd is started whenever qjackctl is
> started. You can go on to deny this, but that doesn't
> change the facts.
So you complain about qjackctl missing support for jackdbus? Having that
will be nice :)
--
Nedko Arnaudov
pgpgHZy0sPwCp.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 06:08:33PM +0300, Nedko Arnaudov wrote: > You have installed jack package that does not work well with > qjackctl (dbus enabled one). Your application autostarted jack server > through dbus. It did not. No jack app here uses dbus. > jackdrc style commandline options for jackd are for jackd. They are not > used for jackdbus. They cant be used for jackdbus. Because of the object > activation works in all distributed object systems I know. This includes > DCOM and D-Bus. What nonsense it this ? Everybody here tells me that the dbus support is build on top of the existing C API and nothing else, that it just a communication layer allowing you to access the C API. Hence jackd is the same with dbus or without. Or isn't this true, and is the dbus support much more invasive than some people want to admit ? The client that autostarted a jackd did not use dbus. When I later started qjackctl it did not use dbus. Yet the 'jackdbus auto' daemon (which nobody needed since all apps use the C API, but started anyway) interferes with clients not using dbus at all. Are you trying to say that on a jack+dbus system *all* jack apps have to be dbus-aware (or fail) ? > So you complain about qjackctl missing support for jackdbus? Having that > will be nice :) Is that supposed to be funny ? Final remark: the dbus advocates here are seriously contradicting themselves. 1. Dbus is just a communication layer. 2. Dbus adds functionality that can't be provided via the normal interfaces. Both can't be true at the same time. 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 Mon, May 18, 2009 16:08, Nedko Arnaudov wrote:
> Fons Adriaensen writes:
>
>> On Mon, May 18, 2009 at 05:13:19PM +0300, Nedko Arnaudov wrote:
>>
>>
>>> Fons I think we can both read C code, right?
>>>
>>>
>>> From posix/JackPosixServerLaunch.cpp, line 166:
>>>
>>>
>>> static int start_server(const char* server_name, jack_options_t
>>> options) {
>>> if ((options & JackNoStartServer) || getenv("JACK_NO_START_SERVER")) {
>>> return 1; }
>>>
>>>
>>> #if defined(JACK_DBUS)
>>> return start_server_dbus(server_name); #else
>>>
>>> jackd fork/exec stuff
>>>
>>
>> I can read this and it can mean different things.
>>
>>
>> - This code is not involved in what happens
>> - The value of the options argument is wrong.
>>
>
> It is involved in what happenes. At least from what I've got about the
> problem you have.
>
> You have installed jack package that does not work well with
> qjackctl (dbus enabled one). Your application autostarted jack server
> through dbus. But you havent configured it. QJackCtl is dbus ignorant. You
> should not use qjackctl with jackdbus system. Unless you know what you are
> doing. Or unless qjackctl gets jackdbus support.
>
> jackdrc style commandline options for jackd are for jackd. They are not
> used for jackdbus. They cant be used for jackdbus. Because of the object
> activation works in all distributed object systems I know. This includes
> DCOM and D-Bus.
>
>
>>> presence of process with "jackdbus auto' commandline those not mean
>>> that *server* is started. This is the dbus service, not the jack
>>> server running.
>>
>> I know that. The fact remains that when the 'jackdus auto'
>> daemon is running a jackd is started whenever qjackctl is started. You
>> can go on to deny this, but that doesn't change the facts.
>
> 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.
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.
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.
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.
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 :)
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] more jack/qjackctl madness : some comments
Fons Adriaensen writes: > On Mon, May 18, 2009 at 06:08:33PM +0300, Nedko Arnaudov wrote: > >> You have installed jack package that does not work well with >> qjackctl (dbus enabled one). Your application autostarted jack server >> through dbus. > > It did not. No jack app here uses dbus. If i got it right (dbus enabled libjack.so) then every jack app on your machine uses dbus. >> jackdrc style commandline options for jackd are for jackd. They are not >> used for jackdbus. They cant be used for jackdbus. Because of the object >> activation works in all distributed object systems I know. This includes >> DCOM and D-Bus. > > What nonsense it this ? Everybody here tells me that > the dbus support is build on top of the existing C > API and nothing else, that it just a communication > layer allowing you to access the C API. Hence jackd > is the same with dbus or without. Or isn't this true, > and is the dbus support much more invasive than some > people want to admit ? I dont get what you are talking about. Please explain. > The client that autostarted a jackd did not use dbus. > When I later started qjackctl it did not use dbus. libjack.so will not start jackd if compiled in dbus. Actually it can but only if jack server start through dbus failed. Obvisouly it didnt because you said that it got started with wrong arguments, right? > Yet the 'jackdbus auto' daemon (which nobody needed > since all apps use the C API, but started anyway) > interferes with clients not using dbus at all. again if you have jackdbus enabled libjack.so all your clients DO interact with dbus. > Are you trying to say that on a jack+dbus system > *all* jack apps have to be dbus-aware (or fail) ? NO. dbus knowledge is behind libjack. But yes, they load libdbus.so when they are started. Maybe you want to verify that with ldd? >> So you complain about qjackctl missing support for jackdbus? Having that >> will be nice :) > > Is that supposed to be funny ? Yes :) > Final remark: the dbus advocates here are seriously > contradicting themselves. > > 1. Dbus is just a communication layer. no it is distributed object model. this somewhat bigger than IPC. > 2. Dbus adds functionality that can't be >provided via the normal interfaces. and no again It can be added. You can reinvent the wheel. You can reuse other already invented mechanism. D-Bus was choosen because it is already quite widespread in Linux systems. > Both can't be true at the same time. they are both false but even if they were true they can be both true, according to my understanding of logic :D if A and B are not corelated then A and B can be true at the same time. -- Nedko Arnaudov pgpZ3Al58oyuR.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 11:57 AM, Rui Nuno Capela 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. we are are discussing ways to reconcile these differences on IRC. for those who don't understand why the second scenario is worth considering, i would point to the questions that (relatively) frequently come from users about changing a running JACK system to use another h/w interface, or to start/stop JACK temporarily for some reason. there is one school of opinion that would say that "stop jackd and restart it with the correct parameters" is the correct approach to this question. i think that at LAC2008 it was felt that we could do better. --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
"Rui Nuno Capela" 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. > 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 pgpPb2FmvcEBJ.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
Paul Davis writes: > On Mon, May 18, 2009 at 11:57 AM, Rui Nuno Capela 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. > > we are are discussing ways to reconcile these differences on IRC. > > for those who don't understand why the second scenario is worth > considering, i would point to the questions that (relatively) > frequently come from users about changing a running JACK system to use > another h/w interface, or to start/stop JACK temporarily for some > reason. there is one school of opinion that would say that "stop jackd > and restart it with the correct parameters" is the correct approach to > this question. i think that at LAC2008 it was felt that we could do > better. I confirm this it true (except about LAC2008 because i was not there and i dont know). And i want to add that qjackctl can be made more flexible if it can detect jackdbus. -- Nedko Arnaudov pgppeQ0Q0FWOQ.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 12:10:45PM -0400, Paul Davis wrote: > 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, *** It already does not work anymore. *** I have the impression that you are missing part of the picture. Jack-dbus is not just an (optional) server using the C API and providing access to it via dbus. I don not know what exactly is happening but it interferes even if clients are just using the C API. And it breaks it. If it were just an optional interface that e.g. an app such as qjackct could use to 'enhance the user experience' that would be perfectly fine for me. I would just not use it. It would also mean that jackd and libjack stay just the same, they don't have to know they are being controlled via dbus. But the current implementation imposes itself, even if clients are just trying to use the C API. And currently, maybe because of a bug, or by design, it breaks the C API. There is IMHO *no* reason why jack-dbus should **intercept** C API calls, start its daemon, and take control. As long as no client is accessing jack via dbus, it should just not be there. Those clients that want to use dbus can apparently launch the server just by trying to talk to it. 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 Mon, May 18, 2009 at 12:34 PM, Fons Adriaensen wrote: > > Jack-dbus is not just an (optional) server using > the C API and providing access to it via dbus. > > I don not know what exactly is happening but it > interferes even if clients are just using the > C API. And it breaks it. as far as we can tell, this is true *only* for the auto-start situation, and that is because of the substantive difference that i outlined in a previous message about what "auto-start" means in two different run-time environments. and it showed up for you, as best as can be determined, because of packaging/build issues that we hope have been fixed. everyone involved (i think) agrees that the current way this has to come to be (a dbus-specific version of libjack) is not the right solution. we are discussing ways to fix this on #jack at present. ___ 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 Monday 18 May 2009 17:57:39 Nedko Arnaudov wrote: > Fons Adriaensen writes: > > 1. Dbus is just a communication layer. > > 2. Dbus adds functionality that can't be > >provided via the normal interfaces. > > Both can't be true at the same time. > they are both false but even if they were true they can be both true, > according to my understanding of logic :D if A and B are not corelated > then A and B can be true at the same time. You are missing the "just" which makes them correlated and means that either dbus (at least its usage in jack) can't add functionality or it is not a plain communication layer but more. Here in this thread of the discussion 1 and 2 are contradictionary and really can't be true at the same time. If you don't understand this, you don't understand logic. (a=>b) Arnold 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
On Monday 18 May 2009 12:34:41 Fons Adriaensen wrote: > On Mon, May 18, 2009 at 12:10:45PM -0400, Paul Davis wrote: > > 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, > > *** It already does not work anymore. *** > > I have the impression that you are missing part > of the picture. > > Jack-dbus is not just an (optional) server using > the C API and providing access to it via dbus. > > I don not know what exactly is happening but it > interferes even if clients are just using the > C API. And it breaks it. > > If it were just an optional interface that e.g. > an app such as qjackct could use to 'enhance the > user experience' that would be perfectly fine for > me. I would just not use it. It would also mean > that jackd and libjack stay just the same, they > don't have to know they are being controlled via > dbus. > > But the current implementation imposes itself, > even if clients are just trying to use the C API. > And currently, maybe because of a bug, or by > design, it breaks the C API. > > There is IMHO *no* reason why jack-dbus should > **intercept** C API calls, start its daemon, > and take control. As long as no client is > accessing jack via dbus, it should just not > be there. Those clients that want to use dbus > can apparently launch the server just by trying > to talk to it. Fons, are you able to make a screencast movie of what is going on with your system and post it? After reading this last round, things are even less clear and such an effort may help make things plain. > > > 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] more jack/qjackctl madness : some comments
On Monday 18 May 2009 12:50:50 Paul Davis wrote: > On Mon, May 18, 2009 at 12:34 PM, Fons Adriaensen wrote: > > Jack-dbus is not just an (optional) server using > > the C API and providing access to it via dbus. > > > > I don not know what exactly is happening but it > > interferes even if clients are just using the > > C API. And it breaks it. > > as far as we can tell, this is true *only* for the auto-start > situation, and that is because of the substantive difference that i > outlined in a previous message about what "auto-start" means in two > different run-time environments. and it showed up for you, as best as > can be determined, because of packaging/build issues that we hope have > been fixed. So perhaps the problem is that Fons is getting an autostart from somewhere, he knows not where, that he doesn't know how to disable? If there is a simple way to disable jack autostart on his system, can someone clue him in and see if it solves his problems for now? > > everyone involved (i think) agrees that the current way this has to > come to be (a dbus-specific version of libjack) is not the right > solution. we are discussing ways to fix this on #jack at present. 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] more jack/qjackctl madness : some comments
Fons Adriaensen wrote: > There is IMHO *no* reason why jack-dbus should > **intercept** C API calls, start its daemon, > and take control. Hmm? libjack from non-DBUS package detects if JACK server is running, if not, it starts the server by doing fork&exec. libjack from DBUS package detects if JACK server is running, if not, it starts the server by telling DBUS server to do fork&exec. I don't see the problem, let alone OMG INTERCEPTING C API CALLS!!11! or eating babies. It may be harder to notice that the libjack-using application has just started the JACK server because the server's output goes to a log file and not stdout, but some people actually like it that way (especially when used with tools like laditray). I'm not saying DBUS version should be used by everyone, or that the currently available set of tools can be safely used by general public. On the other hand, I'm not buying into any anti-DBUS hysteria, because the "JACK server as a background service and not stdout-spamming application forked out from random client process" makes a lot of sense to me. 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] more jack/qjackctl madness : some comments
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. 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 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 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 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 writes: > On Tue, May 19, 2009 at 10:03:28AM +0300, Nedko Arnaudov wrote: > >> Fons Adriaensen 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 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 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 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] more jack/qjackctl madness : some comments
Quoting "Fons Adriaensen" : > I would have no objection if you added e.g. > >jack_client_open_via_dbus() How is the application supposed to know whether the user wants to use dbus or not? > leaving the original call as it is. I agree with Stephanes' 5): An implementation where dbus and "classic" coexist in a single build is the only way to go. The user environment would somehow tell jack whether the user wants to use dbus or not. (In fact, I'd argue this path should've been chosen from the start.) Say for example "the file ~/.jack-classic exists" or "environment variable JACK_COMMUNICATION=DBUS". Or a system wide configuration: "/etc/jackd/configuration says OSC is enabled". I agree with Nedko that this is not a change in the API. This is a change in the implementation of the API. There's a huge difference as we all know. We would run into all kinds of trouble if we would make client software responsible for choosing the server communication model. Hence the implementation was changed, not the API... Is there anything really difficult here? Just make everyone live happily together. Sampo ___ 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
Le 19 mai 09 à 11:29, Sampo Savolainen a écrit : > Quoting "Fons Adriaensen" : > >> I would have no objection if you added e.g. >> >> jack_client_open_via_dbus() > > How is the application supposed to know whether the user wants to use > dbus or not? > >> leaving the original call as it is. > > I agree with Stephanes' 5): > > An implementation where dbus and "classic" coexist in a single build > is the only way to go. The user environment would somehow tell jack > whether the user wants to use dbus or not. (In fact, I'd argue this > path should've been chosen from the start.) > > Say for example "the file ~/.jack-classic exists" or "environment > variable JACK_COMMUNICATION=DBUS". Or a system wide configuration: > "/etc/jackd/configuration says OSC is enabled". > > I agree with Nedko that this is not a change in the API. This is a > change in the implementation of the API. There's a huge difference as > we all know. We would run into all kinds of trouble if we would make > client software responsible for choosing the server communication > model. Hence the implementation was changed, not the API... > > > Is there anything really difficult here? Just make everyone live > happily together. 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. 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] more jack/qjackctl madness : some comments
Stéphane Letz 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? -- Nedko Arnaudov pgpYAnOx1opu7.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
Nedko Arnaudov wrote: > Stéphane Letz 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 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] more jack/qjackctl madness : some comments
Patrick Shirkey writes: > Nedko Arnaudov wrote: >> Stéphane Letz 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. I'm not forcing the new paradigm to anybody. I dont want to force and i cant force because i dont maintain neither jack1 nor jack2. jackdbus was optional and alternative from day zero. it was configure option in the very first dbus.patch that was against jack1 codebase. Packagers force users. Or users force themself. Developers create software. They may give advice but they dont deploy to end user. At least in open source world. -- Nedko Arnaudov pgpvdk1giaWPk.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
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 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" 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 > ___ > 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] 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 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] 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 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 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 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 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 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 writes: > Nedko Arnaudov wrote: >> Ralf Mardorf 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 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 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 writes: > > >> Nedko Arnaudov wrote: >> >>> Ralf Mardorf 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 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 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
Nedko Arnaudov wrote: > [snip] Or you blame gnome folks about new KDE being crap? > > :) > :D I'm running KDE and GNOME and if there will be conflicts for KDE applications, because of GNOME packages, the blame for an odd KDE might be on GNOME and I blame Steinberg not to give a FLOSS Cubase for Linux or to support Ardour, Rosegraden, Muse, Qtractor by donations :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
On Tue, May 19, 2009 at 5:48 PM, Ralf Mardorf wrote: > 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 Quite off-topic, but I can't let this pass. Any release of Rosegarden made in the last decade can load sessions made with any other release -- even a later one -- and we're particularly careful to make sure files never break from one release to the next. (Bugs do happen, but we take this class of bug quite seriously.) Of course, if the session uses features that don't exist in the version you're loading it into, you won't get those features in your session and they'll be lost when you save it again. But that's to be expected. Rosegarden is better than most other software in this respect, open source or proprietary. Chris ___ 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. I find it hard to see how you actually understand Linux audio. I get the impression that you have almost tried but instead have persistently trolled on this point since you arrived. The above is a "full stop" of Ralfs dialog, I say this just in case there is a possible alternative that seems to make sense for a temporary period. Ralf. Please stop with your destabilising crap. - For reference : This must be the 50th time Ralf has been asked to stop dissing Linux Audio... Eventually someone from the mass media will see through his bs (and M$ fud). Until that time we are at his merciful prerogative to make Linux audio look like he and his cronies give a shit. I have to wonder tho, That if he is prepared to spend this much time dissing Linux audio, then his boosses must be really scared about the results as they are obviously well aware of how close we are to the existing sytem that has been devised by the "Geniuses" at ...(insert your favorite sound system here) Ralf. I would really love to hear a conclusive rebuttal from you.. After four years. (is it really that long?) I think we are owed a conclusive response. Patrick Shirkey Boost Hardware Ltd Ralf Mardorf wrote: > 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 > ___ 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 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 :-) 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, 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 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
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
You get me wrong. Patrick Shirkey wrote: > Ralf. > > I find it hard to see how you actually understand Linux audio. I get > the impression that you have almost tried but instead have > persistently trolled on this point since you arrived. > > The above is a "full stop" of Ralfs dialog, I say this just in case > there is a possible alternative that seems to make sense for a > temporary period. > > Ralf. > > Please stop with your destabilising crap. > > - For reference : This must be the 50th time Ralf has been asked to > stop dissing Linux Audio... > > Eventually someone from the mass media will see through his bs (and M$ > fud). Until that time we are at his merciful prerogative to make Linux > audio look like he and his cronies give a shit. I have to wonder tho, > That if he is prepared to spend this much time dissing Linux audio, > then his boosses must be really scared about the results as they are > obviously well aware of how close we are to the existing sytem that > has been devised by the "Geniuses" at ...(insert your favorite sound > system here) > Ralf. I would really love to hear a conclusive rebuttal from you.. > After four years. (is it really that long?) I think we are owed a > conclusive response. > > > Patrick Shirkey > Boost Hardware Ltd > > > > Ralf Mardorf wrote: >> 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 >> > -- ___ 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
