[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