Atte André Jensen wrote: More specifically, make sure you are using a driver specific to your machines PCI/disk controller (if one is available) rather than the generic one. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "Working with Perforce in my day job makes me really appreciate just how good GNU Arch is." -- Erik de Castro Lopo

On Sun, 2005-08-21 at 11:51 -0700, Noah Roberts wrote: That's probably the problem, the generic IDE driver only supports PIO mode which can disable interrupts for a long time. You need to use the IDE driver for your chipset. What distro are you using? This should really work OOTB. Lee

Well, I upgrated to 13-rc6 and tried the patch. The patch ruins the kernel source...it won't compile on this architecture (amd64) with it applied. However, it seems to be included to some degree already. There are only 3 preempt modes and I chose the best...the one I wanted to try first anyway. I also fixed the IDE driver issues. I haven't even messed with any of the interupts. It is working...for now at least. I even started mozilla in the middle of a playback to test and I didn't get an xrun. I did get 2 while typing this and they were not small ones. I am also wondering if it might be some acpi setting I could change that would help a lot. For instance: localhost CPU1 # cat power active state: C2 max_cstate: C8 bus master activity: 000021eb states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00000010] *C2: type[C2] promotion[C3] demotion[C1] latency[090] usage[30301282] C3: type[C3] promotion[--] demotion[C2] latency[900] usage[00014940] Maybe switching to C1 could help? I'm assuming latency should be smaller... I also can't seem to find out which interrupt my soundcard is on. I don't see it in the list: localhost proc # cat interrupts CPU0 0: 318085 IO-APIC-edge timer 1: 3765 IO-APIC-edge i8042 8: 0 IO-APIC-edge rtc 9: 1694 IO-APIC-level acpi 12: 1170 IO-APIC-edge i8042 14: 6163 IO-APIC-edge ide0 15: 12 IO-APIC-edge ide1 177: 29479 IO-APIC-level SiS SI7012 185: 519 IO-APIC-level eth0 193: 15025 IO-APIC-level ohci_hcd:usb1 201: 0 IO-APIC-level ohci_hcd:usb2 209: 0 IO-APIC-level ohci_hcd:usb3 217: 54 IO-APIC-level ehci_hcd:usb4 NMI: 1088 LOC: 318053 ERR: 0 MIS: 0 And what is the proc file interface for the preempt patch?

More unsubstantiated comment, for which I apologise: On Monday 22 August 2005 06:54, Lee Revell wrote: I would guess that Noah has already tried it. There is enough traffic on the AGNULA-users list to suggest that none of the prepackaged DeMuDi 2.6 RT kernels are actually stable, they seem to work perfectly on some hardware and not on others (partic. low-spec and 64bit machines). Most of the work has been done by Free alone although Andreas Kuckhartz made a significant contribution to the .12 builds. It is high time that some of the rest of us got savvy enough to help out. I'm wondering if we're still experiencing NPTL hell here, I'm not really sure how to find out. I will attempt to start providing real information soon, promise. -- cheers, tim hall http://glastonburymusic.org.uk/tim

On 8/22/05, tim hall <tech(a)glastonburymusic.org.uk> wrote: The 2.6.13 idea was probably the most helpful. Applying the rt patch was an idea given by Revel, though not for .13...but thanks for yelling at me about it anyway. .13 comes with the RT patch applied already so it isn't necissary to apply any patch to this kernel....not that I don't know how. No, I don't usually mess with kernels built for distributions I don't use so no, I never tried the DeMuDi kernel and I wouldn't trust it as it is built for a distribution that afaik doesn't run on my architecture (not in native mode anyway). I tend to shy away from pre-packaged kernels at any rate though I have been using the gentoo patches because they are specific to my architecture. Right now though I have a vanilla kernel installed and it isn't being a problem so far even if Gentoo says they won't support anything but their kernel on the 64...but I don't generally need support most of the time. I think we are quickly reaching a point when patching the kernel specifically for audio is unnecissary. And I may as well test .13 since I can. I'm not exactly in production mode here...

On Tue, 23 Aug 2005 11:05:57 +1000 "Shayne O'Connor" <forums(a)machinehasnoagenda.com> wrote: Full realtime preemption is not yet in mainline. They just merged: ( ) No Forced Preemption (Server) ( ) Voluntary Kernel Preemption (Desktop) ( ) Preemptible Kernel (Low-Latency Desktop) So for a full preemptible DAW kernel you'll still need ingo's patch applied. btw i had the same experience with 2.6.12 and RT... horrible stability, not faster in any way as vanilla+normal preemption. The best so far is 2.6.11.x + rt, 2.6.13-rc6 is quite stable here, but i use it w/o RT and am back on Con Kolivas -ck2 with new improved SCHED_ISO and very pleased with it so far. But for a production DAW i would use 2.6.11.x + ingo's RT. Regards Tom

