[PlanetCCRMA] The JACK Story

Michael Curtis lists at moltenmercury.org
Sat Nov 28 02:16:44 PST 2009


On 24/11/2009, at 6:26 PM, Fernando Lopez-Lezcano wrote:

> On Mon, 2009-11-23 at 18:33 -0800, Jonathan Ryshpan wrote:
> 
>> I'd advise not to try to get Fedora to change its policies, if you can
>> avoid it.  Such coordination is always trouble for both parties.
> 
> Maybe so. If a better jack makes it into Fedora it would be best that it
> could be made compatible with the rt kernel and rtirq. We'll see how it
> goes. 

Just weighing in with my 2c here.  It should be possible to patch jack to change the default priority at runtime based on the kernel it's running on.

Something like
#include <sys/utsname.h>

.....

{
  struct utsname utsname;
  int success;

  success = uname( &utsname );
  
  if( success == 0 && strstr( utsname.version, "ccrma" ) )
  {
    defaultPriority = 60;
  }
  else
  { 
    defaultPriority = 20;
  }
}

I'd would think this would be an easy patch to maintain as it would slot early into the options parser, which is probably something that is not changed frequently upstream. (note I made up the variable defaultPriority, so I have no idea if it's as easy as this in the Jack source, however I normally write a getopt parser by setting default values from compiled in options and then overriding them if an option is set, so if this is the case, it should be fairly straightforward).

I suspect Fedora may frown on such detection of kernel versions but in my opinion this would be a good solution - even if you are using CCRMA but (for security / stability reasons) using a stock (Fedora) kernel, Jack will automagically make the right default choice.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/planetccrma/attachments/20091128/21e1e174/attachment-0001.html 


More information about the PlanetCCRMA mailing list