Hi,
On Mon, 15 Feb 2010, Raymond Yau wrote:
Even using a high resolution timer , the application still cannot achieve latency better than the configured period size
For USB case , the driver cannot give accurate hw pointer position , hw pointer increase in steps for the current implementation, (i.e. the graph is
... but that's a real hardware limitation for the USB-driver, right? And even in the USB case, hw pointer is incremented in steps of URB transfer size, so even in this case, latency of a highres timer based application is not limited by the set period-size.
Of course, there is no ALSA API to query the burst size (e.g. the granularity of hw_ptr updates), which is a real problem for generic apps (that are not hardcoded to work with just one ALSA driver).
But you can query the SNDRV_PCM_INFO_BATCH flag (it's set by e.g. the USB driver) and adjust your hrtimer-based application's logic based on that (if set, assume hw_ptr will jump in bursts). I know, not really ideal (you essentially have to e.g. disable PA glitch-free for these cards currently).
This mean that the wake up time cannot be calculated using as number of sample/rate since the fuction is not linear especially when using max buffer size , min period --> max period size is much greater than the watermark
Yep, that's what SNDRV_PCM_INFO_BATCH flag warns you about.