Hi all!

A while ago I started development of an ALSA driver for a device which natively only supports a sampling rate of 39062.5 Hz and 24 bit samples (see http://www.tanzband-scream.at/line6). The ALSA rate plugin does a perfect job for using this device with standard applications (such as xmms) to play audio files at "conventional" sample rates (e.g., 44.1 kHz) with a configuration like this:

pcm.resampler { type rate slave { pcm hw:1 format S24_3LE rate 39062 } converter "samplerate" }

However, this doesn't work for jack since jack requires a power-of-two period size, and ALSA can't find an integer period size for the raw device such that the target rate is met with sufficient precision. An example: the jack daemon can't be started with period size 512 and sample rate 48000 Hz, but it works for 47961 Hz since

512 * 39062.5 / 48000 = 416.666... ~= 417 bytes 512 / 417 * 39062.5 = 47961.63 ~= 47961 Hz

When using this approach together with other audio data from a 48 kHz source, they would drift apart over time, which basically renders the alsa+jack setup useless for this device. I understand that resampling is easier to implement if the sample rate ratio equals the ratio of the (integer) period sizes of client and slave, but at least the underlying libsamplerate has no such restriction. I tried to find the relevant pieces in the ALSA source code (pcm_rate.c), but I'm not sure where these calculations are done and how much effort it would be to support arbitrary sample rate ratios for the resampler. Can this be done in a plugin, or does it require modifications in the ALSA library code base? Could the developers please give a few hints on that?

Thanks & kind regards, Markus