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

[Robert Hancock]

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.

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.
>