On Tue, 2005-08-23 at 10:36 -0700, Noah Roberts wrote: Sorry dude, that's what you get when you buy bleeding edge hardware. You didn't expect this new architecture to work as smoothly as i386 which has been around for 20 years, did you? I guess you'll have to wait for the patch to support your machine. Lee

On 8/23/05, Lee Revell <rlrevell(a)joe-job.com> wrote: I've remained silent on this. You really are no help when you act like this. If you want to help people, great, but this kind of crap isn't helpful. You've replied to this thread 5 times and only once was it without derogatory crap. Only once where you moderately helpful. If you really want to help people, there are better ways to go about it. To everyone that was helpful, thanks. I haven't been able to test since the last report but I think it is working well enough to use for my needs. I have a few more questions but this thread is quickly degrading, and I am just not in the mood to try and justify my selection of hardware and other BS, so I'll just figure the rest out on my own. I really do appreciate those that have been helpful and those that participated to get their own questions answered as well.

On 8/24/05, Lee Revell <rlrevell(a)joe-job.com> wrote: I guess you'll have to point out where I went from asking questions to demanding that everything work flawlessly right now, that Linux SUX because it isn't working this very fucking instant even though I wired everything backwards and submersed my computer in a vat of boiling acid but XP worked just fine before this happened. I am actually sitting here rather pleased that every damn thing in this laptop that I have tried works in Linux at all...in all my years with Linux this has never happened before. If you are getting fed up, just take a break.

Tim Hall says: Thanks Tim, I kind of agree with this. When I'm reading this list I'm aware that there will always be new folks here, people who probably don't know much about linux audio(or linux). Many times I may have an answer to a newbie's question, but not the time. So I hope that someone else will pick up the question and help out. As new people join the list we will have folks who can answer(as Tim stated above). I'm glad that Lee is here to answer some of the harder questions that folks like me need answers to when needed, and I can understand where Lee is coming from. I just try not to let some of those questions get under my skin, that's all. There are other little things that may help. Such as: It would help if people who just started with linux audio not jump in here whining in the hopes that we will instantly fix their problems. Maybe the answer they get will only be a pointer to the Alsa or Jack pages; but it should get them started and then _after_ they read some of the docs and faqs we'll know if there really is a problem to be addressed. I find this list to be extremely helpfull both for getting help, and for being able to find what is needed in the list archives. I hope new folks here know where the archives and wikis are, and can fix some of the trivial problems themselves. There is a lot of enthusiasm here. It's also a very creative place, the kind of places I like to hang out in. Let's all try to give this space the the room for the creativity to blossom in. ... I am also subscribed to the dev list. I don't say much there because many things are above my skill level. But I do learn a lot just hanging out there and reading. Maybe some day I'll be able to help out there too? Some times hanging out and quietly learning the landscape helps. Sometimes a little patience on everyone's part helps a lot. Tracey.

Here is my so far experince for those interested: I could not find a realtime-preempt patch that will apply correctly to a recent 2.6.12 kernel. It could be that some combination of 2.6.12 and realtime-preempt-2.6.12-final will work but I decided to give up. All attempts resulted in rejected hunks, -R?, and/or missing files (which file to patch:). No compilable kernel ever resulted. The two patches I tried are realtime-preempt-2.6.12-final-V0.7.51-38 and realtime-preempt-2.6.12-rc6-V0.7.48-37. Kernel was 2.6.12.5 (when did they add the extra number btw??)....I haven't tried straight up 2.6.12 yet and that may be worth while. 2.6.13-rc6 has some of the realtime preempt patch in it already but it is incomplete. Applying the patch results in a kernel that won't compile for the amd64. 2.6.11.12 can be patched with realtime-preempt-2.6.11-rc4-V0.7.39-02 with success. It compiles on the amd64 and seems to work. I had to use the realtime-lsm patch with it instead of RT-RLimits because the later doesn't seem to exist as a seperate entity from the kernel anymore...even for old versions...or at least I couldn't find it anywhere. Using realtime-lsm was easy as I just did an "emerge realtime-lsm" and set up the gid to audio when loading the module...requires no PAM patch even though I already did one. Right now, without some more serious testing, I am leaning toward the older 2.6.11.12 as the more viable kernel for this computer. I have it set up with complete preemption and it seems to respond quite well to that setting. I still have yet to figure out which entry, if any, in /proc/interrupts is my soundcard but I'll deal with that when I can.

