* Re: rt kernel, pro-audio use
2012-12-19 21:30 rt kernel, pro-audio use Damien Moody
@ 2012-12-20 8:36 ` Ove Karlsen
2012-12-20 17:00 ` Clark Williams
1 sibling, 0 replies; 3+ messages in thread
From: Ove Karlsen @ 2012-12-20 8:36 UTC (permalink / raw)
To: Damien Moody; +Cc: linux-rt-users
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: rt kernel, pro-audio use
2012-12-19 21:30 rt kernel, pro-audio use Damien Moody
2012-12-20 8:36 ` Ove Karlsen
@ 2012-12-20 17:00 ` Clark Williams
1 sibling, 0 replies; 3+ messages in thread
From: Clark Williams @ 2012-12-20 17:00 UTC (permalink / raw)
To: Damien Moody; +Cc: linux-rt-users
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread