[alsa-devel] Proposal for more reliable audio DMA.

[Robert Hancock]

On 06/25/2009 08:20 AM, Jon Smirl wrote:
> On Thu, Jun 25, 2009 at 1:36 AM, Robert Hancock<hancockrwd at gmail.com>  wrote:
>> On 06/24/2009 10:26 PM, Jon Smirl wrote:
>>> On Wed, Jun 24, 2009 at 5:11 PM, Takashi Iwai<tiwai at suse.de>    wrote:
>>>>> The problem is knowing which sample in the background music to start
>>>>> mixing the low latency laser blast into.
>>>> That's why querying the accurate hwptr is important in PA.
>>> I'm still not convinced that all of this logic should be exposed to
>>> PA. Exposing these details is what makes ALSA hard to use. We should
>>> be able to better isolate user space from this. If mixing were moved
>>> into the kernel these details could be hidden.  The in-kernel code
>>> could then be customized for various sound DMA hardware. This would
>>> also go a long ways toward getting rid of latency issues by removing
>>> the need for real-time response from PA.
>> Mixing really does not belong in the kernel. Moving it there doesn't remove
>> any complication or problem, it just moves it to a different place where
>> it's more difficult to program and less debuggable. Most OSes (Windows
>> included) are moving in the direction of moving mixing out of the kernel,
>> not into it.
>
> Mixing has a real-time component to it. Currently Desktop Linux
> doesn't have real-time support. That's why pulse is developing
> RealTimeKit.  Buggy real-time code can easily lock your machine to
> where you need to hit the reset button.
>
> User space code that is locked down with real-time priority and
> servicing interrupts is effectively kernel code, it might as well be
> in the kernel where it can get rid of the process overhead.
>
> http://git.0pointer.de/?p=rtkit.git;a=blob;f=README

Just because it runs with real time priority does not mean it is 
effectively kernel code, or that it belongs there. Putting the code into 
the kernel adds a bunch of extra challenges for little reason, and also 
locks all users into a mixing scheme that may not meet their needs 
(ahem, Windows kernel mixer..)