[PlanetCCRMA] which Fedora?

[Fernando Lopez-Lezcano]

On 11/10/2010 11:41 AM, Orcan Ogetbil wrote:
> On Wed, Nov 10, 2010 at 2:27 PM, Fernando Lopez-Lezcano wrote:
>> On 11/10/2010 01:18 AM, Orcan Ogetbil wrote:
>>> On Tue, Nov 9, 2010 at 10:22 PM, Orcan Ogetbil wrote:
>>>> Ah... I remember I tested this on F-13 both with and without CCRMA
>>>> kernel and it worked fine (maybe I remember it wrong?)
>>> In the patch, I think I need to use utsname.release instead of
>>> utsname.version
>>> Could you send me the output of this program when you are running a
>>> ccrma rt kernel on F-14?
>>>
>>> #include<sys/utsname.h>
>>> #include<iostream>
>>> #include<string.h>
>>>
>>> using namespace std;
>>>
>>> int main()
>>> {
>>>    struct utsname utsname;
>>>    int success = uname(&utsname );
>>>    cout<<    "utsname.sysname:"<<    utsname.sysname<<    endl;
>>>    cout<<    "utsname.version:"<<    utsname.version<<    endl;
>>>    cout<<    "utsname.release:"<<    utsname.release<<    endl;
>>>    cout<<    success<<    endl;
>>>    cout<<    strstr( utsname.release, "ccrma" )<<    endl;
>>> }
>> Here's what it prints:
>>
>> ----
>> utsname.sysname:Linux
>> utsname.version:#1 SMP PREEMPT RT Tue Sep 7 14:36:14 EDT 2010
>> utsname.release:2.6.33.8-149.rt29.1.fc12.ccrma.i686.rtPAE
>> 0
>> ccrma.i686.rtPAE
>> ----
>>
>> Looks like you are right and "release" is the one to use.  When I have some
>> time I'll try to get a better test that does not depend on "ccrma" being on
>> the release part of the kernel. Probably something that would do the
>> equivalent of:
>>
>> ----
>> grep PREEMPT_RT /boot/config-2.6.33.8-149.rt29.1.fc13.ccrma.i686.rtPAE
>> CONFIG_PREEMPT_RT=y
>> ----
>>
>> Which would only be defined in rt patched kernels regardless of their
>> name...
>>
>> Hmm, how about strstr( utsname.version, "PREEMPT RT" ) ? Would that
>> give a positive result on (non-)ccrma realtime kernels?
Ah yes, good one, I did not notice it! I would use it for now. It would 
work for ccrma branded kernels and we could test later for patched 
kernels that somebody else builds (difficult but maybe not impossible). 
I don't know what puts the "PREEMPT RT" string there, will have to do 
some research.

A broader question is: does it make any difference? :-)

I tested a long long time ago and it was better, and in theory it is the 
best optimization (priority of irq-soundcard > jack > everything else), 
but maybe at this point it is not a huge difference in performance.

-- Fernando