Does anybody on this list have a lot of experience identifying sources of scheduling latency in the kernel? I've got an old laptop that I'm trying to make realtime audio safe, and I've run into a wall. I'm running Gentoo with 2.6.29.4-rt15, and no matter how large I make my audio buffers, I still get periodic xruns. I'll start with my system specs: Mobile Athlon 4 1GHz (ample speed for my application) 512MB PC-133 RAM 60GB 5400RPM hard drive USB audio interface through a PCMCIA USB adapter XFS root filesystem jackd 0.116.2 I've tried just about everything I can think of. I moved from kernel 2.6.28 with the Gentoo patches to vanilla 2.6.29 with realtime patches, and that helped. I've disabled swap, tried stopping all services (including cron, metalog, etc.), using the laptop's integrated sound, and there are always xruns, even with no clients connected to jackd and no system load. I modified jack to print the current date and time, number of xruns, and time in seconds since the last xrun to stderr and to syslog each time an xrun occurs. The xruns happen pretty regularly. When I used a smaller buffer size (256 samples, 3 periods) I would get an xrun about every minute, but the interval was always a multiple of 30 seconds. With my current settings (2048 samples, 3 period), I get an xrun every ~1.3 hours (~4500 to 5000 seconds apart). I thought maybe a service was running periodically that was freezing the kernel, so I added syslog logging to jack and tried disabling all services, but there was no correlation that I could see. I thought maybe disk I/O was the problem, so I stopped all disk writing processes and enabled laptop mode. I also disabled the framebuffer, but the framebuffer is not the culprit. I disabled CPU frequency scaling and power management. So far, I can't eliminate the xruns, I can just make them less frequent. Since I couldn't get jack to reach 100% reliability, I tried digging deeper. I ran a test with cyclictest from the realtime Linux wiki in single-user mode. With a 500us period, my average scheduling latency is 20us, but every few minutes a single test will take significantly longer (in the thousands of us, up to 10ms), even at priority 99, which is the highest priority. Latencytop wasn't very useful. The arrow keys don't work properly in a native console (they work okay in an xterm), and it showed no results for cyclictest or jackd. I tried some other tests, but couldn't get useful results from them. Having done all this, does anybody have any recommendations? I thought it was possible to get a direct stack trace of the highest-latency execution path in the kernel. Is that possible, and if so, how do I do it? I'd really like to identify the cause directly rather than just keep changing things until something works. If I can't find the direct cause, I plan on switching to ext3 or ext4, and if that doesn't work, I'll begin disabling everything I have compiled directly into my kernel (PS/2 mouse support, other filesystems, etc.). I'd much rather find the actual cause of the problem and solve it, though. I do have some kernel and alsa development experience. Thanks in advance, Mike Bourgeous ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
