On Wednesday 03 October 2007 21:57, Roman Muñoz wrote: > May be you have some shared IRQ's? Just guessing... Hi Roman. Thanks for your reply. Normally sound cards don't have any problems sharing IRQ's, and as realtime is working with Fedora 7 on the same machine as Etch with my audigy2 soundblaster card, I think that there is something else going on here on Etch, that I havn't quite figured out. > > I wonder what could be the problem here, since I'm using realtime on > Debian Etch with no xruns... and the card is an infamous intel-hda on an > nvidia ck804 motherboard. The fact that you've got the intel-hda card to even work deserves 10 out of 10 full marks. I've seen so many problems with the infinite variations of it. > > I'm not really doing serious audio work (I'm not a musician) but worked > for a music school willing to change from Microsotf. They use Audigy > (and some usb m-audio) cards, and they look like being quite happy. They > used to be Windows-only people until June. Yes, they are using Etch now. > So I would say that Etch works fine with realtime. > > We made a live-cd for that music school. We are not advertising nor > promoting it as a multimedia distro, it is simply what we made in order > to get a system installed and configured quickly, then the music school > came to us and we added the realtime stuff, etc. It worked for them > rigth after installing and setting qjackctl for their card (frames, > sample rate & period, no more). Anyway, you can download it as a Debian > Etch-based livecd, with some (quite few) packages added from testing, > musix, kiberpipa and debian-multimedia: > > http://gisa-elkartea.org/gisalivecd-012.iso > > kernel is 2.6.21.6-rt21, also available to download separatedly: > > http://gisa-elkartea.org/linux-image-2.6.21.6-rt21-gisa-686_03_i386.deb I don't think the kernel version is the problem. There's some other problem, but your kernel is later than Marcos's, so I'll install that as well. I'm on dialup so downloading iso's takes some time, but I'll look at your distro. I think first I'll download the latest version of Musix. This way I can see if realtime is working ok on it, and may get some clues as to why realtime is not working on Etch. > > To install it, you should log in as root with password gisanagusia. On > root's desktop you will find icons for install instructions, gparted and > install script. > > However, install instructions and script are spanish-only at this > moment, sorry. It asks for devices where /, swap, /home and /multimedia > partitions are (you can leave /home and /multimedia blank if not used), > username, user password (twice), root password (twice). grub > destination, and finally, it asks if /home and multimedia contents (if > any) should be preserved. > > Hope this helps, > Roman Many thanks for your reply. Nigel. > > PS: no rtirq on this livecd, but a script /usr/sbin/rtprio_snd is > called at qjackctl's start. Still, rtirq is probably much better... > > PS2: Many thanks to all the people that worked/wrote on/about linux > audio. They made it easy for us to go now to the music school and see so > many smiles. Thank you all very much. > > Nigel Henry escribió: > > On Wednesday 03 October 2007 15:05, Florian Schmidt wrote: > >> On Wednesday 03 October 2007, Wolfgang Woehl wrote: > >>> Montag, 1. Oktober 2007 Marcos Guglielmetti: > >>>> @audio - rtprio 99 > >>>> @audio - nice -10 > >>>> @audio - memlock 4000000 > >>> > >>> Marcos, looking at these numbers (and variations of these on various > >>> netpages) I always wonder whether they are such a good idea: Wouldn't > >>> rtprio 99 allow for banzai processes to almost lock down the machine? > >>> Wouldn't memlock 4000000 (4GB) be like begging for a swapfest on > >>> standard 1GB/2GB machines? Isn't the whole point about limits.conf to > >>> effectively prevent processes from sucking in all resources? So that > >>> when realtime processes go havoc you'll be left with cycles and memory > >>> to survive the situation? > >> > >> Yes, > >> > >> one always assumes with settings like this, that the programs which are > >> run are nicely behaved (e.g. jackd has a watchdog to kill its clients > >> when they run havok).. > >> > >> But whether you give one process RT prio 1 or 99 doesn't matter. It can > >> always keep all SCHED_OTHER threads [the rest of your system, X, xterms, > >> whatnot] from running at all effectively freezing the box (though in > >> reality this is expected behaviout). > >> > >> A typical method to counter this scenario would be to limit user > >> processes to prio 98 and have another watchdog process runnning at prio > >> 99. That watchdog would have another thread running at SCHED_OTHER and > >> checks at regular intervals whether this thread got to run at all. If > >> not -> take action and make e.g. all SCHED_FIFO threads in the system > >> SCHED_OTHER so the user is able to recover from the situation.. There > >> are several watchdogs available (including one from yours truly which > >> needs an overhaul though).. > >> > >> And yes, of course, you wouldn't want to give all system memory away to > >> mlocking. You need some reserve.. > >> > >> Nice -10 otoh is pretty uncritical i guess. > >> > >> Regards, > >> FLo > > > > I started this thread, but at the moment I'm not having much success at > > getting realtime to work on Debian Etch, and that's before I start on > > Lenny. > > > > Realtime works fine on Fedora 7, using the realtime low latency kernel > > from planetccrma, plus rtirq, and a pam update from planetccrma that gave > > me a limits.conf.rpmnew file, as below. > > > > # limit realtime and memory locking access to users in the group audio > > # there is no way to say "allow locking all memory", 4G should be enough > > # > > #* - rtprio 0 > > #* - nice 0 > > # > > #@audio - rtprio 99 > > #@audio - nice -10 > > #@audio - memlock 4000000 > > > > # or (default) allow everyone access > > * - rtprio 99 > > * - nice -10 > > * - memlock 4000000 > > > > Editing the existing limits.conf, adding the above, and commenting out > > the default entries for jack, works fine. When starting jackd in > > qjackctl, I'm getting one xrun every 6m 25secs on average, and the > > largest xrun over the time I tested was about 0.325 msecs. I tested over > > about 2 1/2 hours, and the only other apps open on the desktop were > > Xawtv, and Gkrellm. > > > > On Debian Etch, after adding Marcos's repo to /atc/apt.sources.list, I > > installed the 2.6.21-rt4, and 2.5.21.5-rt18 kernel, along with rtirq > > version 20070101. I edited limits.conf, and added the part above that I > > received from planetccrma. That didn't work, with xruns every 2-3secs. I > > commented out the default uncommented lines, and uncommented the audio > > lines, which are at the top of this post. Still I get xruns every 2-3 > > secs, and if I reboot and try a non rt kernel, xruns every 2-3 secs > > again. It appears that there is still something missing to get realtime > > working on Etch. > > > > I may have to download Musix again, and see how realtime runs on it. I > > DL'd before, but that was when there was a problem with it booting with > > some hardware. As I'm on dialup, I'd put off DL'ing it again, since the > > booting problem has been resolved. > > > > Marcos. If your reading this. Could you provide the link to download > > Musix again please. > > > > Thanks for all the replies to this thread. > > > > Nigel. > > > > > > _______________________________________________ > > Linux-audio-user mailing list > > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > > http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user > > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
