Re: software mixing in alsa

[Jaroslav Kysela <perex@suse.cz>]

On Wed, 18 May 2005, Karel Kulhavy wrote:

> On Tue, May 17, 2005 at 04:36:30PM -0400, Lee Revell wrote:
> 
> [...]
> 
> > alsa-lib, which is part of userspace.  From the application's point of
> > view, it does not matter whether the mixing happens in kernel or not.
> > ALSA follows the philosophy of doing as little as possible in the
> > kernel, and since mixing and volume control work fine in userspace,
> > that's where they live.
> 
> Mixing is IMHO action that should be in kernel because
> 
> 1) needs realtime scheduling to keep latency down

With a realtime scheduler and properly written drivers (no "schedule"  
gaps) you'll reach same results. For x86 we use special instructions like
xchg and locking-free algorithm in dmix, so the latency is SAME for all 
concurent apps with minimal overhead..

> 2) needs tight cooperation with the hardware to prevent dropouts
> on underruns

Yes, but having the code which computes something in interrupt is not 
sane.

> 3) Is a trivial linear algorithm involving memory blocks and linear
>    arithmetic, no complicated computations that are difficult to
>    check for BugFree(TM) so shouldn't present a great risk on kernel
>    stability

You need to write complete new virtual layer or use a new special driver 
which connect to real soundcard. Thats a lot of new code - it's better to 
do it safely in the user space.

> 4) Fits into the kernel philosophy. Kernel is a program meant to provide
>    time-sharing access to limited hardware resource. Sound card is a
>    limited hardware resource.

Why X drivers aren't in kernel, too? Because they're big and kernel should
drive the real bottom of hardware (interrupts, DMA, memory mapping), but
abstraction (which sound mixing _IS_) should be implemented in the user 
space. Otherwise we will end up with a huge kernel implementing nearly 
everything...

> 5) From the knowledge of the exact hardware, the mixing routine in
>    kernel can know maximum allowable levels etc. to prevent clipping.

You can obtain all necessary info in the userspace as well.

We should definitely fix the dmix bugs. Or, if you want, you might buy
an accelerated soundcard which supports multiple streams in hardware.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/