[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: <https://cm-mail.stanford.edu/pipermail/planetccrma/attachments/20091128/21e1e174/attachment.html>
More information about the PlanetCCRMA
mailing list