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.