Linux-audio-tuning February 2009

linux-audio-tuning@lists.linuxaudio.org

7 participants
4 discussions

by Emanuel Rumpf

Hi I just successfully installed 2.6.29-rc4-rt2 $ uname -a Linux mech 2.6.29-rc4-rt2-tip #2 SMP PREEMPT RT Sat Feb 14 17:23:59 CET 2009 i686 GNU/Linux Let me also mention, that the binary nvidia beta driver is working with it (NVIDIA-Linux-x86-180.18-pkg1.run). My problem: jack doesn't start with the real-time option enabled - output: JACK compiled with System V SHM support. cannot use real-time scheduling (FIFO at priority 10) [for thread -1210911056, from thread -1210911056] (1: Operation not permitted) In limits.conf , I have: @audio - rtprio 99 @audio - memlock 600000 @audio - nice -14 This setup used to work fine with my previous RT-kernel (2.6.25) Any idea and help is welcome. Thanks -- Emanuel Rumpf

16 years, 12 months

Re: [LAT] [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)

by Fernando Lopez-Lezcano

On Mon, 2009-02-02 at 20:24 +0100, Lars-Erik Helander wrote: > Fernando your elaborate response is highly appreciated, thanks!! > > >> - 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). > > > This was my thought to. > > >> - 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) > > > I use "lmms" every now and then. I have never been able to get "lmms" > to work well with jack so I use it with ALSA as the audio driver. This > works fine though I can not use jack application simultaneously. So in > this case do I have to explicitly give "lmms" SCHED_FIFO and rtprio? > How (using chrt?) ? If you want you could use chrt. I don't know if lmms is multithreaded, if so you would/should change into SCHED_FIFO the audio thread. Even then the application should be well designed, otherwise it could hang the whole machine. > >> 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? > > > About a week ago building from the git produced a kernel that did not > boot properly, actually it did not even build properly and my own > remedy for the build problem resulted in a kernel that was not able to > boot up properly. However building from the git this weekend produced > a well working kernel. Only problem found is the softirq.c bug that > has been around for a while (it makes USB MIDI keyboards etc not to > work - they are discovered but no MIDI events are received) so I had > to apply a patch for that problem. > Build procedure was very straightforward using the git url I cloned > the git and got myself a complete (already "patched" kernel source > tree) and it was just to do the normal "make oldconfig", "make > menuconfig" ... procedures. I see, I just tried with no luck. It may be a configuration option that triggers compile errors (or something else I'm not doing right). -- Fernando > >> 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 :-). > > I have also sucsessfully built and used 2.6.26.8-rt13 with the Slitaz > (www.slitaz.org) distribution (the git kernel also works with that > distribution). > In order to use the kernel with my USB MIDI devices I had to apply the > above mentioned softirq.c patch.

17 years

[LAT] Fwd: [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)

by Lars-Erik Helander

My response only got sent to Fernando. Here it is for all of you to see :) /Lars ---------- Forwarded message ---------- From: Lars-Erik Helander <lehswe(a)gmail.com> Date: 2009/2/2 Subject: Re: [LAT] [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?) To: Fernando Lopez-Lezcano <nando(a)ccrma.stanford.edu> Fernando your elaborate response is highly appreciated, thanks!! >> - 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). > This was my thought to. >> - 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) > I use "lmms" every now and then. I have never been able to get "lmms" to work well with jack so I use it with ALSA as the audio driver. This works fine though I can not use jack application simultaneously. So in this case do I have to explicitly give "lmms" SCHED_FIFO and rtprio? How (using chrt?) ? >> 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? > About a week ago building from the git produced a kernel that did not boot properly, actually it did not even build properly and my own remedy for the build problem resulted in a kernel that was not able to boot up properly. However building from the git this weekend produced a well working kernel. Only problem found is the softirq.c bug that has been around for a while (it makes USB MIDI keyboards etc not to work - they are discovered but no MIDI events are received) so I had to apply a patch for that problem. Build procedure was very straightforward using the git url I cloned the git and got myself a complete (already "patched" kernel source tree) and it was just to do the normal "make oldconfig", "make menuconfig" ... procedures. >> 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 :-). I have also sucsessfully built and used 2.6.26.8-rt13 with the Slitaz (www.slitaz.org) distribution (the git kernel also works with that distribution). In order to use the kernel with my USB MIDI devices I had to apply the above mentioned softirq.c patch. /Lars

17 years

Re: [LAT] [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)

by Robin Gareus

-----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, 2009-01-27 at 14:06 +0100, Peder Hedlund wrote: >>>> Quoting Ken Restivo <ken(a)restivo.org>: >>>> >>>>> 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. Here's my .config running running debian/lenny+sid on a Thinkpad X60s: http://mir.dnsalias.com/_media/wiki/kernel/config-2.6.28.2.txt robin PS. I bumped into Linus at LCA: 2.6.27 still had various issues with the "big kernel lock" in some modules - most notably vfat - but they should be pretty much gone by now. YAY! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmFGjAACgkQeVUk8U+VK0LVngCgt3l+6PXmL5e7cDi5u4Eo05wP U/oAnA/q9PzfzgeIJcn3IcKworS6bzC3 =oUdC -----END PGP SIGNATURE-----

17 years

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Linux-audio-tuning February 2009