Re: What does snd_pcm_delay() actually return?

[Eliot Blennerhassett <linux@audioscience.com>]

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.

regards

Eliot Blennerhassett