RE: Reason for sound dropouts found

T.Mertes@mobilkom.at
Fri, 12 Mar 1999 14:01:21 +0100

Richard Gooch writes:
> T. Mertes writes:
> > Richard Gooch writes:
> > >
> > > T. Mertes writes:
> > > > 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.
> >
> > A user space solution also needs to have the buffer in the
> > RAM, otherwise it has to wait for swap instead of read().
> > So it may be necessary to lock the user space buffer in RAM.
>
> True, although it's not usually necessary. In any case, the user
space
> solution requires no kernel changes.

I also thought, that enlarging the driver buffer would require
complicated
kernel changes. But now it seems to me that the change of

#define NR_MEM_LISTS 6

to

#define NR_MEM_LISTS 10

in linux/mm/page_alloc.c would be enough in the kernel.
There is a comment in page_alloc.c that for the AP+ (I donīt know
what that is) it needs to allocate 8MB contiguous, aligned
chunks of ram for the ring buffers. So there is already demand for
big buffers. I also remember Alan saying that big buffers are needed
for other drivers (IIRC: video stuff).

In the alsa sound driver a call of __get_free_pages() will get a
different parameter and some ALSA dma data structures get knowledge
that there is e.g 512kB instead of 128kB of dma buffer available.
To my knowledge no big changes. But I need more information
(about ALSA and DMA) to try this.

I also mentioned in my last mail:

Besides, the kernel buffers are freed also when the sound device
is
not used. And the size of the kernel buffer should be
configurable
(like now in ALSA, but on a larger scale). For that reasons I
would
> not rule (3) out.
>
Richard Gooch writes also:

> I Very often you hear the mantra:
> "do it in user space". When you can provide all the functionality
you
> need without sacrificing performance, then I think the correct
place
> is to put things in user space.

I think we should:

1. Improve readahead of sequencially readed files.
2. Create a sound demon which does user space buffering
the way you describe. A sound demon can also solve
the problem of several simultanous accesses to the
sound devices. This sound demon should also have a
good and generally accepted API (To my knowledge
the gnome people work on such a thing. I do not know
if they are also tinking of the dropout problem now).
3. Investigate possibilitys to enlarge the sound buffers of the
drivers.

In total: Provide a solution to the sound dropout problem under
load.

I think we should not:

Rule out possible solutions because of political
reasons. Like:

- The readahead (1) will never be good enough to solve this.
- There will always be competing sound demon (2) APIs and the
communication with the demon can also be delayed due to load.
- Everything (3) which is not user space is kernel bloat.

What I want to say is:

This is not the time to make decisions
This is the time to make different
proposals/suggestions/patches/demons ...

Afterwards the "leader of the free world" (c) will make the
decisions anyway...

Greetings Thomas

-
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/