Re: Reason for sound dropouts found
Richard Gooch (rgooch@atnf.csiro.au)
Fri, 12 Mar 1999 20:48:36 +1100
T. Mertes writes:
> The good news:
>
> I found the reason of sound dropouts which happen under
> disk load and are reported from time to time in linux-kernel.
> Statement:
> Dropouts during playing of sound using /dev/dsp and
> related devices using play, sox, cat and other programms
> happen because the read() call of the playing command
> has to wait too long when the system is under disk load.
> So the internal buffer of the sound driver gets empty
> and the driver has to shut the sound card for a short
> time. This is true for all sound cards and drivers.
> 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.
> 2. Every program to play sound should have two threads
> for reading and writing and an internal buffer which never
> gets empty so that after finishing one write() to the
> sound device the next write() can start immidiate without
> delay. --> no dropout
> 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.
> 3. The internal dma buffer of the sound driver could be
> enlarged. When the dma buffer is big enough the sound
> card would play from this buffer during waits for the
> read(). --> no dropout
[...]
> What do the linux kernel specialists think of
> having big sound driver buffers?
I think (2) is the only reasonable solution. It's really easy to solve
this in user space. No reason to allocate huge kernel buffers (3)
which consume RAM. The alternative of (1) has the disadvantage that
you can end up reading stuff that isn't needed, which just delays when
important (required) data can be read.
Check out bplay: it allocates a SHM segment and uses two
processes. It's a bit ugly, as it doesn't use threads, but it
works. There is a variant called tplay which uses threads instead
which is probably better.
Regards,
Richard....
-
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/