Hi all. I'm trying to track the cause of high scheduling latency peaks in FC2 that make the system unusable for low latency audio work.
Test systems: PIV laptop, radeon video chipset, AMD64 desktop, radeon video chipset. How I test: I run the Jack (Jack Audio Connection Kit) sound server with 2 or 3 128 frame buffers for low latency operation through the Qjackctl gui front-end. I then start GUI apps that use Jack (for example Freqtweak, Hydrogen and Jamin). I see plenty of buffer xruns of varying durations during the app load process and afterwards. The same (laptop) system booting FC1 + XFree + 2.4.26 + low latency patches has rock solid performance and no xruns in the same conditions. If I boot FC2 into 2.4.26 + low latency patches I _still_ see xruns, so it looks like the kernel itself is not triggering them. At least not all of them.
I have no hard data but the xruns appear to coincide with X activity. If I turn off video acceleration I see _more_ xruns (significantly more). If I switch to the vesa driver I still see xruns (so it would seem that the radeon driver itself is not to blame).
Does anyone out there know if something has changed between XFree and xorg that may account for this change in behavior?
Thanks for _any_ help.... (I also tried several other configuration options for xorg.conf with no effect whatsoever[*]).
-- Fernando
[*] and even tried to downgrade to FC1's XFree86 just to see if I could isolate the cause but the result was too unstable and messy to draw any conclusions :-)
On Thu, 2004-05-27 at 17:25, Fernando Pablo Lopez-Lezcano wrote:
Hi all. I'm trying to track the cause of high scheduling latency peaks in FC2 that make the system unusable for low latency audio work.
Test systems: PIV laptop, radeon video chipset, AMD64 desktop, radeon video chipset. How I test: I run the Jack (Jack Audio Connection Kit) sound server with 2 or 3 128 frame buffers for low latency operation through the Qjackctl gui front-end. I then start GUI apps that use Jack (for example Freqtweak, Hydrogen and Jamin). I see plenty of buffer xruns of varying durations during the app load process and afterwards.
More data I forgot to include: Jack is running with SCHED_FIFO priority. For achieving that I run a custom kernel (currently based on Arjan's 1.391) with preempt enabled and the realcap kernel module (by Jack O'Quin) added. I also run an up to date version of ALSA with full debugging enabled so that I can get kernel stack traces when xruns occur.
-- Fernando
On Fri, 2004-05-28 at 02:39, Fernando Pablo Lopez-Lezcano wrote:
On Thu, 2004-05-27 at 17:25, Fernando Pablo Lopez-Lezcano wrote:
Hi all. I'm trying to track the cause of high scheduling latency peaks in FC2 that make the system unusable for low latency audio work.
Test systems: PIV laptop, radeon video chipset, AMD64 desktop, radeon video chipset. How I test: I run the Jack (Jack Audio Connection Kit) sound server with 2 or 3 128 frame buffers for low latency operation through the Qjackctl gui front-end. I then start GUI apps that use Jack (for example Freqtweak, Hydrogen and Jamin). I see plenty of buffer xruns of varying durations during the app load process and afterwards.
More data I forgot to include: Jack is running with SCHED_FIFO priority. For achieving that I run a custom kernel (currently based on Arjan's 1.391) with preempt enabled and the realcap kernel module (by Jack O'Quin) added.
can you disable preempt? That should improve latencies....
On Thu, 2004-05-27 at 22:58, Arjan van de Ven wrote:
On Fri, 2004-05-28 at 02:39, Fernando Pablo Lopez-Lezcano wrote:
On Thu, 2004-05-27 at 17:25, Fernando Pablo Lopez-Lezcano wrote:
Hi all. I'm trying to track the cause of high scheduling latency peaks in FC2 that make the system unusable for low latency audio work.
Test systems: PIV laptop, radeon video chipset, AMD64 desktop, radeon video chipset. How I test: I run the Jack (Jack Audio Connection Kit) sound server with 2 or 3 128 frame buffers for low latency operation through the Qjackctl gui front-end. I then start GUI apps that use Jack (for example Freqtweak, Hydrogen and Jamin). I see plenty of buffer xruns of varying durations during the app load process and afterwards.
More data I forgot to include: Jack is running with SCHED_FIFO priority. For achieving that I run a custom kernel (currently based on Arjan's 1.391) with preempt enabled and the realcap kernel module (by Jack O'Quin) added.
can you disable preempt? That should improve latencies....
I'll try that and report back. A while back - probably 2.6.4-1.279 or whereabouts - I did a comparison (because of reports that it should be better that preempt be off) and latencytest reported better latencies with preempt on. Maybe something has changed since then (or I made some silly mistake).
-- Fernando
On Fri, 2004-05-28 at 11:01, Fernando Pablo Lopez-Lezcano wrote:
On Thu, 2004-05-27 at 22:58, Arjan van de Ven wrote:
On Fri, 2004-05-28 at 02:39, Fernando Pablo Lopez-Lezcano wrote:
On Thu, 2004-05-27 at 17:25, Fernando Pablo Lopez-Lezcano wrote:
Hi all. I'm trying to track the cause of high scheduling latency peaks in FC2 that make the system unusable for low latency audio work.
Test systems: PIV laptop, radeon video chipset, AMD64 desktop, radeon video chipset. How I test: I run the Jack (Jack Audio Connection Kit) sound server with 2 or 3 128 frame buffers for low latency operation through the Qjackctl gui front-end. I then start GUI apps that use Jack (for example Freqtweak, Hydrogen and Jamin). I see plenty of buffer xruns of varying durations during the app load process and afterwards.
More data I forgot to include: Jack is running with SCHED_FIFO priority. For achieving that I run a custom kernel (currently based on Arjan's 1.391) with preempt enabled and the realcap kernel module (by Jack O'Quin) added.
can you disable preempt? That should improve latencies....
It does not (in my tests), quite the reverse.
I'll try that and report back.
Preempt does not make any difference to the problem I'm seeing. First some pretty pictures. This is the result of running latencytest 0.5.3 (patched to compile with the newer kernels):
a) 2.6.6-1.391 with preempt on: http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.1.ll.rhfc2...
b) 2.6.6-1.391 with preempt off: http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.2.ll.rhfc2...
c) 2.6.6-1.391 with preempt off and bad radeon latency patch (see comments below): http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.3.ll.rhfc2...
d) 2.6.6-1.391 with preempt on and bad radeon latency patch: http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.4.ll.rhfc2...
Some comments: it would seem to me that preempt does make a difference, the latency spikes tend to be smaller, as I would expect (at least in what latencytest measures).
In [c] and [d] I'm applying an additional latency patch to the drm kernel driver that affects radeon, r128 and mga based cards. The patch is old and _illegal_ as it does reschedules with a lock on. So far the computer has not locked up but I guess it is a matter of time :-) Without this patch or an equivalent properly done patch a computer with a radeon (or r128/mga) chipset is useless for low latency audio.
Now, you could say that the graphs look pretty good. And I would agree. Regretfully latencytest is not all there is.
A real test with the Jack low latency server reveals that something else is creating latency hits. This is an example of what I see if I start jack inside qjackctl (a gui frontend) and after it is running I start freqtweak, BTW I get similar results running any of the aforementioned kernel builds (jack is running SCHED_FIFO, with 4 buffers of 128 frames in this example):
======== 17:24:09.745 Startup script... 17:24:09.745 artsshell -q terminate 17:24:10.015 Startup script terminated with exit status=256. 17:24:10.015 JACK is starting... 17:24:10.016 /usr/bin/jackstart -R -dalsa -dhw:0 -r48000 -p128 -n4 17:24:10.022 JACK was started with PID=3051 (0xbeb). back from read, ret = 1 errno == Success jackd 0.98.0 Copyright 2001-2003 Paul Davis and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details loading driver .. apparent rate = 48000 creating alsa driver ... hw:0|hw:0|128|4|48000|0|0|nomon|swmeter|-|32bit control device hw:0 configuring for 48000Hz, period = 128 frames, buffer = 4 periods Couldn't open hw:0 for 32bit samples trying 24bit instead Couldn't open hw:0 for 24bit samples trying 16bit instead Couldn't open hw:0 for 32bit samples trying 24bit instead Couldn't open hw:0 for 24bit samples trying 16bit instead 17:24:12.101 Server configuration saved to "/home/nando/.jackdrc" 17:24:12.102 Statistics reset. 17:24:12.452 Client activated. 17:24:12.454 Audio connection change. subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=14, status = 0, state = Triggered) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=14, status = 0, state = Triggered) **** alsa_pcm: xrun of at least 0.115 msecs 17:24:12.494 Audio connection graph change. **** alsa_pcm: xrun of at least 16.162 msecs subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=14, status = 0, state = Triggered) 17:24:12.507 XRUN callback. (1) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=14, status = 0, state = Triggered) **** alsa_pcm: xrun of at least 0.096 msecs 17:24:12.515 XRUN callback. (2) **** alsa_pcm: xrun of at least 2.575 msecs 17:24:12.524 XRUN callback. (3) 17:24:12.528 XRUN callback. (4) 17:31:48.938 Audio connection graph change. 17:31:49.064 Audio connection change. 17:31:49.454 Audio connection graph change. subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Finished) delay of 1291.000 usecs exceeds estimated spare time of 1207.000; restart ... 17:31:49.996 XRUN callback. (5) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Finished) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Triggered) **** alsa_pcm: xrun of at least 2.380 msecs 17:31:50.024 XRUN callback. (6) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Finished) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Finished) delay of 1338.000 usecs exceeds estimated spare time of 1207.000; restart ... 17:31:50.027 XRUN callback. (7) 17:31:50.037 XRUN callback. (8) **** alsa_pcm: xrun of at least 3.733 msecs 17:31:50.047 XRUN callback. (9) **** alsa_pcm: xrun of at least 2.054 msecs subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Finished) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Finished) **** alsa_pcm: xrun of at least 0.993 msecs 17:31:52.148 XRUN callback. (10) **** alsa_pcm: xrun of at least 11.116 msecs 17:31:52.164 XRUN callback. (11) ========
.... and so on and so forth.
So, latencytest is happy but a real test with real applications is not.
Other important data points:
- xruns seem to be related to graphics activity - booting FC2 into 2.4.26 with the low latency and preempt patches gives me similar results (latency hits when running jack and jack apps) - booting FC1 into 2.4.26 (same hardware, just replace the hard disk) gives me a rock solid system (no xruns whatsoever, down to 128x2).
So, it would seem to me that it is not (only) the kernel..........
Things I could not make work: - testing 2.6.6-1.391.x in FC1. For some reason init does not get executed, probably a library problem somewhere...
Other stuff I tried: - getting a better irq for the audio card (on a desktop) - trying to tune pci latencies
Any ideas on what could cause this????
Please keep in mind that I can use FC1 with 2.4.26 on the exact same hardware and it works just fine...
-- Fernando
a) 2.6.6-1.391 with preempt on: http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.1.ll.rhfc2...
85.8% is in the 1ms range
b) 2.6.6-1.391 with preempt off: http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.2.ll.rhfc2...
87.9% is in the 1ms range
so somewhat better
c) 2.6.6-1.391 with preempt off and bad radeon latency patch (see comments below): http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.3.ll.rhfc2...
ohhh interesting
I will be looking at the patch and see if I can fix it up.. the results look spiffy.
On Wed, 2004-06-02 at 00:32, Arjan van de Ven wrote:
a) 2.6.6-1.391 with preempt on: http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.1.ll.rhfc2...
85.8% is in the 1ms range
b) 2.6.6-1.391 with preempt off: http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.2.ll.rhfc2...
87.9% is in the 1ms range
so somewhat better
I guess beauty is in the eyes of the beholder :-) More peaks are within the 1ms range _but_ the actual peaks that get through are larger without preempt. The smaller the peaks the smaller the risk that an actual xrun will happen (more "slack"). Regretfully it takes just one xrun to get an audible click in the audio output.
c) 2.6.6-1.391 with preempt off and bad radeon latency patch (see comments below): http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.3.ll.rhfc2...
ohhh interesting
I will be looking at the patch and see if I can fix it up.. the results look spiffy.
They do. More comments in the next email. -- Fernando
In [c] and [d] I'm applying an additional latency patch to the drm kernel driver that affects radeon, r128 and mga based cards. The patch is old and _illegal_ as it does reschedules with a lock on. So far the computer has not locked up but I guess it is a matter of time :-)
can you send me that patch (or point at an URL) ?
A real test with the Jack low latency server reveals that something else is creating latency hits.
do you run Jack as realtime process ??
So, latencytest is happy but a real test with real applications is not.
it might be an application artifact/interaction
Other important data points:
- xruns seem to be related to graphics activity
- booting FC2 into 2.4.26 with the low latency and preempt patches gives
me similar results (latency hits when running jack and jack apps)
- booting FC1 into 2.4.26 (same hardware, just replace the hard disk)
gives me a rock solid system (no xruns whatsoever, down to 128x2).
So, it would seem to me that it is not (only) the kernel..........
Things I could not make work:
- testing 2.6.6-1.391.x in FC1. For some reason init does not get
executed, probably a library problem somewhere...
you need to pass vdso=0 to the kernel there.
Any ideas on what could cause this????
try disabling DRI.
DRI sometimes can "hold" the pci bus for quite some time, which by definition causes latency since no IO can be done
On Wed, 2004-06-02 at 00:38, Arjan van de Ven wrote:
In [c] and [d] I'm applying an additional latency patch to the drm kernel driver that affects radeon, r128 and mga based cards. The patch is old and _illegal_ as it does reschedules with a lock on. So far the computer has not locked up but I guess it is a matter of time :-)
can you send me that patch (or point at an URL) ?
Sure, find them attached... If you apply the patches and enable the kernel option that detects scheduling with locks held you will get an oops.
I had a private thread with Andrew Morton, Takashi Iwai and Dave Airlie about this issue. Dave floated it in the dri list and did some research but there was no firm conclusion (a few suggestions but no patch to test). I should contact them again. The dri list apparently thought that things like this would cause stuttering in the video card. Goes without saying that probably they think that dropouts and clicks in the audio can be ignored :-) ;-) :-) I suggested maybe a runtime kernel option could be used to satisfy both camps.
A real test with the Jack low latency server reveals that something else is creating latency hits.
do you run Jack as realtime process ??
Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap module to grant non-root users those privileges (compiled as a module in the kernel).
Just occured to me, is there anything else in FC2 that may be running SCHED_FIFO?? I'll try to find out.
So, latencytest is happy but a real test with real applications is not.
it might be an application artifact/interaction
It might be, but do we find out with what? See below for why I think it may be the video output.
Other important data points:
- xruns seem to be related to graphics activity
- booting FC2 into 2.4.26 with the low latency and preempt patches gives
me similar results (latency hits when running jack and jack apps)
- booting FC1 into 2.4.26 (same hardware, just replace the hard disk)
gives me a rock solid system (no xruns whatsoever, down to 128x2).
So, it would seem to me that it is not (only) the kernel..........
Things I could not make work:
- testing 2.6.6-1.391.x in FC1. For some reason init does not get
executed, probably a library problem somewhere...
you need to pass vdso=0 to the kernel there.
Great, thanks, I'll test this later, it could help determine if the problem is in the kernel or not...
Any ideas on what could cause this????
try disabling DRI.
I tried almost every combination of xorg parameters I could think of. Disabling DRI makes matter much _worse_! This is one of the reasons why I think the culprit is xorg or something in the video rendering chain. With DRI on I get fewer xruns, with DRI off I get tons of them (I think they were shorter). I could rationalize this by thinking that the "high end" primitives get broken down into smaller chunks of more basic graphic primitives and then each one of them is doing something that causes an xrun. No facts to support this, of course.
DRI sometimes can "hold" the pci bus for quite some time, which by definition causes latency since no IO can be done
Yes. I also tried changing the bus latency for the different "cards" in the laptop using setpci. No change. I could get better overall performance (ie: the screen would update faster with the xrun information :-)
-- Fernando
A real test with the Jack low latency server reveals that something else is creating latency hits.
do you run Jack as realtime process ??
Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap module to grant non-root users those privileges (compiled as a module in the kernel).
Just occured to me, is there anything else in FC2 that may be running SCHED_FIFO?? I'll try to find out.
Using schedutils (chrt) I find no tasks or threads running SCHED_FIFO. And the realtime threads of jack are apparently running SCHED_FIFO. Argh, that would have been too easy :-)
-- Fernando
On Wed, Jun 02, 2004 at 11:28:20AM -0700, Fernando Pablo Lopez-Lezcano wrote:
A real test with the Jack low latency server reveals that something else is creating latency hits.
do you run Jack as realtime process ??
Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap module to grant non-root users those privileges (compiled as a module in the kernel).
Just occured to me, is there anything else in FC2 that may be running SCHED_FIFO?? I'll try to find out.
Using schedutils (chrt) I find no tasks or threads running SCHED_FIFO. And the realtime threads of jack are apparently running SCHED_FIFO. Argh, that would have been too easy :-)
can you try to NOT run it realtime? Sounds odd but when you use realtime behavior you have to be really careful for priority inversion situations (eg if X doesn't run at such a high prio, but your RT task needs to wait on X to draw something..)
On Wed, 2004-06-02 at 11:34, Arjan van de Ven wrote:
On Wed, Jun 02, 2004 at 11:28:20AM -0700, Fernando Pablo Lopez-Lezcano wrote:
A real test with the Jack low latency server reveals that something else is creating latency hits.
do you run Jack as realtime process ??
Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap module to grant non-root users those privileges (compiled as a module in the kernel).
Just occured to me, is there anything else in FC2 that may be running SCHED_FIFO?? I'll try to find out.
Using schedutils (chrt) I find no tasks or threads running SCHED_FIFO. And the realtime threads of jack are apparently running SCHED_FIFO. Argh, that would have been too easy :-)
can you try to NOT run it realtime?
Sure, just tried that. Lots _more_ xruns, move around the mouse, xruns, switch windows, xruns :-)
Sounds odd but when you use realtime behavior you have to be really careful for priority inversion situations (eg if X doesn't run at such a high prio, but your RT task needs to wait on X to draw something..)
Aha! I think you are on to something! I double checked the priority of the jack clients and _they_ are not getting SCHED_FIFO!! They should be getting that priority from the jack server but they are not (and the jack server is not complaining at all so no error is being raised). Probably some change in glibc, I would think... (remember, this is all working perfectly in < FC2).
That's probably the cause of the xruns. Now I have to find out why... (I also have to test 2.6.x under FC1 with the trick you mentioned earlier in the thread).
Thanks! -- Fernando
On Wed, 2004-06-02 at 12:11, Fernando Pablo Lopez-Lezcano wrote:
On Wed, 2004-06-02 at 11:34, Arjan van de Ven wrote:
On Wed, Jun 02, 2004 at 11:28:20AM -0700, Fernando Pablo Lopez-Lezcano wrote:
A real test with the Jack low latency server reveals that something else is creating latency hits.
do you run Jack as realtime process ??
Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap module to grant non-root users those privileges (compiled as a module in the kernel).
Just occured to me, is there anything else in FC2 that may be running SCHED_FIFO?? I'll try to find out.
Using schedutils (chrt) I find no tasks or threads running SCHED_FIFO. And the realtime threads of jack are apparently running SCHED_FIFO. Argh, that would have been too easy :-)
can you try to NOT run it realtime?
Sure, just tried that. Lots _more_ xruns, move around the mouse, xruns, switch windows, xruns :-)
Sounds odd but when you use realtime behavior you have to be really careful for priority inversion situations (eg if X doesn't run at such a high prio, but your RT task needs to wait on X to draw something..)
Aha! I think you are on to something! I double checked the priority of the jack clients and _they_ are not getting SCHED_FIFO!! They should be getting that priority from the jack server but they are not (and the jack server is not complaining at all so no error is being raised). Probably some change in glibc, I would think...
Before (or rather while) I start banging my head again against sched_setscheduler and friends, could this be related to selinux even though it is turned off? None of the calls that are supposed to give the client thread SCHED_FIFO are (apparently) returning errors...
-- Fernando
[to the Jack Devel list readers: this is the tail end of a thread in which I was trying to get help to debug xruns under FC2/2.6.6/xorg - turns out that pthread_create was not doing the same thing as before :-]
A real test with the Jack low latency server reveals that something else is creating latency hits.
do you run Jack as realtime process ??
Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap module to grant non-root users those privileges (compiled as a module in the kernel).
Just occured to me, is there anything else in FC2 that may be running SCHED_FIFO?? I'll try to find out.
Using schedutils (chrt) I find no tasks or threads running SCHED_FIFO. And the realtime threads of jack are apparently running SCHED_FIFO. Argh, that would have been too easy :-)
can you try to NOT run it realtime?
Sure, just tried that. Lots _more_ xruns, move around the mouse, xruns, switch windows, xruns :-)
Sounds odd but when you use realtime behavior you have to be really careful for priority inversion situations (eg if X doesn't run at such a high prio, but your RT task needs to wait on X to draw something..)
Aha! I think you are on to something! I double checked the priority of the jack clients and _they_ are not getting SCHED_FIFO!! They should be getting that priority from the jack server but they are not (and the jack server is not complaining at all so no error is being raised). Probably some change in glibc, I would think...
Just confirmed this with a first preliminary hack (and test). Jack creates new threads and to do that it sets up a pthread_attr_t struct and uses pthread_attr_setschedpolicy and pthread_attr_setscope to set the scheduling policy (and also sets the priority) in the struct. Then pthread_create is called (with that struct as an argument) and the thread is created. But the thread created is _not_ SCHED_FIFO and there is no error return. If _after_ the thread is created I double check the scheduling policy and use pthread_setschedparam to again set it to SCHED_FIFO then the thread changes to SCHED_FIFO... go figure...
The previous behavior was different (< FC2). If pthread_create could not create the thread with the right scheduling then an error would be returned (and another hack would be activated in the code to take into account another failure of glibc to do things properly :-)
Anyway, so the kernel is not at fault and graphics are not at fault.
Suggestions on how to proceed? I have a hack I just tested for a minute and with that the xruns are apparently gone. It would be better to try to trace this to the real source of the problem.
Thanks very much for the help, specially to Arjan for steering me in the right direction. As usual what kills you are the assumptions :-(
-- Fernando
On Wed, Jun 02, 2004 at 10:35:44AM -0700, Fernando Pablo Lopez-Lezcano wrote:
DRI sometimes can "hold" the pci bus for quite some time, which by definition causes latency since no IO can be done
Yes. I also tried changing the bus latency for the different "cards" in the laptop using setpci. No change. I could get better overall performance (ie: the screen would update faster with the xrun information :-)
This is true in the non DRI case too. Several card designs can lock the bus for considerable periods of time and there is nothing Linux can do about these cases. In the Matrox case its configurable (see man mga) I don't know about the others.
Alan
Things I could not make work:
- testing 2.6.6-1.391.x in FC1. For some reason init does not get
executed, probably a library problem somewhere...
you need to pass vdso=0 to the kernel there.
I finally built a version of the 2.6.6 kernel that boots on FC1 with vdso=0. I still see ALSA xruns while using Jack with realtime scheduling (booting into 2.4.26 gives me rock solid performance in the same machine / distro).
Does the "nosysinfo" kernel boot option still turn off nptl globally?[*] -- Fernando
[*] others running 2.6.6 in Debian have also found problems with 2.6.6, some of them where solved by disabling nptl with the LD_ASSUME_KERNEL environment variable.
Fernando Pablo Lopez-Lezcano wrote:
On Thu, 2004-05-27 at 17:25, Fernando Pablo Lopez-Lezcano wrote:
Hi all. I'm trying to track the cause of high scheduling latency peaks in FC2 that make the system unusable for low latency audio work.
I'm guessing that is why Planet CCRMA hasn't announced a full Fedora Core 2 release yet?
Peace, William
On Sat, 2004-06-05 at 16:58, William M. Quarles wrote:
Fernando Pablo Lopez-Lezcano wrote:
On Thu, 2004-05-27 at 17:25, Fernando Pablo Lopez-Lezcano wrote:
Hi all. I'm trying to track the cause of high scheduling latency peaks in FC2 that make the system unusable for low latency audio work.
I'm guessing that is why Planet CCRMA hasn't announced a full Fedora Core 2 release yet?
That is correct. There was an internal announcement in the Planet CCRMA list and most of the packages are built and downloadable. I'm obviously recommending to not upgrade until this has been solved.
The actual cause has been tracked to a problem in the nptl threading library and the jack audio server. The jack client audio threads are not being created with SCHED_FIFO (as requested) and the pthread_create function does not signal any error. I have to work on a workaround.
-- Fernando
-
Alan Cox -
Arjan van de Ven -
Fernando Lopez-Lezcano -
William M. Quarles