Re: Mac mini sound woes

[Marcin Dalecki <martin@dalecki.de>]

On 2005-03-29, at 05:36, Lee Revell wrote:

> On Mon, 2005-03-28 at 09:42 +1000, Benjamin Herrenschmidt wrote:
>> It seems that Apple's driver has an in-kernel framework for doing 
>> volume
>> control, mixing, and other horrors right in the kernel, in temporary
>> buffers, just before they get DMA'ed (gack !)
>>
>> I want to avoid something like that. How "friendly" would Alsa be to
>> drivers that don't have any HW volume control capability ? Does 
>> typical
>> userland libraries provide software processing volume control ? Do you
>> suggest I just don't do any control ? Or should I implement a double
>> buffer scheme with software gain as well in the kernel driver ?
>
> alsa-lib handles both mixing (dmix plugin) and volume control (softvol
> plugin) in software for codecs like this that don't do it in hardware.
> Since Windows does mixing and volume control in the kernel (ugh) it's
> increasingly common to find devices that cannot do these.  You don't
> need to handle it in the driver at all.
>
> dmix has been around for a while but softvol plugin is very new, you
> will need ALSA CVS or the upcoming 1.0.9 release.

Instead of the lame claims on how ugly it is to do hardware mixing in
kernel space the ALSA fans should ask them self the following questions:

1. Where do you have true "real-time" under linux? Kernel or user space?
2. Where would you put the firmware for an DSP? Far away or as near to 
hardware as possible?
3. How do you synchronize devices on non real time system?
4. Why the hell do we have whole network protocols inside the kernel? 
Couldn't those
be perfectly handled in user space? Or maybe there are good reasons?
5. Should a driver just basically map the hardware to the user space or 
shouldn't
it perhaps provide abstraction from the actual hardware implementing it?
6. Is there really a conceptual difference between a DSP+CPU+driver and 
just
looking at the MMX IP core of the CPU as an DSP?