rt kernel, pro-audio use

rt kernel, pro-audio use

[Damien Moody]

Hi,

I have a couple of questions.

1. I'd like to keep informed when the rt kernel gets updated, so I can 
put up a new Gentoo ebuild on my site (gentoostudio.org). Is this the 
list for that? If not, what is?

2. I use the rt patches a la rt-sources on Gentoo. I'm a musician and 
audio engineer. What advantages does the rt patch set provide over other 
patch sets like ck-sources and pf-sources, where latency can be 
configured to be very low? I'd like to document this on my site.

Thanks!
Damien

Re: rt kernel, pro-audio use

[Ove Karlsen]

On 12/19/2012 10:30 PM, Damien Moody wrote:
> Hi,
>
> I have a couple of questions.
>
> 1. I'd like to keep informed when the rt kernel gets updated, so I can 
> put up a new Gentoo ebuild on my site (gentoostudio.org). Is this the 
> list for that? If not, what is?
>
> 2. I use the rt patches a la rt-sources on Gentoo. I'm a musician and 
> audio engineer. What advantages does the rt patch set provide over 
> other patch sets like ck-sources and pf-sources, where latency can be 
> configured to be very low? I'd like to document this on my site.
>
> Thanks!
> Damien
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
1 - yes. Have your email client filter mails with "announce" in the 
header, to "rt kernel updates" folder for instance. Something like that.

2 - rt-patch provides extremely low latency, if you hardware can handle 
it. Intel E5 is a good cpu, for extreme low latency.
Ck-patches doesn`t really provide any improvement over fair-scheduler. 
Actually fair-scheduler performs on overall better, with lower peak 
latencies. Ck-patches has slightly lower average latencies. While 
audio-performance was similar when I tested both, visual jitter, was 
less with fair scheduler, and 90hz timer.

I did some tests to make linux run with the least-jitter possible. You 
can read the conlusions on that here: 
http://paradoxuncreated.com/Blog/wordpress/?p=2268

It seems RT-patch is not neccesary for very low latency audio, and a 
good firewire card, atleast on the old firewire-stack, hopefully the new 
one is as good at latency, where I ran audio at 0.33ms latency, with 
RT-threads.

The rt-patch using only threadmode, (not impacting performance, other 
than on the thread it is used) might be good for audio, since visual 
jitter already can be minimized on the regular kernel. if 0.33 should 
not work with standard and it is a software problem, or you want to try 
even lower. 0.2ms is very close to virtual hardware, and ofcourse is 
something a musician would want.

Other than that RT patch might have specific uses outside general 
computing and media.

Peace Be With You.

Re: rt kernel, pro-audio use

[Clark Williams]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

On Wed, 19 Dec 2012 21:30:29 +0000
Damien Moody <webmaster@gentoostudio.org> wrote:

> Hi,
> 
> I have a couple of questions.
> 
> 1. I'd like to keep informed when the rt kernel gets updated, so I can 
> put up a new Gentoo ebuild on my site (gentoostudio.org). Is this the 
> list for that? If not, what is?
> 
> 2. I use the rt patches a la rt-sources on Gentoo. I'm a musician and 
> audio engineer. What advantages does the rt patch set provide over other 
> patch sets like ck-sources and pf-sources, where latency can be 
> configured to be very low? I'd like to document this on my site.
>

I use an RT-patched kernel with Fedora to record drum tracks with
Ardour3+jack+ffado. I can record 16-channels of 24-bit samples at
48000Hz through a pair of Presonus FP10s attached to a Lenovo W510
laptop and I honestly can't remember the last time I had an xrun. 

I'm sure plenty of people can do this with a standard kernel that's
been tuned but no matter how much they tune it, there's always the
possibility of running into a priority-inversion situation. The RT
patchset converts most of the spinlocks in the kernel to an
rt_mutext_t. The rt_mutex_t lock has a priority-inheritance chain that
allows for a temporary priority boost of a thread holding a lock when a
higher priority thread tries to claim the lock. This prevents
intermediate priority threads from preventng the lock-holder thread
from running, delaying the high priority thread indefinitely. 

Clark


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]