Messages in this thread | | | From | T.Mertes@mobilkom ... | Subject | RE: Reason for sound dropouts found | Date | Tue, 16 Mar 1999 10:01:00 +0100 |
| |
> Thomas Sailer [SMTP:sailer@ife.ee.ethz.ch] wrote > Pavel Machek wrote: > > > > Daemon would have to be pagelocked and realtime. Pagelocked realtime > > daemon sounds much like kernel code... > > Yes, but with the added benefit of not having to use it.
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/
| |