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

[Jon Smirl]

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

>
> For what PulseAudio is trying to do, it needs this kind of information
> because it wants to be able to rewrite the buffer the card is reading out of
> at any time, and it needs to be able to know how far along in the buffer the
> card has read so it knows where it can start rewriting. It's somewhat
> complicated for sure, but most normal applications don't have to deal with
> these kinds of details.
>
>>
>> My hardware doesn't have the capability of querying the hwptr and the
>> hwptr speed is not linear because of the FIFO and burst transfers.
>> Non-linear speed means I can't use a clock to estimate hwptr. I do
>> however have the capability of directing the DMA into a new buffer.
>> Another thing I could try is setting up DMA descriptor chain blocks
>> for every 16 bytes. These descriptors get marked as they are used and
>> they don't have to cause an interrupt.
>>
>> We are evaluating a processor change from PPC to ARM so all of this
>> may change for me.
>>
>
>



-- 
Jon Smirl
jonsmirl at gmail.com