On Mon, 2009-02-02 at 09:53 +0100, Lars-Erik Helander wrote:
I really appreciate the information provided in this
thread. However I
would appreciate if someone could provide a link to some basic
information on the subject since I have found very little information
about using standard kernel features for low-latency.
The kind of questions I do have are:
- What kernel versions are suitable to use (have significant
real-time like characteristics) without applying the rt-patches (...,
2.6.25.*, 2.6.26.*, 2.6.27.*, 2.6.28.*)
Users are posting success with 2.6.28.*
(Information on what, in this context, was added
versions would of course help)?
- If I take some standard distribution which has a suitable (non-RT)
kernel version, what do I have to do in order to to have some basic
audio apps running nicely?
- Will "rtirq" make a difference on a non-RT-patched kernel system?
No AFAIK. Non-rt patched kernels do not have irq processes running as
separate SCHED_FIFO threads (which is what is tuned by rtirq).
- Do I have to use PAM to have non-root users to
acquire necessary rtprios?
I guess it depends on the distro. In most (all?) you have to make sure
the user is allowed to use SCHED_FIFO and lock memory
in /etc/security/limits.conf. That may be already done by your distro -
in some cases you have to add your user to a group for things to work
(and then logout and login again).
- What jackd settings are important?
Depends a bit on the soundcard.
-R --> to use SCHED_FIFO
-d --> point to your hardware device (ie: hw:0 for the first card)
-p --> say, 128, for low latency
-n --> some hda-intel cards on not so new kernels may need 3 or more
- Do I need to assign rtprios explicitly to all my
(qjackctl, qsynth, ...) or is that "automagic"?
Automagic. Jackd gives the proper priority to the clients (to the thread
of the client that handles audio i/o)
- Do I need to modify anything else under /sys or
/proc for the
system to use the available rt-like characteristics?
Hmmm, I did not have to but apparently newer kernels need some tweaking
(see other messages in this thread)
I have close to 30 years experience in developing
realtime systems and
has been using Linux for audio in various distribution the last two
years. Further I have built RT-kernel for couple of distributions
(this weekend I successfully built and ran a 2.6.28-rt kernel from the
new git tree :) ).
Ah, I have not tried this yet! How did that work out? Any errors or
problems on boot? How exactly did you go about building the whole thing?
However I have no experience in using newer non-RT
kernels but I am very interested to find out how well you can have
them work, especially since whenever you find a nice distro you can
not use it because the hazzle of building an RT-kernel for that
particular distro is so big :(.
Planet CCRMA (http://ccrma.stanford.edu/planetccrma/software/
) has rt
patched kernels of the 220.127.116.11* flavor for fc9 (in the "testing"
repository) and fc10, and should be easy to install (not an objective
assessment, I created and maintain Planet CCRMA :-).
There are many other distros out there that have rt kernels as well.
Any knowledge or link that would enlighten me are
2009/2/2 Robin Gareus <robin(a)gareus.org>rg>:
-----BEGIN PGP SIGNED MESSAGE-----
On Sun, Feb 1, 2009 at 3:08 AM,
On Sun, 01 Feb 2009 04:42:40 +0100
Robin Gareus <robin(a)gareus.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Fernando Lopez-Lezcano wrote:
>> On Fri, 2009-01-30 at 03:23 +0100, torbenh(a)gmx.de wrote:
>>> On Thu, Jan 29, 2009 at 03:41:48PM -0800, Fernando Lopez-Lezcano
>>>> On Tue, 209-01-27 at 14:06 +0100, Peder Hedlund wrote:
>>>>> Quoting Ken Restivo <ken(a)restivo.org>rg>:
>>>>>> And here is the next installment in the saga of trying to get
>>>>>> Ingo RT going on my Asus EEE.
>>>>>> I successfully built and ran the 18.104.22.168-rt12 with the
>>>>>> alsa_seq patch. It ran.
>>>>>> The problem is that neither the Ethernet (atl1e) or wireless
>>>>>> (rt2860sta) work. So I pretty much had to reboot back out of
>>>>>> it immediately.
>>>>> I've been running the standard kernel from openSUSE 11.0 on my
>>>>> Athlon 2000+ and can get down to at least 5.3ms latency on an
>>>>> Audiophile 2496 using the limits.conf "trick".
>>>>> Do people really need lower latencies for music purposes or are
>>>>> we just thinking "well, I needed the RT patch three years ago;
>>>>> ain't stopping now" ?
>>>> It depends on your usage (this question seems to come up every
>>>> couple of months lately). The current kernels are much better in
>>>> low latency applications than three years ago. They are usable if
>>>> you don't require "low" latencies (64 or 128 x 2). What you
>>>> also strongly depends on the hardware mix you have.
>>>> If you want to use 64 or 128 frame periods (or less) you probably
>>>> will need at rt patched kernel in most cases. Then again if an
>>>> occasional xrun is not a problem then you would be fine with the
>>>> stock kernel.
>>> i am running with -p64 -n3 on an intel-hda with 2.6.28
>>> of course internal cards have the greatest potential for
>>> lowlatencies. so this might be unfair, compared to pci.
>> Hmmm, I'm not sure, the load on pci itself by a soundcard should be
>> nothing really hard. What would the internal card use? Would not
>> that be pci or pci express anyway?
> surely they are.
> $ lspci | grep Audio
> 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High
> Definition Audio Controller (rev 02)
> The RT patch does two things:
> It allows to prioritize interrupts and it [almost] guarantees
> real-time scheduling for a dedicated process or thread.
> While the soundcard is low bandwith on the PCI bus, IRQ prio may still
> be required to override HDD and [sometimes] graphics I/O; at least
> when playing or recording many tracks. NTL, you can get a perfect
> x-run free system without the RT patch; you can just not rely on it
> to be as x-run free as a RT patched kernel ;)
>>> and i havent really seen xruns which i could not relate to some
>>> programm which wasnt RT-safe, and i am compiling stuff most of the
>>> day... though perhaps i am not pushing the DSP load hard enough.
>>> i did not even turn preemptible RCU on.
>>> the latency measurement instrumentation is also in 2.6.28 btw.
>> Well, that's very good news then!
>> I think the last time I tried to use a non-preempt was 2.6.27.x
>> (maybe, I would have to double check). Playing 24 channels in
>> ardour would result in xruns, not very often but they would happen,
>> this is with 128x2 on an RME hdsp card runing on a quad core intel
>> system. I should try again with the latest available.
> I just booted into a vanilla 22.214.171.124 #1 SMP PREEMPT
> right, there's no realtime patch, yet running jackd at 64 * 3 @48kSPS
> on a HDA - ardour2 with 12 tracks, a couple of LADSPA effects and
> jamin (lots of CPU!) - there's no xruns yet!
> I'll be back in the studio in two weeks from now to test it with USB
> and 1394 devices. With <=2.6.24 kernels those were always working more
> reliably that the HDA so I don't expect problems there.
> BTW. with 2.6.28 I needed to
> `echo -1 > /proc/sys/kernel/sched_rt_runtime_us`
> or edit /etc/sysctl.conf and add
> sys.kernel.sched_rt_runtime_us = -1
> before JACK was able to acquire real-time privileges.
May I ask what that does? This value is 950000 on my system.
I think jack has rt privileges here on 126.96.36.199 but I'm not too certain.
I don't even know how to check that reliably.
jackd would not start with -R if realtime permission can not be granted. I
think you would know if there was a problem ;)
I have to say I don't know either what this option is you are setting,
Robin. Is that the granularity of the timer (in u-sec's)? Setting to -1
seems to suggest that the highest possible value is used, although I'm only
wildly guessing. Would be great to know!
indeed, jackd did not start unless run as root or until I changed
It's the us (or .001% of CPU usage?!) above which FIFO and RR will be
throttled to recover from a run-away rt process. - I'm not exactly sure
why it affects jackd when run as "normal" user; maybe because with CPU
load above the default 95% rt can not be guaranteed.
There's a bit [off topic] but enlightening info at
BTW. in sysctl.conf it's not "sys.kernel..." but
kernel.sched_rt_runtime_us = -1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
-----END PGP SIGNATURE-----
Linux-audio-tuning mailing list
Linux-audio-tuning mailing list