<br><br><div class="gmail_quote">On Sun, Feb 1, 2009 at 3:08 AM,  <span dir="ltr">&lt;<a href="mailto:hollunder@gmx.at">hollunder@gmx.at</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Sun, 01 Feb 2009 04:42:40 +0100<br>
Robin Gareus &lt;<a href="mailto:robin@gareus.org">robin@gareus.org</a>&gt; wrote:<br>
<br>
&gt; -----BEGIN PGP SIGNED MESSAGE-----<br>
&gt; Hash: SHA1<br>
&gt;<br>
&gt; Fernando Lopez-Lezcano wrote:<br>
&gt; &gt; On Fri, 2009-01-30 at 03:23 +0100, <a href="mailto:torbenh@gmx.de">torbenh@gmx.de</a> wrote:<br>
&gt; &gt;&gt; On Thu, Jan 29, 2009 at 03:41:48PM -0800, Fernando Lopez-Lezcano<br>
&gt; &gt;&gt; wrote:<br>
&gt; &gt;&gt;&gt; On Tue, 2009-01-27 at 14:06 +0100, Peder Hedlund wrote:<br>
&gt; &gt;&gt;&gt;&gt; Quoting Ken Restivo &lt;<a href="mailto:ken@restivo.org">ken@restivo.org</a>&gt;:<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; And here is the next installment in the saga of trying to get<br>
&gt; &gt;&gt;&gt;&gt;&gt; Ingo RT going on my Asus EEE.<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; I successfully built and ran the 2.6.26.8-rt12 with the<br>
&gt; &gt;&gt;&gt;&gt;&gt; alsa_seq patch. It ran.<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; The problem is that neither the Ethernet (atl1e) or wireless<br>
&gt; &gt;&gt;&gt;&gt;&gt; (rt2860sta) work. So I pretty much had to reboot back out of<br>
&gt; &gt;&gt;&gt;&gt;&gt; it immediately.<br>
&gt; &gt;&gt;&gt;&gt; I&#39;ve been running the standard kernel from openSUSE 11.0 on my<br>
&gt; &gt;&gt;&gt;&gt; Athlon 2000+ and can get down to at least 5.3ms latency on an<br>
&gt; &gt;&gt;&gt;&gt; Audiophile 2496 using the limits.conf &quot;trick&quot;.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; Do people really need lower latencies for music purposes or are<br>
&gt; &gt;&gt;&gt;&gt; we just thinking &quot;well, I needed the RT patch three years ago; I<br>
&gt; &gt;&gt;&gt;&gt; ain&#39;t stopping now&quot; ?<br>
&gt; &gt;&gt;&gt; It depends on your usage (this question seems to come up every<br>
&gt; &gt;&gt;&gt; couple of months lately). The current kernels are much better in<br>
&gt; &gt;&gt;&gt; low latency applications than three years ago. They are usable if<br>
&gt; &gt;&gt;&gt; you don&#39;t require &quot;low&quot; latencies (64 or 128 x 2). What you get<br>
&gt; &gt;&gt;&gt; also strongly depends on the hardware mix you have.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; If you want to use 64 or 128 frame periods (or less) you probably<br>
&gt; &gt;&gt;&gt; will need at rt patched kernel in most cases. Then again if an<br>
&gt; &gt;&gt;&gt; occasional xrun is not a problem then you would be fine with the<br>
&gt; &gt;&gt;&gt; stock kernel.<br>
&gt; &gt;&gt; i am running with -p64 -n3 on an intel-hda with 2.6.28<br>
&gt; &gt;&gt; of course internal cards have the greatest potential for<br>
&gt; &gt;&gt; lowlatencies. so this might be unfair, compared to pci.<br>
&gt; &gt;<br>
&gt; &gt; Hmmm, I&#39;m not sure, the load on pci itself by a soundcard should be<br>
&gt; &gt; nothing really hard. What would the internal card use? Would not<br>
&gt; &gt; that be pci or pci express anyway?<br>
&gt; &gt;<br>
&gt; surely they are.<br>
&gt;<br>
&gt; $ lspci &nbsp;| grep Audio<br>
&gt; 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High<br>
&gt; Definition Audio Controller (rev 02)<br>
&gt;<br>
&gt; The RT patch does two things:<br>
&gt; It allows to prioritize interrupts and it [almost] guarantees<br>
&gt; real-time scheduling for a dedicated process or thread.<br>
&gt;<br>
&gt; While the soundcard is low bandwith on the PCI bus, IRQ prio may still<br>
&gt; be required to override HDD and [sometimes] graphics I/O; at least<br>
&gt; when playing or recording many tracks. NTL, you can get a perfect<br>
&gt; x-run free system without the RT patch; you can just not rely on it<br>
&gt; to be as x-run free as a RT patched kernel ;)<br>
&gt;<br>
&gt; &gt;&gt; and i havent really seen xruns which i could not relate to some<br>
&gt; &gt;&gt; programm which wasnt RT-safe, and i am compiling stuff most of the<br>
&gt; &gt;&gt; day... though perhaps i am not pushing the DSP load hard enough.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; i did not even turn preemptible RCU on.<br>
&gt; &gt;&gt; the latency measurement instrumentation is also in 2.6.28 btw.<br>
&gt; &gt;<br>
&gt; &gt; Well, that&#39;s very good news then!<br>
&gt; &gt;<br>
&gt; &gt; I think the last time I tried to use a non-preempt was 2.6.27.x<br>
&gt; &gt; (maybe, I would have to double check). Playing 24 channels in<br>
&gt; &gt; ardour would result in xruns, not very often but they would happen,<br>
&gt; &gt; this is with 128x2 on an RME hdsp card runing on a quad core intel<br>
&gt; &gt; system. I should try again with the latest available.<br>
&gt;<br>
&gt; I just booted into a vanilla 2.6.28.2 #1 SMP PREEMPT<br>
&gt;<br>
&gt; right, there&#39;s no realtime patch, yet running jackd at 64 * 3 @48kSPS<br>
&gt; on a HDA - ardour2 with 12 tracks, a couple of LADSPA effects and<br>
&gt; jamin (lots of CPU!) - there&#39;s no xruns yet!<br>
&gt;<br>
&gt; I&#39;ll be back in the studio in two weeks from now to test it with USB<br>
&gt; and 1394 devices. With &lt;=2.6.24 kernels those were always working more<br>
&gt; reliably that the HDA so I don&#39;t expect problems there.<br>
&gt;<br>
&gt; BTW. with 2.6.28 I needed to<br>
&gt;<br>
&gt; &nbsp;`echo -1 &gt; /proc/sys/kernel/sched_rt_runtime_us`<br>
&gt;<br>
&gt; or edit /etc/sysctl.conf and add<br>
&gt; &nbsp; sys.kernel.sched_rt_runtime_us = -1<br>
&gt;<br>
&gt; before JACK was able to acquire real-time privileges.<br>
<br>
</div></div>May I ask what that does? This value is 950000 on my system.<br>
I think jack has rt privileges here on 2.6.28.2 but I&#39;m not too certain.<br>
I don&#39;t even know how to check that reliably.<br></blockquote><div><br>jackd would not start with -R if realtime permission can not be granted. I think you would know if there was a problem ;)<br>I have to say I don&#39;t know either what this option is you are setting, Robin. Is that the granularity of the timer (in u-sec&#39;s)? Setting to -1 seems to suggest that the highest possible value is used, although I&#39;m only wildly guessing. Would be great to know!<br>
<br>&nbsp;cheers, <br><br>karsten<br></div></div>