When you play sound you need some memory to queue. Memory
usage would be the same for user and kernel. The actual buffer
handling code can be very small and maybe there is already
some queue handling code which can be used. And, if you have a
buffer queue in the kernel the actual DMA buffer can be smaller,
because it can be refilled from the buffer queue quickly. This could
help also in some of the DMA area allocation problems.
> In the case of mp3 playback, it's much better to do the buffering
> on the input side to the decompressor, not at the output side,
> as you can do 10 times the buffering with the same amount of
memory.
Yes, in case of mp3 playback you are right. But there are a lot of
formats,
and a device should work good for all of them.
For me the different solutions for sound dropouts look now like:
1. great readahead improvement: Not easy. Ingo Molnar mailed me
a small patch, I have not tried out until now. Silly me!
2. Buffering in playing program/demon: Locking the pages and
realtime priority seems necessary. And there are a lot of
playing programs/demons existing. It seems not to be easy
to rewrite all/most of them. Remember: People like to use
their playing program. And there are also different
environments (GNOME, KDE, ... ) which also have different
philosophies.
3. Buffering in the driver:
a) Enlarging the DMA buffers has limits
- Allocation of big continous memory may not be possible
due to memory fragmentation.
- There are also hardware limitations. For example:
The SB 128 PCI card allowes only up to 256 MB of
DMA buffer.
b) A queue of page sized buffers in front of the DMA buffer
seems reasonable:
- It can be used in the generic part of the sound driver.
- It may allow the DMA area to be smaller. This would
avoid problems of DMA allocation due to memory
fragmentation.
- Maybe a buffer queue mechanism is already in the
kernel. I can think of several possible usages of such
a queue.
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/