lkml.org 
[lkml]   [2004]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
    From
    Date
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:04    [W:4.128 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site