[alsa-devel] safe support for rewind in ALSA

[pl bossart]

All,
I'd like to reopen a thread on concerns with the current
implementation of rewind in ALSA. This was already discussed on the
mailing list last year without any progress.
(see  http://thread.gmane.org/gmane.linux.alsa.devel/65759/focus=65773
and http://article.gmane.org/gmane.linux.alsa.devel/66902)

The problem is that snd_pcm_rewind() allows in theory to go back to
the next sample to be rendered. This however isn't possible on any
existing hardware. DMAs do prefetch samples ahead of time, and output
interfaces have FIFOs on top of this.
This isn't too bad in the PC world with HDAudio, since the prefetching
is limited. However in the embedded space it has become a headache. To
reduce power consumption, most of the recent embedded interfaces do
embed some local internal memory (5kB for TI's McBSP3, a lot more for
others), and we should provide a means for driver developers to set a
bound on how much can be rewound safely when power-saving features are
enabled.

Note that there already are a set of definitions for FIFOs, but they
are either obsolete or no one uses them (actually HDAudio makes use of
this value internally in azx_dev but doesn't export it).

My suggestion would be to add a 'fifo' parameter to the runtime
structure (so that it's visible to the core), let the driver developer
fill the value in the .open routine, and use this parameter in rewind
to prevent rewinding too much. This parameter would include both
hardware FIFOs and DMA buffers.

Comments welcome.
- Pierre