Experimenting with kernel 2.6.28

[funkmuscle]

oh yeah, I'm waiting!!

[genlog]

Thorgal,

How the did you build the kernel?

I just build linux-2.6.28.4, with FIFO, but jack refuses to use Realtime option

JACK compiled with System V SHM support.
cannot use real-time scheduling (FIFO at priority 10) [for thread -1207335248, from thread -1207335248]
(1: Operation not permitted) cannot create engine

I totally don't understand how that you run it RT.

For now it's still ok, because i don't record audio yet (online midi for now), but i will need it soon .
Using older kernel is not option, because marvell pata support via legacy was broken until 2.6.27.

Hopefully you can help :d

[thorgal]

Hello,

You are using 2.6.28.4. I used vanilla 2.6.28. That's the difference. If I am not getting senile, I sort of remember having read that 2.6.28.3 should be fine with RT. Try to downgrade to .3 if you want more recent than vanilla 2.6.28.

Moreover, I forgot to mention that I also got the recent RT git-tree (the development code containing the RT patches) to compile and boot fine. It's buggy though (kernel crashes, PC freeze when closing jackd due to an old kernel bug - there's a patch that fixes it, it was mentioned on the jackd mailing list after I asked if anyone knew what was happening but it does not remove the kernel crashes). Anyway, work on the RT branch is ongoing.

[genlog]

No succes with 2.6.28,2.6.28.3, 2.6.28.4

But i have read in the documentation, that i should make some 'space' free for RT via uuid or group.

in may case, that should be in /sys/kernel/uids/1000/cpu_rt_runtime

Now the value of cpu_rt_runtime is 0 for my uid. If i'm looking for the value of the root(0 uid) it is 950000.
So i tried to change the value of my uid but i get errors. I've searched for the error, and it appears to be kind of a bug.

http://linux.derkeiler.com/Mailing-List ... 06354.html

I suppose if I patch the kernel it should work.

Thank you for the reply.

[thorgal]

hey genlog, your last post gave me a hint as to what the difference is between your compilation and mine : I never choose the CONFIG_GROUP_SCHED option, always set it to N.
I am the only user of my DAW, no need to define specific user groups with different level of RT privileges. I never looked into this rather recent kernel option.

[genlog]

It's possible that was the problem. Anyway i patched my kernel with the patch & can now run RT, so i'm happy .
Next time i will compile without the group support because i'm also the only one that use the computer.
Anyway i got now latency time of 2.53ms wich is very good, but i didn't test it under big load. But i think that will be not a very big probleem because i don't use much vst's, i like more hardware synths etc.

Anyway, thank you again for support
If I could, i would buy you a great belgian beer :d

[thorgal]

interesting post from the Jucetice blog: http://www.anticore.org/jucetice/?p=117

something to think about before jumping to newer kernels. I did not experience what the guy mentioned but again, I did not test it with his simple terminal command.

[studio32]

I think the 64studio team reports good results with the .29 kernel...

[thorgal]

just tried it (2.6.29-rc6-rt3).

I first checked the processes (ps -Leo class,rtprio,com | grep IRQ and timer). I noticed some stuff has changed:
it is not softirq-timer and softirq-hrtimer but sirq-timer and sirq-hrtimer. So in debian based systems, you will have to modify /etc/default/rtirq accordingly.

Apart from that, I tried a very low latency setting.
First with -p 64 -n 2 -r 96000 (0.7ms lat one way). I fired ardour with a not very big but not small session. Clicking on the time ruler area to trigger transport always produced an xrun but playback itself did not.

Then, I increased the number of frames per period to 128 (one way latency 1.3ms). The xrun behavior disappeared.

I then fired rosegarden and dssi-vst with a VSTi and played them along with ardour in jack transport mode. It ran really good for 5mn when suddenly, rosegarden froze. I could not stop it normally but KDE could kill it after I tried to kill the RG window (KDE pops up a question whether you want to kill the process because the app is not responding to the mouse action).

Killing RG did not fuck up the rest, dssi-vst and ardour were still alive and kicking.

I am not sure what the matter is with RG at low lat. I wanted to test further but I am too busy with other things ATM. I will investigate further when I am not so busy.
Cheers!

[raboof]

Is that the kernel at http://apt.64studio.com/backports/pool/ ... linux-2.6/ ?

[thorgal]

as usual, I compiled my own kernel.