1 Feb
2009
1 Feb
'09
11:13 p.m.
On Sun, Feb 1, 2009 at 3:08 AM, <hollunder(a)gmx.at> wrote:
On Sun, 01 Feb 2009 04:42:40 +0100
Robin Gareus <robin(a)gareus.org> wrote:
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!
cheers,
karsten
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fernando Lopez-Lezcano wrote:
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.
On Fri, 2009-01-30 at 03:23 +0100, torbenh(a)gmx.de
wrote:
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 ;)
On Thu, Jan 29, 2009 at 03:41:48PM -0800,
Fernando Lopez-Lezcano
wrote:
> On Tue, 2009-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?
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.