On 8/25/05, Lee Revell <rlrevell(a)joe-job.com> wrote: Yes, thank you for confirming what I said. There is no realtime-preempt patch for the current stable kernel. You either downgrade or upgrade to 2.6.13 which also can't be patched for amd64.

On 8/26/05, Florian Schmidt <mista.tapas(a)gmx.net> wrote: Why not just download the 2.6.13 tree and use it? Such is what I did. Apparently many people here like to respond to messages/threads without reading them. Whether it builds or is functional on AMD64 is THE issue. It isn't a different issue...it is THE issue for this thread. It is also the very issue of the post you are responding to. This is just getting stupid. I'm done. I never said anything about 2.6.13-rc7. I did state that 2.6.13-rc6 will _not_ compile on amd64 if you attempt to add the RP patch. I also stated that to get RP you have to go with the "unstable" kernel and live with the "almost" RP that you get without the patch, or downgrade from the current stable kernel and apply a patch that works. The only one I had success with is 2.6.11.12. I get lambasted for trying to patch 2.6.13 and now I get lambasted for saying you have to use a pre-current kernel if you want the RP with amd64. I can't win with you people. I am not playing anymore. You all need something better to do with your lives.

On Fri, 26 Aug 2005 20:24:41 +0200 Florian Schmidt <mista.tapas(a)gmx.net> wrote: Actually this isn't really 100% sure :) maybe the patches you tried actually did not apply cleanly (this hasn't happened for a long time for me with Ingo's patches but the probability is probably well above 0). Please forget this last paragraph of my previous mail. Everyone is free to choose the tone of his mailings and my skin should definetly be thicker. Have fun and better luck with future kernels, Flo -- Palimm Palimm! http://tapas.affenbande.org

On Fri, 2005-08-26 at 10:45 -0700, Noah Roberts wrote: Because 2.6.13 does not have the RP patch merged, and I thought the whole point of the thread was "how do I build an RP kernel for AMD64". Lee

On 8/26/05, Lee Revell <rlrevell(a)joe-job.com> wrote: So we are from "terrible idea...why would you..." to "do it like this..." Well, it's an improvement. rc7 seems to be viable on amd64. I did it like above and it worked so I also tried it two different ways to make sure it wasn't something in my procedure that broke it last time...not that it still couldn't be. Downloading the kernel 2.6.13-rc7 and patching it works. Running an emerge on the vanilla sources, which actually does the above, and patching them works (though you have to add ~amd64 to the keywords). I have only tested compilation, I have not booted one yet. So, two days ago with rc6 it couldn't be done the second two ways (didn't try the first). Now with rc7 all the sudden it can. That is odd but not outside the realm of possibility with a "testing" kernel. rc6 blew up in sched.c only a few seconds into a compile complaining about various symbols being undefined and/or redefined, rc7 makes it through with only some deprication warnings that seem to be in all kernels these days. I fully expect it to work fine on bootup. At any rate I now have a few working preemtable kernels. I don't figure on needing another. I'm moving on to figuring other things out. I almost didn't make this one but I figured having a compile report destined for the developer was worth the effort even if it wouldn't work for me...and it ended up working instead.

Lee Revell wrote: happy endings are great :D shayne

Emanuel Rumpf wrote: Have you tried specimen. You just import samples & map them to the keyboard. I am developing quite a fondness for it. http://gazuga.net/ Regards Guy ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

On Mon, 2005-29-08 at 20:26 +0200, Emanuel Rumpf wrote: Would adding proper sf2 support to linuxsampler be that hard? I'm actually somewhat surprised it doesn't have support already.... -DR-

On Mon, 2005-08-22 at 17:25 -0700, Noah Roberts wrote: No, it doesn't have the full RT patch, not even close. It does have some fixes that make it more likely to have good realtime performance than 2.6.12. Maybe you're confusing Ingo's RT preempt kernel patch with the RT rlimits and realtime LSM patches, it's a common mistake. Please check the list archives if you don't understand the difference. Lee

On 8/20/05, Atte André Jensen <atte.jensen(a)gmail.com> wrote: No, not yet. I have used Linux for a long time and never had to deal with that. I frankly don't know anything about getting the best out of an HD with that program. I always let Linux do it since it seemed to do pretty good with it.

On 8/20/05, ix(a)replic.net <ix(a)replic.net> wrote: I'll give that a shot too.