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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
