Bug 542288

Regarding the use of alternatives: IIUC how jack works, alternatives is the wrong approach.  It takes an end user decision and gives it to the system administrator.  Use envirnment-modules instead.  http://fedoraproject.org/wiki/PackagingDrafts/EnvironmentModules

(In reply to comment #1)
> Regarding the use of alternatives: IIUC how jack works, alternatives is the
> wrong approach.  It takes an end user decision and gives it to the system
> administrator.  Use envirnment-modules instead. 

So? (Are you aware of the context? End user = administrator in this case. We don't need to consider other multi user scenarios. Or am I missing something?)

About PRIORITIES:

Source patching for a runtime configuration parameter is messy and difficult to
mantain, especially when there are perfectly usable configuration files. The
following examples assume a desired jackd priority of 60.

You can add to the jack package a /etc/jackdrc file with the following content:

/usr/bin/jackd -R -P60

You can add to the qjackctl package a /etc/rncbc.org/QjackCtl.conf file with
the following content:

[Settings]
Priority=60

You can use the same priority values for ccrma and normal kernels if you modify
the rtirq script so it lowers the non-audio kernel threads below the maximum
permitted by /etc/security/limits[.conf|.d]

It would be nice if the jackd package allowed a bit more headroom to sort out
the priorities of the IRQ handlers by elevating the maximum priority for the
jack group, always below the kernel default of 50, of course. Isn't 49 just as
safe as 20?

(In reply to comment #2)
> (In reply to comment #1)
> > Regarding the use of alternatives: IIUC how jack works, alternatives is the
> > wrong approach.  It takes an end user decision and gives it to the system
> > administrator.  Use envirnment-modules instead. 
> 
> So? (Are you aware of the context? End user = administrator in this case. We
> don't need to consider other multi user scenarios. Or am I missing something?)  

I'm not sure if I do or not.  Why do you want to have the ability to install both jack1 and jack2 in parallel on the system?

(In reply to comment #4)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Regarding the use of alternatives: IIUC how jack works, alternatives is the
> > > wrong approach.  It takes an end user decision and gives it to the system
> > > administrator.  Use envirnment-modules instead. 
> > 
> > So? (Are you aware of the context? End user = administrator in this case. We
> > don't need to consider other multi user scenarios. Or am I missing something?)  
> 
> I'm not sure if I do or not.  Why do you want to have the ability to install
> both jack1 and jack2 in parallel on the system?  

Both are different implementations of the same jack API. They do not (yet) exactly match in capabilities. 

Eventually jack2 will be version 2.0 of jack and both will converge. In the meantime it would be good to be able to choose which one to use (currently Fedora uses 0.x, Planet CCRMA uses 1.9.x), there are a few cases (max number of ports is the one that comes to mind) where jack1 might be better.

(In reply to comment #3)
> About PRIORITIES:
> 
> Source patching for a runtime configuration parameter is messy and difficult to
> mantain, especially when there are perfectly usable configuration files. 

I agree, it is not a good solution - I hesitate going this way. But it is dynamic and fixes the problem. It is the first proposal that does not involve changing current Fedora rt priority policy which would probably be difficult. 

> The following examples assume a desired jackd priority of 60.
> 
> You can add to the jack package a /etc/jackdrc file with the following content:
> 
> /usr/bin/jackd -R -P60

Would this be overriden by the command line?

> You can add to the qjackctl package a /etc/rncbc.org/QjackCtl.conf file with
> the following content:
> 
> [Settings]
> Priority=60

That one would not work as it would work only in qjackctl (and not in a command line invocation of jackd). 

Furthermore both solutions are static. They do not address the (_currently_, see below) nature of the problem in that the optimum priority for jackd depends on the kernel that is running and how its interrupts have been optimized. 

> You can use the same priority values for ccrma and normal kernels if you modify
> the rtirq script so it lowers the non-audio kernel threads below the maximum
> permitted by /etc/security/limits[.conf|.d]

Yes, I suggested that in a post within the thread quoted above in the Planet CCRMA list:

http://ccrma-mail.stanford.edu/pipermail/planetccrma/2009-November/016161.html

I'd suggest you read that post in detail. I explain the current situation with a few suggestions on how to address the current incompatibility. 

> It would be nice if the jackd package allowed a bit more headroom to sort out
> the priorities of the IRQ handlers by elevating the maximum priority for the
> jack group, always below the kernel default of 50, of course. Isn't 49 just as
> safe as 20?  

Correct. AFAIK there is no particular reason for choosing 20. Fedora chose 20, I chose a higher priority to match rtirq's handling of interrupts (and that happened before Fedora started doing that). One is not more secure than the other. 

But it is not correct that jackd's priority should always be below the kernel default of 50 in rt kernels. 

Fedora kernels have only a few rt critical processes and they run with rt priority 99. In a Fedora 11 install I see two processes per cpu, one called "migration" and another called "watchdog", I presume they are meant for process migration between cpus and detection of lockouts but that is just a guess. 

Neither of those processes should be touched and they should not impact jackd's performance. 

In (Planet CCRMA) rt patched kernels, in addition to the "migration" and "watchdog" processes (outside of the scope of this thread) there is another one per cpu, "posixcputmr", also running at priority 99. Below those come all irq processes ("irq/*") which run at priority 50, and below those come all software interrupt processes ("sirq-*") running at priority 49. At the very bottom of the priority ladder are four (I have a 4 core machine, I presume it is one per core) "events" threads running at rt priority 1. 

Where should jackd fit in this rt enabled picture? In a nutshell, the irq process that corresponds to the soundcard should have higher priority than all other irq processes. Jackd's rt threads should have a priority lower than the priority of the irq process that handles the soundcard interrupt _but_ higher than all other processes that handle irq's. So, the soundcard has the highest priority, jackd, which is driven by those interrupts, is next, and after that comes everything else (the optimization done by rtirq is more complicated than that, this is just the essential stuff). 

I agree that 20 is a bit too low to acommodate all desired levels. 

Let's see:

Anything in the rt kernel that runs at 99 should still run at 99. 
Irq's that are not soundcard related should be moved, say:
  50 --> 10
Software interrupts should also be moved:
  49 --> 9
Interrupts related to the soundcard should go higher:
  sound irqs 50 --> 15?
Jackd would be somewhere in between 10 and 15:
  jackd rt threads 10 --> 12?
Anything in the kernel running at 1 should still run at 1

It is not as simple as this would suggest as rtirq also needs a few more priority levels, and you can order priorities further (it decrements or increments priority when allocating them, I'd need to read the script to remember what happens). 

Further caveats:

Some software packages do run at rt priorities that are very low, for example some threads in the Pd (Pure Data) graphical should programming environment run at 2 or 3, I think. So we should not be touching, say, below 5.

Some software also runs rt threads that are related to jackd's rt priority, an example is jconv (a real-time oriented partitioned convolution program, very nice for convolution reverb) - I don't remember the algorithm for determining priorities in that case. 

A bit more headroom than just 20 would be better.

(In reply to comment #0)
> 3- In case we keep the names as in the above links, PlanetCCRMA's package needs
> to be Fedorized. It won't pass the review this way. 

No kidding... :-)

> From what I understand, the
> same specfile is used to build both jack1 and jack2 packages. 

That is correct. 

> This won't be necessary in Fedora.

The spec file (ugly as it is) also enables the packager to package either svn or the latest release. Maybe that could be kept. I have found it necessary to switch back and forth as important bugs crop up that are solved in svn (happened recently in jack2 1.9.3). 

> 6- DBUS: Jack2 package has some dbus related file, jack1 doesn't. I don't know
> what it does.

There is a dbus switch in the spec file. It is off by default as the behavior of a dbus enabled jackd is different and non-backwards compatible (and it is not set in stone that this will be the way the dbus functionality is implemented). If there are binaries still being generated that depend on dbus then there is a bug in the source itself or in the spec file. 

> 7- libffado: This package is not yet in Fedora. It has been under review for a
> while in bug 456353. Jack2 package has a BR on this. But it can be compiled
> without it. I don't know what functionality libffado will add. Jack1 doesn't
> need it.

Jack1 also needs it, it is just not used in the current Fedora package (it is used in Planet CCRMA jack1's packages). 

The libffado package enables the building of a jackd backend that can use firewire soundcards (if you are running audio on a laptop you have very few options for high quality multichannel audio i/o, either very expensive RME PCMCIA - or express - slot cards or firewire). Libffado should be part of Fedora if jack2 wants to move to Fedora. 

BUT:

Firewire support for soundcards was broken by Fedora's change of firewire stack in Fedora 7 and, AFAIK, has not been fixed yet. I think current (or very recent) kernels enable building with both stacks, and the userland libraries can handle both (very recently also). So it _may_ be possible to fix this now (after five releases). But most probably there is nobody around that needs this any more - what would you do if a distro bricks a perfectly working class of devices and never fixes them? (with the best of intentions, of course, but bricks them nevertheless)

I currently ship my Planet CCRMA rt kernels with the older stack so that any remaining audio users that need firewire and have not migrated to less advanced distributions can still use them :-)

Is the requirement for more ports something that the end user needs (as in, I want to run more applications/inputs/outputs/? so I need more ports) or something that the system admin needs (as in, I need to allow jack to handle five users at the same time so I need more ports)?  From the little I know from playing around with replacing pulseaudio with jack on KDE once, it seems like jack is being chosen by the user.  So it seems like choosing jack1 vs jack2 is also something that needs to be decided by the user.

(In reply to comment #8)
> Is the requirement for more ports something that the end user needs (as in, I
> want to run more applications/inputs/outputs/? so I need more ports) or
> something that the system admin needs (as in, I need to allow jack to handle
> five users at the same time so I need more ports)?  From the little I know from
> playing around with replacing pulseaudio with jack on KDE once, it seems like
> jack is being chosen by the user. So it seems like choosing jack1 vs jack2 is
> also something that needs to be decided by the user.  

It can be argued both ways. 

I would prefer a system-wide selection of one or the other. 

A user level would also be nice but I'm not positive it would be doable from what I have read so far (not much, I admit). As far as I can tell the modules thing deals with environmental variables - jack has libraries that all clients use, the ones not in use have to be hidden. Do you have examples of things that can be switched per/user with that?

I don't have more examples right now of differences between jack1 and jack2, which would make this easier (the port stuff is how many ports can be opened by applications - it was hardwired at compile time in jack2 last time I checked, that might have changed by now).

Since Jack installs shared libraries in libdir, there are two ways of dealing with this.

1- put the shared library somewhere else and make a symlink in libdir.
2- put the shared library somewhere else and add the new path to LD_LIBRARY_PATH.

alternatives takes route 1 and environment modules takes route 2. I think for the current situation route 1 is the cleaner solution.

Given the fact that jack users who would want to have both jacks installed simultaneously are mostly audio production folks, they will be plugging in and out their music devices into the computer, they will usually need admin access anyway. Obviously, this approach aims "user=admin" systems, which, as I said, makes sense. I can't imagine a scenario where someone will do audio production in a public computer where the sysadmin is not around. Am I wrong?

> Would this be overriden by the command line?
> 
> That one would not work as it would work only in qjackctl (and not in a command
> line invocation of jackd). 
> 

Of course! But I assume we are talking about facilitating the out-of-the-box experience for the average users. Anyone who fiddles with the command line can override _anything_, including the default priority supplied by the patch. I think it is a reasonable assumption that such a user should know what he is doing and wouldn't need any changes to the package as it is now, since he should be capable of tuning up the priorities in his system.

The only advantage of the patch is that it allows you to omit the -Pnn option in the invocation and that it adapts to the kernel, but you sign up for a lifetime of patch maintenance.

If you want to make my proposal dynamic it would be very easy to select a different set of rc files on startup by adding a init service script that would adjust symbolic links to them (or adding this functionality to rtirq).

You would need to add the following files to a package:

/etc/jackdrc.rt
/etc/jackdrc.nonrt
/etc/rncbc.org/QjackCtl.conf.rt
/etc/rncbc.org/QjackCtl.conf.nonrt
/etc/init.d/adjust-jack-rcs-at-boottime-or-wadchawannacallit

> Furthermore both solutions are static. They do not address the (_currently_,
> see below) nature of the problem in that the optimum priority for jackd depends
> on the kernel that is running and how its interrupts have been optimized. 
> 

But that's what I am pointing at, and why I suggested a static solution: same priorities regardless of kernel via modification of rtirq.

> But it is not correct that jackd's priority should always be below the kernel
> default of 50 in rt kernels. 

Yes if we lower down the non-audio irqs on rt kernels by changing rtirq.

> Jackd would be somewhere in between 10 and 15:
>   jackd rt threads 10 --> 12?

That's what I was suggesting, only not in such detail.

(In reply to comment #11)
> > Would this be overriden by the command line?
> > 
> > That one would not work as it would work only in qjackctl (and not in a command
> > line invocation of jackd). 
> > 
> 
> Of course! But I assume we are talking about facilitating the out-of-the-box
> experience for the average users. 

What about other applications which start jackd by themselves (there are a lot of them)?

> What about other applications which start jackd by themselves (there are a lot
> of them)?  

Quoted from http://linux.die.net/man/1/jackd

====

Environment
JACK is evolving a mechanism for automatically starting the server when needed. Any client started without a running JACK server will attempt to start one itself using the command line found in the first line of $HOME/.jackdrc if it exists, or /etc/jackdrc if it does not. If neither file exists, a built-in default command will be used, including the -T flag, which causes the server to shut down when all clients have exited.

====

I don't know about those apps, to be honest. Which ones? How do they do it?

If an application uses a different command line to start jackd, the only way the patch will help is if the line includes -R _and_ not -P.

(In reply to comment #9)
> A user level would also be nice but I'm not positive it would be doable from
> what I have read so far (not much, I admit). As far as I can tell the modules
> thing deals with environmental variables - jack has libraries that all clients
> use, the ones not in use have to be hidden. Do you have examples of things that
> can be switched per/user with that?
> 
See Orcan's comment for the overview.

(In reply to comment #10)
> Given the fact that jack users who would want to have both jacks installed
> simultaneously are mostly audio production folks, they will be plugging in and
> out their music devices into the computer, they will usually need admin access
> anyway. Obviously, this approach aims "user=admin" systems, which, as I said,
> makes sense. I can't imagine a scenario where someone will do audio production
> in a public computer where the sysadmin is not around. Am I wrong?  

Yes.  We're building a unix-like OS.  So we should never build something that requires the user=admin when we can do better.  AFAICS, that is the case here.  We have environment-modules.  It will deal with the problem at hand and allow the user to make the choice just as they should be able to make the choice between jack1 and pulseaudio without requiring sysadmin intervention.

(In reply to comment #14)
> (In reply to comment #9)
> > I can't imagine a scenario where someone will do audio production
> > in a public computer where the sysadmin is not around. Am I wrong?  
> 
> Yes. 

One of us is missing something. Are you seriously suggesting to change the Fedora Linux distribution's default LD_LIBRARY_PATH environment variable from NULL to something non-NULL?

Well, I am fine with that but I am not sure everybody will like it.

Default no.  When used to enable an alternative implementation via environment-modules yes.

(In reply to comment #16)
> Default no.  When used to enable an alternative implementation via
> environment-modules yes.  

That means we want to install one of the libjack.so.0 to LIBDIR directly and the other libjack.so.0 will be somewhere else and it will be called when environment modules changes LD_LIBRARY_PATH.

Then how will we handle those software which call /usr/bin/jackd directly, or dlopen stuff from /usr/lib/jack/ ? Can environment variables deal with those?

> Then how will we handle those software which call /usr/bin/jackd directly, or
> dlopen stuff from /usr/lib/jack/ ? Can environment variables deal with those?  


The first case would be easily handled substituting /usr/bin/jackd for a script that launched the alternate depending on an environment variable. But I don't see how modules would handle the second case, if developers are not instructed to use the contents of an EV before resorting to that harcoded path, which I don't think they are.

Out of curiosity, why would an application dlopen jack instead of linking dynamically to it at build time? Can you cite an example?

Can you cite an example of software that starts jackd not using the jackdrc mechanism, unless it is _explicitly_ configured to do so? I guess the sensible bahaviour for any jack client would be:

1) jackd is already running. Hook up.
2) ONLY IF an alternate command line has been explicitly specified by the user to override jackdrc, try it. This should never be the default behavior at install time, since it makes the maintenance of this software a non-centralized mess.
3) use jackdrc.
4) as a last resort use a custom jackd command.

I see the use of per-application jackd commands for power users that, for instance, want to trade-off stability for latency depending on the application, but those users should know what they are getting into and there's little a packager can do to help them, since by default they will not be happy with any single default configuration.

Perhaps this is best taken to LAD where more diverse and knowledgeable eyes can help find the best solution.

(In reply to comment #18)
> > Then how will we handle those software which call /usr/bin/jackd directly, or
> > dlopen stuff from /usr/lib/jack/ ? Can environment variables deal with those?  
> 
> 
> The first case would be easily handled substituting /usr/bin/jackd for a script
> that launched the alternate depending on an environment variable. But I don't
> see how modules would handle the second case, if developers are not instructed
> to use the contents of an EV before resorting to that harcoded path, which I
> don't think they are.
> 
> Out of curiosity, why would an application dlopen jack instead of linking
> dynamically to it at build time? Can you cite an example?

I don't know the innards of jack programs (or at least most of them) so I don't know if any do that. 

Just using environment variables does not seem like a good technical solution to the problem at hand. A user switches jacks from a terminal. Starts jack from qjackctl (menu item). Then starts a program from the terminal that was used to switch jack. Both instances will not see the same content for the same environmental variables, right? One uses jack1 and the other jack2. The user did nothing "wrong". 

Does _any_ other piece of software in the Fedora landscape other than LAM (a "local multicomputer programming environment") use this method of controlling application behavior?

> Can you cite an example of software that starts jackd not using the jackdrc
> mechanism, unless it is _explicitly_ configured to do so? I guess the sensible
> bahaviour for any jack client would be:
> 
> 1) jackd is already running. Hook up.
> 2) ONLY IF an alternate command line has been explicitly specified by the user
> to override jackdrc, try it. This should never be the default behavior at
> install time, since it makes the maintenance of this software a non-centralized
> mess.
> 3) use jackdrc.
> 4) as a last resort use a custom jackd command.
> 
> I see the use of per-application jackd commands for power users that, for
> instance, want to trade-off stability for latency depending on the application,
> but those users should know what they are getting into and there's little a
> packager can do to help them, since by default they will not be happy with any
> single default configuration.
> 
> Perhaps this is best taken to LAD where more diverse and knowledgeable eyes can
> help find the best solution.  

Perhaps that would be best. 

Another piece for the puzzle. This is not a new problem. An effort to solve this happened about 2 years ago (at my request mostly) to include this functionality into jack itself. Jack2's developer Stephane Letz developed a method to be included in jack2 whereas it would be able to switch to jack1 libraries or not. I don't remember the _exact_ way in which this was done but it involved a stub library that would transfer control to the real selected one. It did not work. Apparently it did, but some existing software was quite unhappy (unpredictable) with very weird results. So this was dropped (no point in wasting resources for a dead end problem). 

Anything that involves handling libraries through env variables can potentially fail, I think (corner cases? buggy software? I don't really care why). So I'd be wary of using such methods. 

BTW, a solution exists for the original goal of installing both jack1 and jack2 at the same time (alternatives). The original goal of installing both and being able to select at the sysadmin level which one to use has been elevated to a user level control. I think a sysadmin level control is good enough, others disagree and so we end up with nothing for the time being. 

(http://www.proz.com/kudoz/spanish_to_english/poetry_literature/2492113-lo_mejor_es_enemigo_de_lo_bueno.html :-)

Wouldn't using alternatives suffer from similar issues?  User starts up kde with jack1 as the sound server.  User uses alternatives to switch to the jack2 server.  User starts a new program or does something that attempts to dlopen a jack module.  Suddenly you have a mismatch between the running server and the new program/module.  Seems like the never fail advice in both cases is to run the alternatives or module initadd command, then logout and log back in again.

Note that with environment-modules, changing the module will only break the user that invokes it who doesn't know where to push environment modules.  With alternatives, it will break other users of the system who are logged in at the same time.  (For instance, if you've fast-user-switched to another user so they can do a little bit of audio production work while you're away, they switch from jack2 to jack1 for their work.  You come back and fast-user switch back.  Suddenly, your running applications aren't using the libraries that match the server).

As for other things using environment-modules; the guidelines for using it are relatively new.  Now that we have documented how to use environment-modules in packaging, we want to stop using alternatives in places that its unsuitable, ie places that makes sense for end-users to run rather than system admins and places where command-line/ABI/API compatibility is not present.  For instance, switching between MPI implementations was ported from alternatives to environment-modules a few months ago.

(In reply to comment #20)
> Wouldn't using alternatives suffer from similar issues?  User starts up kde
> with jack1 as the sound server.  User uses alternatives to switch to the jack2
> server.  User starts a new program or does something that attempts to dlopen a
> jack module.  Suddenly you have a mismatch between the running server and the
> new program/module.  Seems like the never fail advice in both cases is to run
> the alternatives or module initadd command, then logout and log back in again.

That's correct. 

> Note that with environment-modules, changing the module will only break the
> user that invokes it who doesn't know where to push environment modules.  With
> alternatives, it will break other users of the system who are logged in at the
> same time. 

In a jack based audio production environment that should not happen, see below. 

> (For instance, if you've fast-user-switched to another user so they
> can do a little bit of audio production work while you're away, they switch
> from jack2 to jack1 for their work. 

Using alternatives the sysadmin would do the switch, in a multiuser environment such as the one you describe normal users would not be able to switch back and forth. 

> You come back and fast-user switch back. 
> Suddenly, your running applications aren't using the libraries that match the
> server).

Jack does not work in those circumstances. It has to own the soundcard all the time (it is doing i/o from/to the card constantly). I don't think jack would survive switching users and losing contact with the card. 

> As for other things using environment-modules; the guidelines for using it are
> relatively new.  Now that we have documented how to use environment-modules in
> packaging, we want to stop using alternatives in places that its unsuitable, ie
> places that makes sense for end-users to run rather than system admins and
> places where command-line/ABI/API compatibility is not present.  For instance,
> switching between MPI implementations was ported from alternatives to
> environment-modules a few months ago.  

Thanks for the information, I assumed that somehow I was making a mistake when searching for other examples of packages that used it.

(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #9)
> > > I can't imagine a scenario where someone will do audio production
> > > in a public computer where the sysadmin is not around. Am I wrong?  
> > 
> > Yes. 
> 
> One of us is missing something. Are you seriously suggesting to change the
> Fedora Linux distribution's default LD_LIBRARY_PATH environment variable from
> NULL to something non-NULL?

What happens if something else changes LD_LIBRARY_PATH?

> Well, I am fine with that but I am not sure everybody will like it.

(In reply to comment #22)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > (In reply to comment #9)
> > > > I can't imagine a scenario where someone will do audio production
> > > > in a public computer where the sysadmin is not around. Am I wrong?  
> > > 
> > > Yes. 
> > 
> > One of us is missing something. Are you seriously suggesting to change the
> > Fedora Linux distribution's default LD_LIBRARY_PATH environment variable from
> > NULL to something non-NULL?
> 
> What happens if something else changes LD_LIBRARY_PATH?

Anything can change environment variables (user actions, other software packages, etc). If LD_LIBRARY_PATH is changed then jackd and/or its clients will not look up the libraries in the configured location. Jackd could revert to the default without the user having any say in the matter, and/or clients could stop working correctly when they load the wrong libraries. 

It looks to me like a very fragile foundation on which to build something that has to be dependable.

We really have more important things to do than getting this work without a root password. I, for one, haven't seen anybody in my entire life who brought all his studio equipment to make music in an internet cafe or in school's computer lab. 

Let's be realistic, shall we?

Unfortunately, I will be extremely busy in the following 2 weeks. And right after that, I will be away until mid-January. So all this time got wasted with trying to convince each other which method is better.

But we forgot one thing: A method is better than no method. I already did some work and came up with one method. If you folks (who defend the environmental modules) spent as much time with implementing your ideas, as you spent writing here in this thread, we would have had a nicer method than mine by now.

I usually don't engage in internet pissing contests, but since you are the second person in this thread throwing uncalled for snide remarks, instead of just bailing out of the discussion, as I had first decided to do after Nando's comment, I feel compelled to clarify some general points.

1) I don't see anyone here trying to throw a spanner in the works, just offering alternatives for discussion in the search for a good solution. I don't see how that wastes anyone's valuable time since you are entirely free to ignore them.

2) Unless the official maintainer of the package gets involved, there is no guarantee that any actual work that is done will be of any use, since he is the one who has the final decision. I don't see how would we actually have anything by now. As a side note, if he doesn't have the time to actively maintain this package it would be nice if he relinquished it to people who can, like Orcan or Nando, if they are willing to take it.

As for my personal position about the alternatives issue, I frankly don't care about what method is used since I don't think I'll ever have both jackds installed, and if I'd ever wanted to switch between them it is very easy to just uninstall one and install the other. How's that for a solution that already works, needs no further discussion and doesn't waste anyone's valuable time? If we are going to be realistic, are we sure switching daemons will be a daily occurrence?

I just chimed in here because of the thread priority issue, which I personally find much more in need for a fix.

In any case, I don't see how taking some of those valuable time to insult and alienate people is of any help to anyone. I actually hadn't heard of env. modules before and, as a system administrator, I find it an interesting concept to ponder about, so I for one am grateful Toshio brought it up as a general alternative, even if it might not apply well to this case.

Thanks for all the good work you put in, guys.

(In reply to comment #25)
> I usually don't engage in internet pissing contests, but since you are the
> second person in this thread throwing uncalled for snide remarks, instead of
> just bailing out of the discussion, as I had first decided to do after Nando's
> comment

Sorry, I did not mean to offend anyone, if I did I apologize. 

[MUNCH]
> I just chimed in here because of the thread priority issue, which I personally
> find much more in need for a fix.

I agree. Maybe I/we should start another bug that is more specific? It is a compatibility problem between the vanilla kernel and the rt+rtirq low latency solution - I don't know how much it will resonate with regular Fedora users/maintainers as the problem is not inherent to Fedora itself. 

I have not had time to take a hard look at rtirq but any solution that adapts to Fedora's choice of upper usable priority would involve changing it as the current code (as far as I can remember) does not have an option for changing the priorities of the kernel threads it does not optimize.

This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I guess this bug could be closed now since we have jack-1.9.5 in place.