Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, 2009-05-19 at 21:41 +0200, Fons Adriaensen wrote: > On Tue, May 19, 2009 at 08:28:21PM +0100, Bob Ham wrote: > > > > Scroll back 100 messages, read everything and maybe > > > you will grok it :-) > > > > I was reading through the thread when I encountered your fiction. It's > > the previous messages that brought me to the conclusion I came to about > > the point of the fiction. I was evidently wrong and I don't understand > > what the point actually was. > > Denial. The parrot is not dead. It's just a little bit tired. > Heh, yeah I get that analogy :-) I can see where you were going with the fiction now, too. signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] 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, May 19, 2009 at 08:28:21PM +0100, Bob Ham wrote: > > Scroll back 100 messages, read everything and maybe > > you will grok it :-) > > I was reading through the thread when I encountered your fiction. It's > the previous messages that brought me to the conclusion I came to about > the point of the fiction. I was evidently wrong and I don't understand > what the point actually was. Denial. The parrot is not dead. It's just a little bit tired. -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : some comments
On Tue, 2009-05-19 at 21: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 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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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: > 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
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
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
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
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
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
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
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
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 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 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 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 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 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 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
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 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 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 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
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
"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
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
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 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
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
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 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
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
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 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
"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
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
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
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
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 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
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 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 à 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 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
