> 2) ALSA API is to complicated: most applications opens single sound
> stream.
Seconded.
> 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
>
Why would you, or the "Desktop User Joe" using Torvalds-advertised KDE,
care about how many modules are loaded?
Splitting code up to make things more modular is A Good Choice most
of the times. There is, however, one point in which you have reason:
if the overall modular structure is bigger than a mono one, then it's
indeed "complicated".
> 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.
>
jackd does not count - ALSA works without it.
> 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.
>
I'd rather have libasound segfault rather than my kernel oopsing, in case
someone forgot a NULL check.
> 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.
>
AFAICS, OSS does not do mixing at all in its current state.
Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[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]
