Messages in this thread Patch in this message | | | Date | Mon, 15 Mar 1999 22:04:07 +0100 | From | Pavel Machek <> | Subject | Re: Reason for sound dropouts found |
| |
Hi!
> 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.
You _DONT_ have 256MB sound DMA buffer. Apply this one and look how much you _really_ have.
diff -u clean//drivers/sound/dmabuf.c linux/drivers/sound/dmabuf.c --- clean//drivers/sound/dmabuf.c Wed Dec 23 11:16:12 1998 @@ -87,6 +87,7 @@ if (start_addr == NULL) dmap->buffsize /= 2; } + printk( "Sound: allocated %dK buffer\n", dmap->buffsize / 1024 ); if (start_addr == NULL) { printk(KERN_WARNING "Sound error: Couldn't allocate DMA buffer\n");
> 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.
Take a look at sound drivers, they already subdivide DMA buffer into smaller chunks (dmap->nbufs, ...). _Maybe_ it would be possible to make these chunks physically non-contignuous... (It is _not_ trivial, I took a look myself).
Pavel -- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
- 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/
| |