[PlanetCCRMA] The JACK Story

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Sun Nov 22 15:07:38 PST 2009


On Sun, 2009-11-22 at 11:09 +0000, David Ford wrote:
> Hi Guys
> In the middle of all this technical discussion can I add a plea from
> users of 'older hardware'? I'm running PCCRMA on a 2.6GH single core
> box and an IBM T23 1.13GH laptop, I wouldn't like to find that I can't
> use Jack any more - just as Jack has finally managed to overcome the
> Pulseaudio scourge and we are getting more and more applications with
> Jack connections.

No worries there, I think, either jack1 or jack2 should be happy. Jack2
can use multiple cores if the topology of the graph of apps allows it
and you have more than one core, otherwise it just uses one (there is
nothing special about it, it just spawns more threads and the os takes
care of juggling them between cores or in one. 

-- Fernando

> On 22/11/09 07:58, Orcan Ogetbil wrote: 
> > On Sun, Nov 22, 2009 at 12:37 AM, Fernando Lopez-Lezcano wrote:
> >   
> > > On Sat, 2009-11-21 at 23:20 -0500, Orcan Ogetbil wrote:
> > >     
> > > > On Sat, Nov 21, 2009 at 10:55 PM, Fernando Lopez-Lezcano wrote:
> > > >       
> > > > > On Sat, 2009-11-21 at 22:02 -0500, Orcan Ogetbil wrote:
> > > > >         
> > > > > > Would you like to have them parallelly installable? We can achieve
> > > > > > parallel installation via "alternatives".
> > > > > >           
> > > > > I'm not completely sure if that is possible. Keep in mind that all jack
> > > > > server and client _libraries_ need to be switched in and out (ie: it is
> > > > > not just a matter of switching the jackd binaries.
> > > > > 
> > > > >         
> > > > I am confident that we can handle it. Java, as a much bigger suite
> > > > with many libraries, does it. We will have to reside the actual
> > > > binaries+libraries in certain directories and alternatives will do its
> > > > magic with the symlinks.
> > > >       
> > > Ok, it would be worth trying. Having them both would be good. And the
> > > user can choose the default.
> > > 
> > > What is the default default? :-), the last one installed? Sorry, I'm not
> > > familiar with the alternatives system.
> > > 
> > >     
> > As far as I know, "alternatives" has a priority measure that you
> > specify in the %post of your package. I don't know which one should be
> > the default. I use both from time to time and I can't decide. I would
> > say whichever is more stable.
> > 
> >   
> > > The priority I'm talking about is the one jackd runs at so it is
> > > internal to jack. I change the default in the source code to match
> > > rtirq's tweaked priorities. Jackd does not look for it anywhere, you can
> > > change it from the command line or qjackctl but it would be best to have
> > > the best choice be automatic for the rt kernel, of course :-)
> > > 
> > >     
> > So, what would priority 60 do with Fedora's kernel? Sorry I'm rather
> > ignorant with kernel related stuff. I run your jack2 on Fedora's
> > kernel quite frequently. Although I haven't done anything other than
> > simple 3-4 track recording recently, I didn't have trouble with the
> > current setting.
> > 
> >   
> > > > (By the way, the current convention is to use that folder rather than
> > > > editing limits.conf.)
> > > >       
> > > Ah, I did not know that. I should change my current package to do that
> > > instead of adding to limits.conf (when did this start? fc11?)
> > > 
> > >     
> > I think it started with F-11 but I'm not sure. You don't need to do an
> > update just for this change. Maybe next time you update the package,
> > you can do it this way.
> > 
> >   
> > > Thanks for bringing this up! I'm all for jack2 moving to Fedora proper,
> > > the trick would be to figure out the jackd rt priority stuff so that it
> > > can run under both kernels with no tweaking on the part of the user. No
> > > answer to that yet.... :-(
> > > 
> > >     
> > Yeah, it would be cool if we can figure out a best way. By the way,
> > (maybe I should have said this in the beginning) I don't maintain
> > Fedora's jack and I hope the current maintainer will cooperate.
> > 
> > Cheers,
> > Orcan
> > 
> > _______________________________________________
> > PlanetCCRMA mailing list
> > PlanetCCRMA at ccrma.stanford.edu
> > http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
> >   
> _______________________________________________
> PlanetCCRMA mailing list
> PlanetCCRMA at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma



More information about the PlanetCCRMA mailing list