[Linux-bruxelles] Linux-Kernel Archive: Reason for sound dropouts found
Aldo
blinuxman at tuxfamily.org
Sam 20 Aou 12:54:33 CEST 2005
Je voudrais savoir si les problèmes que nosu avons de distrib en
distrib, alsa ou oss, peu importe, n'ont pas à voir avec ceci?
merci de vos éventuelles réponses.
Linux-Kernel Archive: Reason for sound dropouts found
X-URL: http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0711.html
Reason for sound dropouts found
T.Mertes at mobilkom.at
Fri, 12 Mar 1999 10:26:01 +0100
(un peu vieux comme info, hm!)
* Messages sorted by: [1][ date ][2][ thread ][3][ subject ][4][
author ]
* Next message: [5]Brian Gerst: "Re: 3dfx - a security hazard?"
* Previous message: [6]Nathan Hand: "Re: xawtv segfaults with
2.2.3-ac1 (not 2.2.3)"
* Next in thread: [7]T.Mertes at mobilkom.at: "Re: Reason for sound
dropouts found"
* Maybe reply: [8]T.Mertes at mobilkom.at: "Re: Reason for sound
dropouts found"
* Maybe reply: [9]Thomas Sailer: "Re: Reason for sound dropouts
found"
* Maybe reply: [10]Paul Barton-Davis: "Re: Reason for sound dropouts
found"
* Maybe reply: [11]Thomas Sailer: "Re: Reason for sound dropouts
found"
_________________________________________________________________
The good [12]news:
I found the reason of sound dropouts which happen under
disk load and are reported from time to time in linux-kernel.
Statement:
Dropouts during playing of sound using /dev/dsp and
related devices using play, sox, cat and other programms
happen because the read() call of the playing command
has to wait too long when the system is under disk load.
So the internal buffer of the sound driver gets empty
and the driver has to shut the sound card for a short
time. This is true for all sound cards and drivers.
Proof:
With a cold cache on my system it is easy to produce
dropouts using:
penguin> find / -name "*core*" &
penguin> play sound.wav
when sound.wav is some 30 to 40 MB sound file (3 to 4 min).
Additionally xosviews interrupt lights of the sound card
went dark during a dropout while the interrupt lights of
the timer and the scsi stay on. You can do also mouse
activitys like moving the windows during the dropouts.
This is an indication that the dropouts are not related to
switching off the interrupts for too long. During the
dropouts there is usually no big CPU load.
When you do the following (also with a cold cache):
penguin> play sound.wav
penguin> find / -name "*core*" &
penguin> play sound.wav
there are no dropouts. In this case, after the first playing
the file sound.wav is already in the cache and reading it
a second time does not have to wait for disk i/o.
When you do the following (with cold cache):
penguin> strace -f play sound.wav
and in another window
penguin> find / -name "*core*"
you can see that the strace stops showing a read() syscall
every time you have a dropout. This read is from the
sound.wav file.
To proof thet the dropouts are sound card and sound driver
independend is easy: I get the dropouts under load using two
different sound cards and their drivers:
SB 16 Vibra and SB 128 PCI
From that I conclude that it happens also with other cards
and drivers.
I used also the alsa driver for the SB 128 PCI and get the
same results.
Collary:
This sort of sound dropouts are
1. Not related to disallowing interrupts in IDE or
SCSI drivers for too long. This was stated in the
past several times as reason for sound dropouts.
2. Not related to the sound driver and its dma.
3. Not related to CPU load.
Solution(s):
There are several ways to solve this problem:
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
I would suggest to look at all three ways together to
solve the problem.
About the 3rd way I tried a little bit:
With the ALSA driver I already used 128k of buffer. But it
was not enough (I still get dropouts). To get big buffers
from the kernel I had to change
#define NR_MEM_LISTS 6
to
#define NR_MEM_LISTS 10
in linux/mm/page_alloc.c so that __get_free_pages can
deliver bigger buffers. Is that enough or did I miss
something.
I was up to now not able to lift the limitation of
128k buffers the alsa audiopci driver is using.
I do not know much about ISA and PCI dma.
Is there a limit in the size of a PCI/ISA dma area.
If there are no limits I would suggest to change
the sound drivers to be configurable to have big
buffers. I think that People with 128MB or more would
happily spend even 1MB or more just to have good
sound under every load condition. I think of some
config option or module parameter specifying the
size of the buffer would be enough.
If you have information how to enlarge the dma buffer
of the es1370 driver of the kernel or the audiopci
driver of alsa it would be helpful.
What do the linux kernel specialists think of
having big sound driver buffers?
Greetins Thomas
-
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
the body of a message to majordomo at vger.rutgers.edu
Please read the FAQ at [13]http://www.tux.org/lkml/
_________________________________________________________________
* Next message: [14]Brian Gerst: "Re: 3dfx - a security hazard?"
* Previous message: [15]Nathan Hand: "Re: xawtv segfaults with
2.2.3-ac1 (not 2.2.3)"
* Next in thread: [16]T.Mertes at mobilkom.at: "Re: Reason for sound
dropouts found"
* Maybe reply: [17]T.Mertes at mobilkom.at: "Re: Reason for sound
dropouts found"
* Maybe reply: [18]Thomas Sailer: "Re: Reason for sound dropouts
found"
* Maybe reply: [19]Paul Barton-Davis: "Re: Reason for sound dropouts
found"
* Maybe reply: [20]Thomas Sailer: "Re: Reason for sound dropouts
found"
References
1. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/date.html#711
2. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/index.html#711
3. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/subject.html#711
4. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/author.html#711
5. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0712.html
6. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0710.html
7. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0728.html
8. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0728.html
9. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0759.html
10. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0766.html
11. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0784.html
12. news:*
13. http://www.tux.org/lkml/
14. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0712.html
15. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0710.html
16. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0728.html
17. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0728.html
18. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0759.html
19. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0766.html
20. http://www.uwsg.iu.edu/hypermail/linux/kernel/9903.1/0784.html
Plus d'informations sur la liste de diffusion Linux-bruxelles