[alsa-devel] Proposal for more reliable audio DMA.
jonsmirl at gmail.com
Thu Jun 25 16:20:22 CEST 2009
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.
> 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.
jonsmirl at gmail.com
More information about the Alsa-devel