[SNIP dropouts are due to the sound data not being
available]
> Solution(s):
>
> There are several ways to solve this problem:
>
> 1. Greatly improve readahead of sequencially readed files.
> The readahead must be so good that the data is always
> already in the cache when the read() syscall is executed.
> In that way the read() would never block. --> no dropout
> I know this seems a little bit unrealistic.
The readahead is good enough. The problem we have is that,
although the data IS read ahead of time, the data is kicked
out of memory again when we need the data.
On some single-disk systems, you might be right though...
> 2. Every program to play sound should have two threads
> for reading and writing
> This could be done also by a sound demon used by all
> sound programms. When this user buffer swaps out,
> you get your dropouts aggain.
The sound daemon (or even a kernel thread with network
interfacing, etc.) has my personal preference. For one,
it doesn't require modification of every single process
and secondly it could give us more flexibility in where
we can send the sound (calculate mp3 in cellar, send
sound to whisper 486 on desktop).
> What do the linux kernel specialists think of
> having big sound driver buffers?
Having multiple sound buffers which get remapped on
the fly might be far better...
regards,
Rik -- Open Source: you deserve to be in control over your own data.
+-------------------------------------------------------------------+
| Linux Memory Management site: http://humbolt.geo.uu.nl/Linux-MM/ |
| Nederlandse Linux documentatie: http://www.nl.linux.org/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/