> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> krgn wrote:
>> On Sun, Feb 1, 2009 at 3:08 AM, wrote:
>>
>>> On Sun, 01 Feb 2009 04:42:40 +0100
>>> Robin Gareus wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Fernando Lopez-Lezcano wrote:
>>>>> On Fri, 2009-01-30 at 03:23 +0100,
torbenh@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 :
>>>>>>>>
>>>>>>>>> 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!
>
> 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
> -----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@lists.linuxaudio.org
>
http://lists.linuxaudio.org/listinfo/linux-audio-tuning
>