[alsa-devel] What does snd_pcm_delay() actually return?
linux at audioscience.com
Tue Jun 17 02:53:59 CEST 2008
Takashi Iwai wrote:
> First off, it's not only about USB but for hardwares that require the
> own h/w queue. There bunch of such hardwares, and we provide really
> poor support for them. The above sounds like bandaiding on a bandaid
> over a bandaid.
Hmm. This thread will take some digesting...meanwhile here are my (not
particularly coherent) thoughts from the POV of driver developer for
cards that have large on-card FIFOs. (asihpi)
The period-based refresh makes it hard to use the fifo effectively. If
the card fifo is allowed to 'suck' all the data from the ringbuffer then
it makes it look like an underrun. Also it makes time appear to run fast
until the fifo is filled up.
The 'fast time' creates problems for ALSA on playback start, because
alsa assumes that it will take a whole period for a period of data to be
consumed, while the driver is capable of consuming multiple periods
almost instantly. In my driver I have to throttle the rate that data is
transferred to the card fifos.
Just as in the network case, where it is desirable to get data across
the network as early as possible to allow secure playback, we want to
fill the oncard fifo as early and as much as possible.
Only if both ringbuffer and fifo are empty (playback) or full (record)
is a true xrun occuring.
Our underlying API returns the following info
* Size of host ringbuffer
* Amount of unread data in host ringbuffer
* Amount of unread data in card fifo
* Frames output at the DAC/input at ADC since stream start
Plus info about granularity and latency of the above info.
I suspect that a byte-stream approach would be a better match to our cards.
More information about the Alsa-devel