Re: underruns and strange code in pcm_rate.c (and patch)

["Alexander E. Patrakov" <patrakov@ums.usu.ru>]

Takashi Iwai wrote:

> The problem is that the hardware is woken up only at the period size
> of the slave side.  Assume the slave (hardware playback) is running
> 48kHz and the client (input) is 44.1kHz.  When dmix is used, usually
> the period size = 1024 in the h/w side.  Then the period size of the
> client side is supposed to be 940.
> Here, note that 940 != 1024 * 44.1 / 48.0 exactly.  This rounding
> causes the drift of wake-up time at each period and the delay is
> accumulated.

Let me propose a solution: let the "rate" plugin return a rate slightly 
different from the requested one, adjusted based on the period size, so that the 
mismatch and rounding error doesn't happen (i.e.: use 44062 Hz instead of 44100 
in calculations of pointer positions in the above example, and resample the 
client data from that rate instead of exact 44100). This would not be a 
regression anyway, as there are cards (e.g., ens1371) that can do 48 kHz only 
approximately.

-- 
Alexander E. Patrakov