[alsa-devel] safe support for rewind in ALSA
Kai Vehmanen
kvehmanen at eca.cx
Sun Feb 21 11:35:07 CET 2010
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.
More information about the Alsa-devel
mailing list