On Tue, 3 Jan 2006, Adrian Bunk wrote:
On Tue, Jan 03, 2006 at 08:24:49PM +0100, Olivier Galibert wrote:
On Tue, Jan 03, 2006 at 05:16:13PM +0000, Alistair John Strachan wrote:
This argument is basically watered down with devfs, udev, sysfs, etc. which
all have exactly the same issues. Should a crippled OSS API be the way
forward for Linux? I think not.
And they're getting some real backlash because of that now. Hell,
Linus' message was about udev in the first place.
The udev breakages might not have been nice, but OSS/ALSA is a
completely different issue:
OSS has been deprecated since ALSA was merged into the Linux kernel
_four years ago_.
Also more than four years exist another thing: generaly sound suport in
Linux kernel is broken by design. Points where it is broken:
1) ALSA API forces not use devices files and many things on sound managing
level are handled on user space library. This dissallow civilized
redirection sound stream in runed application without this application
interractions (try redirect sound stream on runed application for
example to headset .. simple case skype .. oh you probaly don't know: in
current ALSA infrastructure there is no civilized way for handle
gadgests like BT headsets). In current ALSA API (IIRC) you must write in
special way applications for handle this (look pint 2)).
2) ALSA API is to complicated: most applications opens single sound
stream.
All what system user expect it is plaing sound by more then one
application with simple mixing sound streams. For me ALSA is prepared
like for handle ANY sound case .. EXCEPT all most simpler.
3) ALSA kernel architecture is to complicated. This main reason why
configuring sound on Linux is SO COMPLICATED. From my system:
# lsmod | grep ^snd | wc -l
19
All this for handle ONLY ONE sound card. Why not one alsa main module
and one with hardware backend module like in comarcial OSS ?
ALSA is also requires much more bigger code size than OSS variant
(count all snd* modules size, jackd and libasound and compare this with
OSS modules and user space OSS library size). Simillar is on allocated
memory in all system sound components.
Many task switches incurred by the current ALSA architecture
add quickly up to perceivalble deleys during processing. In many cases
sound must be handled with RT piorites so all code sise must possible
small for handle this with minimal latency.
4) ALSA mixing model is UNSECURE by design because all mixing sound
streams (for example with diffrent sampling rates) are performed
in user space.
Also using jackd also "creates problems" with RTing this proccess and
much more bigger problems on configure stage (for joe user).
All this can be handled in secure and proprer RT prioprities
ONLY on kernel space (so all gaming mith jackd or so is plain waste
of time). Only on kernel level is possible correctly handle all this.
With ALSA you can't extend in esy way for example SELinux for prevent
intercept sound streem from microphone by remote user. Current OSS API
is much more better for SELinux.
Why ? because all mixing on OSS is performed on kernel level.
I can't understand why ALSA developers still do not understands this
fundamentalt facts.
5) OSS API can be used not only on Linux. ALSA API can be used ONLY on
Linux.
This was, still is and (looks like allways) will be main reason
for not spending so many time as it is required on polish sound
interractions on Linux applications.
Still I can't understand why introducing ALSA *must* break OSS user
space API in so deep way.
OSS user space API also have some weak poinst on to big complications
because it allow implemet the same cases in to many forms (for some
cases it provides more than two ways for handle some scenarios).
I do not understand why on developing Linux soud support was forgoten
"don't move .. improve" sentence :>
OSS API paralelism looks lik was "correctly" implemnted in ALSA .. so
ALSA do not improves sound handling for user space applications and
additionaly introduces other own complications (ASA API documentations
in many cases isn't clear).
Conclution: removing OSS from Linux kernel and force using ALSA in last
four years was IMO one of the main resons why Linux still can't
effectively fight on desktop area and in future will be/can be one of the
most importand weak point which can drive Linux to die at all (in longer
period).
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [email protected]*
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
