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