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

[Takashi Iwai]

At Wed, 24 Jun 2009 10:10:35 -0400,
Jon Smirl wrote:
> 
> On Tue, Jun 23, 2009 at 5:54 AM, Mark
> Brown<broonie at opensource.wolfsonmicro.com> wrote:
> > On Mon, Jun 22, 2009 at 12:43:52PM -0400, Jon Smirl wrote:
> >> On Mon, Jun 22, 2009 at 12:27 PM, James
> >
> >> > DMA transfers on sound cards are a ring buffer. There is no automatic
> >> > stop feature.
> >
> >> I don't about all hardware, but all of the hardware I've worked with
> >> works both ways, ring or stop at the end.
> >
> >> DMA transfers for network packets wouldn't work in the ring buffer
> >> model, you need the stop at the end capability.
> >
> > Remember, you're working with a general purpose SoC which shares the DMA
> > controller with a large selection of other hardware.  A DMA controller
> > that's part of a sound device and can't be used in anything else doesn't
> > need to worry about any other applications.
> >
> 
> From what I have observed the current ALSA DMA design does not
> reliably deal with over/underrun.  On the hardware I'm using it is
> possible to construct a system which will always behave predictably
> but I can't build it using the ALSA driver interface.

That's true for your hardware.  But not for most hardware with
simple "setup-go-and-dont-touch-anymore" style DMA.

> These issues probably indicates that the DMA interface between ALSA
> and the driver has been designed at the wrong level.

Partly true.  ALSA PCM was designed for most ISA/PCI DMA transfer
model, not for embedded devices.  (BTW, it means that your proposal
can't be applied easily to most of these devices because their DMA
setup cannot be changed at all while DMA is running...)

> For example those
> timers trying to fix glitches in HDA belong down in the HDA driver,
> not the core.

Basically, XRUN can be avoided very easily.  Simply have an enough
large buffer.  The rest question is how to fill the buffer.  If you
don't want to give h/w interrupts from the sound chip, you need any
other timing source to sync with the position.  But, XRUN is simply a
matter of the buffer size and the latency of the system.

The glitch-free problem of PA comes from the fact that PA assumes that
the driver returns the current hw position accurately at any time.
But, in many hardwards, including HDA, this is not true.  The hardware
lies.  It doesn't report the right position at all.  Thus, there are
many workarounds implemented in HD-audio side.

So, before a discussion goes chaotic, I'd like to separate two issues:
- how to avoid XRUN
- how to detect XRUN

The former is what I mentioned in the above.

The latter pretty depends on the hardware, and your proposal would
help (if it were possible for the target hardware).

Actually, for me, your proposal looks rather like a redesign of PCM
core to fit better with specific embedded devices.  That's fine, and
I've been thinking of a way to improve the core model.  But, it would
merely help for "reliability" in general, if you look at all devices
we must support.


thanks,

Takashi