Subject: Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Tue Jul 13 2004 - 16:26:53 EEST
Lee Revell wrote:
>On Mon, 2004-07-12 at 19:31, Andrew Morton wrote:
>
>
>>
>>OK, thanks. The problem areas there are the timer-based route cache
>>flushing and reiserfs.
>>
>>We can probably fix the route caceh thing by rescheduling the timer after
>>having handled 1000 routes or whatever, although I do wonder if this is a
>>thing we really need to bother about - what else was that machine up to?
>>
>>
>>
>
>Gnutella client. Forgot about that. I agree, it is not reasonable to
>expect low latency with this kind of network traffic happening. I am
>impressed it worked as well as it did.
>
>
Why not reasonable ? It is very important that networking and HD I/O
both don't interfere with low latency audio.
Think about large audio setups where you use PC hardware to act as
dedicated samplers, software synthesizers etc.
Such clusters might be diskless and communicate with a GBit ethernet
with a high performance file server and
in some cases lots of network I/O might occur during audio playback. So
having latency spikes during network I/O
would be a big showstopper for many apps in certain setups.
Even ardour if run on a diskless client would need low latency while
doing network I/O because it does lots of disk I/O
which on the diskless client translate to lots of network I/O.
Typical use could be educational or research institutions where diskless
clients drastically lower the cost of managing large number
of boxes and allow sharing of resources. See the LTSP project.
Other low latency while high network I/O uses are video conferencing
applications, diskless settop boxes that stream
videos over IP etc.
Therefore low level network kernel develeopers think about us poor real
time multimedia souls :)
cheers,
Benno
http://www.linuxsampler.org
This archive was generated by hypermail 2b28 : Tue Jul 13 2004 - 16:28:28 EEST