Right, an mp3 buffer can be much smaller than a wave buffer. Here
you
can save RAM. But you have to expand the mp3 sound which costs time
and that can make problems when there is high CPU load. A plane
user or kernel space buffer helps when there is high DISK load.
A kernel space buffer might be needed to be contiguous and a user
space demon needs to communicate with the actual player.
You see: The hole think is not so simple as: A USER/KERNEL space
solution serves all needs.
What I want to say is:
We should try out ALL possible solutions in parallel.
Maybe one solution alone is not sufficient, but two together are.
Maybe readahead of sequencially readed files can really be improved
greatly and the whole USER/KERNEL space debate is useless.
Sound output is realtime. Linux (and unix) is NOT a realtime
operating system (No flames please). There is no guarantee, that
a system call reacts in a given time. So in theory a read() system
call can take "forever" and in that case every kernel and user
buffer
runs out. This is a really theoretical case, I know.
Now lets take the "computer users" view:
I really don't care about USER/KERNEL space solutions. But I
want a solution. I want it now. So it cannot be the perfect one
which requires all sound software to be rewritten and will be
finished in five years. I just want a working solution now, which
in
five years will be replaced by the perfect one.
For that reason I looked into the kernel and the alsa sound drivers
and found that there are places where the buffer size can be
specified. So it might be possible just to adjust some numbers in
the kernel and/or alsa sound driver and get a working solution.
What I tried to ask then was:
Can somebody help me because there might be some
limitations in the DMA and/or driver side which I do not
recognize at first sight. For example the ALSA audiopci driver
provides a configurable buffer size from 4 to 128kB. Some of
the internals of the driver set the buffer size to 128 when I
specify a bigger buffer size. Is this an artificial software/dma
limit or can I raise it. I sombody knows, please tell me the place
where the limit is checked.
I guess that other people with other cards and drivers have
the same problem. Therefore I sended the mail to linux-kernel.
If that is the case and we can provide a solution it would help
a lot of people. (Of course I start with my soundcard)
INVITATION to everybody listening:
If you are interested to help you can try the following:
First try to play a bigger wave file on your machine under load.
Not "Hello this is Linus ..." but something which is 30 to 40 MB big
and takes several minutes to play. If you dont have such a wave
file you can produce it with cdparanoia. Then try to play it with
play sound.wav
(which internally uses the sox command).
If you then put load on the same disk with for example with
find / -name "*core*"
and hear sound dropouts then your system is usable to test
sound dropout solutions. Now you can reproduce the dropouts
at any time (remember to have a clean cache: so reboot).
With that it is possible to try any solution. You can try different
sound playing programs, develop a new one, try the gnome
sound demon. Try user and/or kernel space solutions...
end INVITATION
I for myself will first try out to enlarge buffers on the kernel
and/or alsa driver side. Because if that works I can use all
existing sound programs. If that does not work I will also start
with user space solutions.
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/