Messages in this thread | | | Subject | Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch | From | Lee Revell <> | Date | Sat, 24 Jul 2004 18:49:11 -0400 |
| |
On Sat, 2004-07-24 at 02:43, Ingo Molnar wrote: > * Lee Revell <rlrevell@joe-job.com> wrote: > > > jackd was running in the background in both cases. With 1024KB, there > > were massive XRUNS, and worse, occasionally the soundcard interrupt > > was completely lost for tens of milliseconds. This is what I would > > expect if huge SG lists are being built in hardirq context. With > > 16KB, jackd ran perfectly, the highest latency I was was about 100 > > usecs. > > > > Kernel is 2.6.8-rc2 + voluntary-preempt-I4. CPU is 600Mhz, 512MB RAM. > > ok, i'll put in a tunable for the sg size. >
I tested this with every power of two from 16KB to 1024KB. The current default on my system is 1024KB. This may be affected by disk controller or other factors, someone else reported a default of 128KB with the same drive. Using jackd at the lowest reasonable latency setting (32 frames/period at 48000 frames/sec = 666 usecs/period ), the highest value that does not cause problems is 256KB. The maximum latency spike I saw with this setting was ~220 usecs.
For anyone unfamiliar, if jackd detects that it has been delayed by more than half a period it considers this an error condition because even though there was not an XRUN, it probably does not have enough time left to process a block of audio, and even if it did, it would probably not get scheduled in time to deliver it (IOW there would be an XRUN on the next write) so it restarts.
I therefore propose 256KB as a good default for a low latency system once this is made tunable. This might be a good default for any system, I am not sure under what conditions this would be a bottleneck, but for example this would let you handle multiple NFS clients using 8K or even 32K block sizes without compromising latency. For a single-user, audio-centric system like a DAW, I would go as low as possible until you see disk throughput start to drop, 16KB works well for me.
You would want this as high as possible for, say, a CD burner, but I don't see the point is going as high as 1024KB for a disk drive.
Lee
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |