Messages in this thread | | | From | T.Mertes@mobilkom ... | Subject | RE: Reason for sound dropouts found | Date | Fri, 12 Mar 1999 14:01:21 +0100 |
| |
Richard Gooch writes: > T. Mertes writes: > > Richard Gooch writes: > > > > > > T. Mertes writes: > > > > 1. Greatly improve readahead of sequencially readed files. > > > > The readahead must be so good that the data is always > > > > already in the cache when the read() syscall is > > executed. > > > > In that way the read() would never block. --> no dropout > > > > I know this seems a little bit unrealistic. > > > > 2. Every program to play sound should have two threads > > > > for reading and writing and an internal buffer which > > never > > > > gets empty so that after finishing one write() to the > > > > sound device the next write() can start immidiate > > without > > > > delay. --> no dropout > > > > This could be done also by a sound demon used by all > > > > sound programms. When this user buffer swaps out, > > > > you get your dropouts aggain. > > > > 3. The internal dma buffer of the sound driver could be > > > > enlarged. When the dma buffer is big enough the sound > > > > card would play from this buffer during waits for the > > > > read(). --> no dropout > > > [...] > > > > What do the linux kernel specialists think of > > > > having big sound driver buffers? > > > > > > I think (2) is the only reasonable solution. It's really easy to > > solve > > > this in user space. No reason to allocate huge kernel buffers (3) > > > which consume RAM. > > > > A user space solution also needs to have the buffer in the > > RAM, otherwise it has to wait for swap instead of read(). > > So it may be necessary to lock the user space buffer in RAM. > > True, although it's not usually necessary. In any case, the user space > solution requires no kernel changes.
I also thought, that enlarging the driver buffer would require complicated kernel changes. But now it seems to me that the change of
#define NR_MEM_LISTS 6
to
#define NR_MEM_LISTS 10
in linux/mm/page_alloc.c would be enough in the kernel. There is a comment in page_alloc.c that for the AP+ (I don´t know what that is) it needs to allocate 8MB contiguous, aligned chunks of ram for the ring buffers. So there is already demand for big buffers. I also remember Alan saying that big buffers are needed for other drivers (IIRC: video stuff). In the alsa sound driver a call of __get_free_pages() will get a different parameter and some ALSA dma data structures get knowledge that there is e.g 512kB instead of 128kB of dma buffer available. To my knowledge no big changes. But I need more information (about ALSA and DMA) to try this.
I also mentioned in my last mail:
Besides, the kernel buffers are freed also when the sound device is not used. And the size of the kernel buffer should be configurable (like now in ALSA, but on a larger scale). For that reasons I would > not rule (3) out. > Richard Gooch writes also:
> I Very often you hear the mantra: > "do it in user space". When you can provide all the functionality you > need without sacrificing performance, then I think the correct place > is to put things in user space.
I think we should:
1. Improve readahead of sequencially readed files. 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). 3. Investigate possibilitys to enlarge the sound buffers of the drivers.
In total: Provide a solution to the sound dropout problem under load.
I think we should not:
Rule out possible solutions because of political reasons. Like:
- The readahead (1) will never be good enough to solve this. - There will always be competing sound demon (2) APIs and the communication with the demon can also be delayed due to load. - Everything (3) which is not user space is kernel bloat.
What I want to say is:
This is not the time to make decisions This is the time to make different proposals/suggestions/patches/demons ...
Afterwards the "leader of the free world" (c) will make the decisions anyway...
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/
| |