2 Feb
2009
2 Feb
'09
2:35 p.m.
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
in different
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
processes
(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 2.6.26.8* 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.
-- Fernando
Any knowledge or link that would enlighten me are
highly appreciated.
Kind Regards
/Lars
2009/2/2 Robin Gareus <robin(a)gareus.org>rg>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
krgn wrote:
_______________________________________________
Linux-audio-tuning mailing list
Linux-audio-tuning(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-tuning On Sun, Feb 1, 2009 at 3:08 AM,
<hollunder(a)gmx.at> wrote:
indeed, jackd did not start unless run as root or until I changed
/proc/sys/kernel/sched_rt_runtime_us
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
http://kerneltrap.org/mailarchive/linux-kernel/2008/8/16/2960524
BTW. in sysctl.conf it's not "sys.kernel..." but
kernel.sched_rt_runtime_us = -1
robin
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
>>> wrote:
>>>> 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 2.6.26.8-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;
I
>>>>> 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
get
>>>> 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 2.6.28.2 #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 2.6.28.2 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! -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkmGZ1AACgkQeVUk8U+VK0JleACdGtXQ+jNwHFTkAIsHlN2Lo0+t
7CYAnRHWNCxkQ3CtuvmhLteUH+E6RXNJ
=q9dt
-----END PGP SIGNATURE-----
_______________________________________________
Linux-audio-tuning mailing list
Linux-audio-tuning(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-tuning