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] What are we talking about.
Stéphane Letz writes: > Packagers are then strongly recommended to prepare the "classic" or > the "D-Bus" JACK2. Dependancies have to be handled accordingly (Nedko > please clarify this point...) > The "mixed" target should *not be used* for packaging. > > (see http://trac.jackaudio.org/wiki/JackDbusPackaging) We have suggested packaging approach: http://trac.jackaudio.org/wiki/SuggestedPackagingApproach We can fix something if someone thinks it is not good. -- Nedko Arnaudov pgps9PhxqsdEa.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
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] What are we talking about. (Was: KILL DBUS)
Le 18 mai 09 à 16:35, Paul Davis a écrit : > On Mon, May 18, 2009 at 10:25 AM, MarcO'Chapeau > wrote: >> On Mon, 18 May 2009 17:36:11 +0400, alex stone >> wrote: >>> Marc, >>> hehe, and the waltz continues. So let's assume that pulse isn't >>> being >>> considered here as part of the dbus paradigm intent . >> >> Hi again. >> >> Ok, let's stop dancing then :) Let me try to explain that dbus here >> is not >> the center of what has changed in JACK2. > > i'm just going to trying to summarize even more from what Marc has > said. There are two issues that have become tangled up in this recent > email flurry. > > 1) the current D-Bus support can be mishandled by packagers and this > can lead to problems for some users > 2) the only actual implementation that uses the control API is based > on D-Bus, and this is not a source of happiness and cake for everyone. > > There is nothing stopping other implementations (pure C, OSC, python > etc) using the control API, but at this time, nothing else does. > Stephane has attempted to correct problem (1) in svn with warnings > etc. to packagers. > > --p Some more words about that: JACK2 SVN makes now clear what can be built: - "classic" JACK : this target compiles the "jackd" executable. This exe behaves exactly as JACK1 is behaving (beside possible bugs). This target is the *default* one (that is the one resulting from "./waf configure). This version is meant to be used with usual tools Qjackctl, Ardour... (to start the server)... and so on. - D-Bus JACK: this target compiles the "jackdbus" executable *only* (that is the "jackd" is not compiled anymore). This target is obtained using --dbus at configure time. This version is meant to be controled with D-Bus based control applications (Nedko please clarify this point...) - both targets can be mixed but a WARNING is issued at configure time; that is "./waf configure --dbus --classic" will compile both "jackd" and "jackdbus" executable. This is to be done only by people who know exactly what they are doing. Packagers are then strongly recommended to prepare the "classic" or the "D-Bus" JACK2. Dependancies have to be handled accordingly (Nedko please clarify this point...) The "mixed" target should *not be used* for packaging. (see http://trac.jackaudio.org/wiki/JackDbusPackaging) 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 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
Fons Adriaensen writes: > On Mon, May 18, 2009 at 03:14:08PM +0300, Nedko Arnaudov wrote: > >> The configuration file is stored in >> ~/.config/jack/conf.xml >> (location conforming to the XDG Base Directory Specification). > > Frankly I don't give a damn for that spec, or in fact > anything from that self-styled group of *** who have > apparently never in their lives seen a computer without > a running desktop, have no idea of how things are done > on a Unix-like system, are the source of all misery I've > been confronted with lately, and are slowly turning Linux > into something worse than Windows (I mean freedesktop.org). > > To start with, jackd is not a desktop app, and Unix/Linux > apps are traditionally configured using an ~/***rc file. To be honest I dont care about the location of the file. It is fine with me and I'm not going to advocate XDG, it is a fight between you and them. -- Nedko Arnaudov pgpHmP1YLVQUg.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : 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
On Mon, May 18, 2009 at 03:14:08PM +0300, Nedko Arnaudov wrote: > The configuration file is stored in > ~/.config/jack/conf.xml > (location conforming to the XDG Base Directory Specification). Frankly I don't give a damn for that spec, or in fact anything from that self-styled group of *** who have apparently never in their lives seen a computer without a running desktop, have no idea of how things are done on a Unix-like system, are the source of all misery I've been confronted with lately, and are slowly turning Linux into something worse than Windows (I mean freedesktop.org). To start with, jackd is not a desktop app, and Unix/Linux apps are traditionally configured using an ~/***rc file. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack_ringbuffer or port_buffer ?
Hi Hermann, On Mon, May 18, 2009 8:31 am, hermann meyer wrote: >> they are totally unrelated. > > do I get it right, so, if there is no other thread then the > process_callback involved in the midi data collection,then there is no > need to use the ringbuffer ? A ringbuffer is like an array that never ends. It's like a C++ std::vector<> or std::list<>. It's a container that you can use if you want a never-ending array where the memory is pre-allocated. The ringbuffer in jack could be used in any program, anywhere. Here is a Wikipedia article on the subject: http://en.wikipedia.org/wiki/Circular_buffer You would use a ringbuffer when you have an audio (real-time) thread that MUST NOT wait... but you need to share data with a GUI thread or some other thread that will do heavy processing. JACK does not require, nor does it even expect, that you will have a ringbuffer anywhere in your application... even if you have more than one thread. If you use an normal array/buffer for transferring data, that will be just fine as long as you have appropriate read/write controls. On the other hand, a port_buffer is just the interface you use from JACK to read/write data from/to the JACK bus. It is owned and operated by JACK, so you don't have to allocate it, nor worry about whether it's a ring buffer or some other kind of buffer. Hope this helps, Gabriel -- G a b r i e l M B e d d i n g f i e l d ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack_ringbuffer or port_buffer ?
Am Montag, den 18.05.2009, 09:32 -0400 schrieb Paul Davis: > On Mon, May 18, 2009 at 9:31 AM, hermann meyer wrote: > > > > do I get it right, so, if there is no other thread then the > > process_callback involved in the midi data collection,then there is no > > need to use the ringbuffer ? > > if you are using JACK MIDI, then there is no other thread and no > ringbuffer is needed. thats it,many thanks, Paul hermann ___ 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_ringbuffer or port_buffer ?
On Mon, May 18, 2009 at 9:31 AM, hermann meyer wrote: > > do I get it right, so, if there is no other thread then the > process_callback involved in the midi data collection,then there is no > need to use the ringbuffer ? if you are using JACK MIDI, then there is no other thread and no ringbuffer is needed. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack_ringbuffer or port_buffer ?
Am Montag, den 18.05.2009, 08:27 -0400 schrieb Paul Davis: > On Mon, May 18, 2009 at 3:52 AM, hermann meyer wrote: > > Hi all > > > > I have a question about the useage from the jack_ringbuffer for midi > > out_put. I'am unsure to use it or not ? Can someone tell me what is the > > advance when I use it, in relation to write direct to the port_buffer ? > > they are totally unrelated. > > the port buffer is where you read/write data that you wish to > collect/deliver to the rest of the JACK system. > > using a ringbuffer is an optional but useful approach when you need to > make the data read/written during the process callback available > to/generated by some other thread. do I get it right, so, if there is no other thread then the process_callback involved in the midi data collection,then there is no need to use the ringbuffer ? I talk about a audio2midi converter, it work nice with the jack_ringbuffer, and also nice with the direct use from the port_buffer. I try to figure out with on is best for this purpose, and didn't come to a result. I think, the ringbuffer must use more CPU and mem, but I can`t see it realy. So when I get you right, I have no need to use the ringbuffer here ? thanks hermann ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack_ringbuffer or port_buffer ?
On Mon, May 18, 2009 at 3:52 AM, hermann meyer wrote: > Hi all > > I have a question about the useage from the jack_ringbuffer for midi > out_put. I'am unsure to use it or not ? Can someone tell me what is the > advance when I use it, in relation to write direct to the port_buffer ? they are totally unrelated. the port buffer is where you read/write data that you wish to collect/deliver to the rest of the JACK system. using a ringbuffer is an optional but useful approach when you need to make the data read/written during the process callback available to/generated by some other thread. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
drew Roberts writes: > How does dbus know what parameters to start jack with? Where is that > configured? (Perhaps this will solve the issue, I don't recall this > information passing before my eyes in this thread so far.) jackbus reads the configuration file and then start jack server through the control API. The configuration file is stored in ~/.config/jack/conf.xml (location conforming to the XDG Base Directory Specification). -- Nedko Arnaudov pgpFeIBAMoToM.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
On Monday 18 May 2009 05:49:01 Jan Weil wrote: > If it is indeed a > compile time option, the design is flawed IMHO. Generally, the new > control API sounds like a good idea but why can't the new features be > exposed as new command line tools without dbus dependency per default? > So you want the dbus interface? Fine, just install jack-control-dbus or > whatever. > > Or am I not getting it? > > Jan I have asked similar questions with pretty much the same intent re the compile time issue twice now and don't recall seeing a response to either. Also, I have not seen anyone who is "championing" the dbus / pulse side of things explain what is happening to Fons. It almost seems like they are telling him he can't be seeing what he is reporting. So, dbus guys, how is it that dbus is (re)starting on qjackctl launch? (Fons, isn't that what you are saying?) And why is it starting a jackd with different parameters that are in the rc file and in the qjackctl setup config? How does dbus know what parameters to start jack with? Where is that configured? (Perhaps this will solve the issue, I don't recall this information passing before my eyes in this thread so far.) all the best, drew ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
Jan Weil writes: > On Mon, May 18, 2009 at 01:23:20PM +0400, alex stone wrote: >> Will we continue to have a Jack version minus the dbus infrastructure, >> once jack2 is released? > > As an uninvolved observer I am wondering why the dbus control interface, > if it is indeed only one of many potential interfaces using the c/c++ > API, is not packaged separately as an optional add-on. If it is indeed a > compile time option, the design is flawed IMHO. Generally, the new > control API sounds like a good idea but why can't the new features be > exposed as new command line tools without dbus dependency per default? > So you want the dbus interface? Fine, just install jack-control-dbus or > whatever. > > Or am I not getting it? You are getting it but obviously the one who has put those packages in the "respected" repository is not getting it. I've packaged jack2 in the way you've mentioned. Of course those are for specific distro (ubuntu) and not real packages but draft packages that i've made to simplify work of real packagers when they take the maintainership. -- Nedko Arnaudov pgpFt0RbxCSlK.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
alex stone writes: > So again, i'll ask the question. > > Will we continue to have a Jack version minus the dbus infrastructure, > once jack2 is released? > > Or are we destined to be dragged into a "compulsory" hybrid? > > I share Fon's concerns, and still don't understand why the dbus/pulse > momentum is taking precedence over what has been up to now, a great > audio solution for any user who wants to write and create music. > > I'm not a coder, but i'll ask the jack team, who i have a lot of > respect for, to take a step back and have another look at the bigger > picture again. Dbus may be a way into a partnership with Pulse, but > that implies a degree of compulsory requirement for the user. > > And i don't think answering with "So don't use it" is an answer if > there's a question over the persistence of Dbus and Pulse overriding > the users intent. > > Fon's description of "Big Brother" seems more applicable, and less > humorous, the more one thinks about this. > > Alex. > > p.s. I'm practical about software, so the Dbus "mantra" means nothing to me. There are three packaging scenarios described in http://trac.jackaudio.org/wiki/JackDbusPackaging This document is created packagers can choose how to package jack. The mixed setup is can easily lead to user frustration and this is explained. I personally use the mixed setup but i know how the whole mixed system behaves and I need to start jackd occasionally. I wouldn't recommend packaging mixed setup. In ubuntu packages I've created jackdbus is separate package. jackd is separate package too. They both implement jack server virtual package. Packagers must choose between classic jackd or dbus-only scenarios unless they want to cause pain to their users. Some more things I've implemented in the ubuntu packaging... Only dbus control apps depend on jackdbus package. qjackctl depends on jackd package. So if you install qjackctl but dont want (or dont know about) jackdbus you get no dbus. If you install lpatchage or laditools you get dbus setup. Users don't care about jackd vs jackdbus. They care about the frontends. If they are used to qjackctl+jackd they will use that and will get no "dbus ate my babies" feeling. If they like ladi control apps, they will not use jackd. -- Nedko Arnaudov pgp0X7wVkPLf9.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
On Mon, May 18, 2009 at 01:23:20PM +0400, alex stone wrote: > Will we continue to have a Jack version minus the dbus infrastructure, > once jack2 is released? As an uninvolved observer I am wondering why the dbus control interface, if it is indeed only one of many potential interfaces using the c/c++ API, is not packaged separately as an optional add-on. If it is indeed a compile time option, the design is flawed IMHO. Generally, the new control API sounds like a good idea but why can't the new features be exposed as new command line tools without dbus dependency per default? So you want the dbus interface? Fine, just install jack-control-dbus or whatever. Or am I not getting it? Jan ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
So again, i'll ask the question. Will we continue to have a Jack version minus the dbus infrastructure, once jack2 is released? Or are we destined to be dragged into a "compulsory" hybrid? I share Fon's concerns, and still don't understand why the dbus/pulse momentum is taking precedence over what has been up to now, a great audio solution for any user who wants to write and create music. I'm not a coder, but i'll ask the jack team, who i have a lot of respect for, to take a step back and have another look at the bigger picture again. Dbus may be a way into a partnership with Pulse, but that implies a degree of compulsory requirement for the user. And i don't think answering with "So don't use it" is an answer if there's a question over the persistence of Dbus and Pulse overriding the users intent. Fon's description of "Big Brother" seems more applicable, and less humorous, the more one thinks about this. Alex. p.s. I'm practical about software, so the Dbus "mantra" means nothing to me. On Mon, May 18, 2009 at 12:10 PM, Nedko Arnaudov wrote: > Fons Adriaensen writes: > >> On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane Letz wrote: >> >>> I really appreciate your feedback..., but AFAICS Qjackctl is *absolutely* >>> not using the DBUS layer! >> >> Then please tell what this is: (ps -ef output) >> >> fons 2444 1 0 10:43 ? 00:00:00 /usr/bin/jackdbus auto >> >> Killing this makes qjackctl behave normally again, >> and allows me to start the server configured in it >> Setup window instead of getting a different one. > > Presence of jackbus process does not mean that jack server is > started. It means that jack server may or may not be started. jackdbus > service is there to allow in future creation of multiple jack servers. > > the easiest way to check whether jack server is started by jackdbus > service is: > > jack_control status > > -- > Nedko Arnaudov > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > > -- Parchment Studios (It started as a joke...) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness : 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
Fons Adriaensen writes: > On Sun, May 17, 2009 at 09:36:12AM +0200, Stéphane Letz wrote: > >> I really appreciate your feedback..., but AFAICS Qjackctl is *absolutely* >> not using the DBUS layer! > > Then please tell what this is: (ps -ef output) > > fons 2444 1 0 10:43 ?00:00:00 /usr/bin/jackdbus auto > > Killing this makes qjackctl behave normally again, > and allows me to start the server configured in it > Setup window instead of getting a different one. Presence of jackbus process does not mean that jack server is started. It means that jack server may or may not be started. jackdbus service is there to allow in future creation of multiple jack servers. the easiest way to check whether jack server is started by jackdbus service is: jack_control status -- Nedko Arnaudov pgpKR5tgRqVyY.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] more jack/qjackctl madness
"MarcO'Chapeau" writes: > On Sun, 17 May 2009 13:11:23 +0200, Fons Adriaensen > wrote: >> The only argument pro using dbus I'v heard so far >> is that it permits run-time discovery of new backends, >> internal clients and their parameters. > > That's unfair. Read the archives. There are more arguments to that. All features that jackdbus offers can be added without dbus. Using dbus was and still is the best way. It will be the best until there is better reusable model invented. Or if someone donates (development time) to implement such object model. Most important thing missing in jackd is the log file. Then you have other missing features: * no way several app to control single jack server. One needs to adopt it. * no runtime discovery of jack settings * no hierarchical settings file * complex patchbay API that results in complicated code in patchbay apps * multithread (for jack1 realtime too) threading model. (GUI) control patchbay app should be allowed to be single threaded and not required to handle graph change events in a realtime context. >> Dbus assumes there is a local login, without that >> there is no session bus, and things don't work. >> Most of my audio machines are headless, there is >> no local login, but I still expect things to work, >> and that, IMHO, is not unreasonable. > > It is not unreasonable. No one said you *had* to use dbus. This needs > fixing and until it is fixed, packagers should be advised to disable dbus. ATM headless and multiserver setups are not covered by jackdbus. This *can* be fixed with dbus model. Packagers tha have made the packages should have read this before enabling dbus: http://trac.jackaudio.org/wiki/JackDbusPackaging Maybe they did. I dont see why you Fons are attacking jackdbus because of packaging not matching your needs. -- Nedko Arnaudov pgpe49UcKihQf.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] jack_ringbuffer or port_buffer ?
Hi all I have a question about the useage from the jack_ringbuffer for midi out_put. I'am unsure to use it or not ? Can someone tell me what is the advance when I use it, in relation to write direct to the port_buffer ? In witch case do you prefer the ringbuffer, in witch case do you prefer the direct use of the port_buffer ? Witch one is the one with lesser useage from CPU and mem ? I try to figure that out, but I didn`t come to a clear result witch one is the one to use. regards hermann ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
