lkml.org 
[lkml]   [1999]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Reason for sound dropouts found
Date


> Pavel Machek [SMTP:pavel@bug.ucw.cz] wrote:
> Hi!
>
> > I think we should:
> >
> > 1. Improve readahead of sequencially readed files.
>
> Get splay from http://adam.kaist.ac.kr/~jwj95/splay-0.8.2.tar.gz.
Then
> you'll see readahead will not help.
>
> > 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).
>
> Daemon would have to be pagelocked and realtime. Pagelocked
realtime
> daemon sounds much like kernel code...
>
> > 3. Investigate possibilitys to enlarge the sound buffers
of the
> > drivers.
>
> ...which is good reason to put it into kernel. DONT enlarge sound
> buffers of drivers - they need to be physically contignuous.
>
> Instead add one layer with linklist of 4K buffers (see my prev
mail).

I can only agree.
This seems to be reasonable. But I suggest to investigage
the other ways further. Just to be fair to all solutions and to
have a good, instead of a "political" solution. I argumented
also for investigation of all solutions when the "everything
in user area" arguments came.

But as I told in another mail: I want to investigate the
driver buffer solution first:

I found out that the size of DMA memory is, for example
also limited for the SB 128 PCI card by 256MB. And with
256MB sound DMA buffer I still have dropouts under disk
load. So just enlarging the DMA buffer is not sufficient as
solution.

A linklist of 4K buffers (buffer queue) seems necessary.
And as you pointed out the buffers have to be locked in
memory and the access must be realtime. The buffers
can be requested and freed dynamical on open/close or
with usage. This way memory is only used when the
sound device is used.

Is there already some 4K linklist of buffers system in the
kernel that can be used (code reuse is a good weapon
aggainst kernel bloat)? I guess that the buffer cache is
too much filesystem related.

I looked into the alsa driver and was impressed.
Very structured, very systematic.
From what I saw I think that there are only a few
places where a buffer queue has to interface.

Something like:

write_to_buffer_queue(queue, char *data, int length,
int *hi_reached);
read_from_buffer_queue(queue, char *data, int length,
int *lo_reached);

Just a rough idea ...
hi/low_reached can also be return values
Also some:

open_buffer_queue(queue, int hi_mark, int low_mark)
close_buffer_queue(queue)
empty_buffer_queue(queue)

seems necessary.
And of course it needs to interface with the alsa and
the oss sound drivers. From first sight:
- In the alsa driver it seems to be possible that the
buffer_queue can be called from the generic part
of the driver (not shure about this).
- For the oss driver I don't know.

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/

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