Messages in this thread | | | From | T.Mertes@mobilkom ... | Subject | RE: Reason for sound dropouts found | Date | Mon, 15 Mar 1999 18:03:59 +0100 |
| |
> 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/
| |