It seems that for ens1371, setting rate to 44100 (with
snd_pcm_hw_params_set_rate_near) returns 44099 for capture and 44100 for
playback.
In alsa-driver/cards/cards-ens1371 we have:
static ratden_t es1371_dac_clock = {
num_min: 3000 * (1 << 15),
num_max: 48000 * (1 << 15),
num_step: 3000,
den: 1 << 15,
};
static ratnum_t es1371_adc_clock = {
num: 48000 << 15,
den_min: 32768,
den_max: 393216,
den_step: 1,
};
... so adc and dac rates really are different. Based on the above
information, the closest exact adc rates are 44101.051Hz and
44099.814Hz.
Now this raises some questions. Ecasound currently uses set_rate_near(),
but for instance JACK and possibly ardour use set_rate(). So I need to
patch them to use _near() before use. I can do this because I know
set_near() will do what I want. But with some other cards set_near() might
set a rate that is really different from the requested one, and will
result in unexpected app behaviour. So set_near() is not a universal
solution.
Another thing is what does the plugin layer do if sample rate differs by
one sample. Does it end up doing resampling from 44099 to 44100? Now this
doesn't sound good.
Any ideas on how to handle this?
--
http://www.eca.cx
Audio software for Linux!
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
